Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

I created an issue on phabricator for "CONSULTATION/PLAN: Managing Complex
State and GUI on Mediawiki (e.g. for Wikidata/Wikibase UI)"
https://phabricator.wikimedia.org/T157014

And added people who showed interest here as subscribes (hope that is fine)

Jan
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Krinkle]

On Mon, Jan 30, 2017 at 1:57 PM, Jan Dittrich 
 wrote:

>
> State management and data/event propagation goes beyond of what OOUI can
> provide, as far as I (Jan) know. So an obvious candidate was looking into
> MVVM solutions of which the most well known is the React library.


If considering React, I would start by recommending Preact instead.
Especially since we're starting clean, we won't need any compat layer (and
yet feels similar enough to existing users).

https://preactjs.com/


On Wed, Feb 1, 2017 at 1:11 AM, Jon Robson  wrote:

>
> Redux for managing your state and OOjs UI for rendering the UI components.
>


Indeed, Redux is also a good option.

-- Timo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

Hi John,

Thanks for sharing your evaluation and your experiences – and, in,
particular, working examples.



> So I'm curious... for something like Wikidata which is so different from
> standard Mediawiki instances =(the rendering and editing experiences are
> fundamentally different) what's stopping you from adding a layer on top of
> the stack and using Mediawiki as a black box for storage and API... at
> least as an alternative editing experience?


I am not sure (I am not very deep into our current code base), but if I am
right that is pretty much what is already done, anyway in Wikibase: Its
server part exposes an api to which we push the data.

Jan

2017-02-01 2:11 GMT+01:00 Jon Robson :

> I think at this point Mediawiki's frontend stack and its dependencies on RL
> and supporting user gadgets don't lend itself well to frameworks like React
> or Vue.  With regards to moving away from jQuery UI your path of least
> resistance inside MediaWiki feels like it might be to use a library such as
> Redux for managing your state and OOjs UI for rendering the UI components.
>
> Frameworks by definition provide you with rules and constraints to prevent
> you from writing code in bad ways leading you to easier to work with code.
> The MediaWiki ecosystem doesn't do well with constraints - it's about
> experimenting.
>
> That aside, I'm curious if you have considered a different approach. One
> big issue we commonly see in the reading web team in working with
> MobileFrontend and our apps team who depend on our APIs is that the lines
> of model and view get blurred frequently. There are certain things our API
> doesn't do and that we workaround in PHP code - the only place we can do
> this. I was a little worried about this, so as a side project I explored
> how difficult it was to render the existing mobile site without MediaWiki's
> PHP layer.  I built a progressive web app (PWA) using React (just a
> personal preference but any framework could be used to do the same). The
> result is deployed on labs: https://trending.wmflabs.org
> and the code on Github: https://github.com/jdlrobson/weekipedia
>
> At first, this may seem like a lot of work but it wasn't. I reused
> Mediawiki
>  code where possible (packaging up into npm libraries) and what I found was
> feature development became extremely easy the more that I implemented as
> reuse was extremely useful within the framework.
>
> The React web app now has feature parity with the mobile site - it looks th
> esame, you can login support via OAuth (thanks to the awesome work from
> Gergő
> Tisza and co), there's i18n support
>  A8%D7%90%D7%9C?uselang=he>,
> you can edit you can view history/diffs etc etc... we've been using it
> for user testing. Since things got so easy I even got carried away and
> built features I've wanted forever ;-) [1]:
>
> If I exclude the time I spent improving Mediawiki REST APIs to support this
> app I reckon building this took about a month of work (and that wasn't even
> full time). Yes, the solution had many trade-offs... My app cannot run
> gadgets or CSS/JS from the Mediawiki namespace and certain pages which
> require additional JavaScript e.g. maps/pages with math do not load that Js
> - but I see those problems as easily solvable and I value the benefits I
> experienced through working within a well-documented framework...
>
> So I'm curious... for something like Wikidata which is so different from
> standard Mediawiki instances =(the rendering and editing experiences are
> fundamentally different) what's stopping you from adding a layer on top of
> the stack and using Mediawiki as a black box for storage and API... at
> least as an alternative editing experience?
>
> Having complete APIs and enabling our future and present community members
> to be able to build things like this easily should be our goal as
> engineers.
>
> It's worth pointing out that Chrome has plans to allow developers to
> package web apps as installable APKs (see
> https://joreteg.com/blog/installing-web-apps-for-real). What this means is
> with a bit of configuration I could update my PWA to override all visits to
> Wikimedia domains and steal traffic. I think when this happens lots of
> developers will be jumping on this opportunity. This is great for
> distributing our knowledge, not so good about keeping a unified experience
> for all our visitors. I'd rather we were ahead of that trend rather than
> lagging behind.
>
> Happy to chat more if you find this conversation interesting. I've covered
> a lot here... :)
> [1] e.g.
> * infinite random -  https://trending.wmflabs.org/en/wiki/Special:Random
> * the trending work turned into a REST API that we're still experimenting
> with and offline support.
> * cross-wiki search -
> https://trending.wmflabs.org/en.wikiquote/Special:Search/San%20Francisco
>
>
> On Tue, 31 Jan 2017, 5:06 a.m. Jan Drewniak, 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

>
> Regardless of UI framework, for state management I'd strongly recommend
> using redux , and after the fact pair it with
> whatever UI framework you prefer.


Yes,  that (referred to as "State management" or so in my mail) may have
been a bit buried under all the other stuff, but it is something I think of
as a good way too (regardless of the actual DOM generation)

A college of mine (not on the Wikidata team) has used it, too, and we were
both happy.

we can set some time to discuss and show you how
> we're using it (we still need to write documentation about it so that's why
> I can't point you to much now).
>

Thanks! I will get back to the team with all the infos I get here and then
decide about further information needs, but it is pretty likely that we
need some info there. I'll get back to this.


Jan

2017-02-01 7:58 GMT+01:00 Joaquin Oltra Hernandez 
:

> Hi Jan,
>
> Regardless of UI framework, for state management I'd strongly recommend
> using redux , and after the fact pair it with
> whatever UI framework you prefer. Here are some of the reasons for using
> it:
>
>
>- Very popular and widely used
>- Excellent documentation (see http://redux.js.org/)
>- Plenty of educational materials (articles, tutorials, videos,
>examples, and the docs site itself)
>- Really small size (<2kb)
>- Architecture that forces a single source of true state tree with clear
>state transitions
>- Eases unit testing of the system with the clear boundaries and state
>separation
>- Amazing developer tools making the store a full event sourcing system
> allowing for
>great introspection into the system, importing/exporting event logs,
> time
>travelling through the action log, etc.
>
> Here are some reasons for not using it:
>
>- It is different from what we usually do, which means there is some
>ramp up time and learning to do from people that are used to what is
>usually done.
>
> I personally think it is very worth it, given it imposes a clear separation
> between the business logic and state manipulation and the UI and side
> effects (like in the boundaries talk
> ). If you are
> interested let me know and we can set some time to discuss and show you how
> we're using it (we still need to write documentation about it so that's why
> I can't point you to much now).
>
> Cheers.
>
> On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich 
> wrote:
>
> > Hello Wikitext-l,
> >
> > ---
> > TL;DR: The Wikidata team is considering to use a MVVM/Single-State
> solution
> > for Wikidata’s UI. What are requirements and concerns would be important
> to
> > consider?
> > ---
> >
> > Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be
> faded
> > out, we are looking at possible future frameworks or paradigms to build
> our
> > UI on. Our needs are:
> >
> > - Having a sustainable foundation
> > - Being able to handle complex state dependencies (simplest are like: "if
> > element x is in edit mode, set element y to saving mode")
> > - A solution that is easy to learn for beginners and easy to read and
> > reason about for our engineers.
> >
> >
> > State management and data/event propagation goes beyond of what OOUI can
> > provide, as far as I (Jan) know. So an obvious candidate was looking into
> > MVVM solutions of which the most well known is the React library.
> >
> > We had a deeper look at Vue.js which is known for having a large
> community,
> > too, but being easier to understand and not using an additional patent
> > clause in its licensing.
> >
> >
> > We see the following possible advantages:
> >
> > - Better modularization
> > - understandability of our code, in particular reasoning about event- and
> > data-flow
> > - better separation of concerns and testability for:
> > -- HTML templates
> > -- Component interactivity
> > -- Data manipulation
> > -- connection to backend-API
> >
> >
> > - If we use a well documented framework, learning to contribute is much
> > easier compared to software for which there is only auto-generated
> > code-level-docs
> >
> >
> > Here are some answers to obvious questions:
> >
> > 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> > syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> > too) normal HTML templates are used
> >
> > 2) Does that mean that people coming from Object oriented languages will
> > need to learn a whole new paradigm – reactive, pure-functional
> programming?
> > -> While there are some elements of functional programming used in
> > react-like-frameworks, I would (subjectively) say that few additional,
> > totally new knowledge is needed and most can be covered by "take
> > parameters, work 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

> Many of these new JS libraries, such as React, have some very heavy
> dependancies.


Yes, this is true. The usage of such dependencies is often not connected to
the way such frontends work, though. E.g. vue can be used without a loader
and does not need an extra JSX compiler.
It is often used with a loader (webpack, mostly), because many people seem
to prefer it and it enables you to structure your code in
single-component-files, which I admit, while disliking the dependency, is
very comfortable imho.

Jan



2017-01-31 14:05 GMT+01:00 Jan Drewniak :

> Certainly a topic for the front-end standards group, but to give my two
> cents:
>
> Many of these new JS libraries, such as React, have some very heavy
> dependancies.
> React requires JSX which needs to be transpiled into JS, ES6 Class syntax
> which needs to be transpiled into ES5, which requires Babel and probably a
> task runner like Grunt or Gulp (or webpack), which of course require Node
> and NPM... so already you've built a very heavy dependancy chain which
> itself needs to be maintained (ex: Gulp 4 is coming with breaking changes)
> and all this needs to be integrated into MediaWiki which has its own way of
> doing things.
>
> None of that sounds like fun to me, so however you proceed I would
> certainly aim to avoid all that .
>
>
> On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
> > This discussion seems exactly what we have a Frontend Standards group
> for:
> > https://www.mediawiki.org/wiki/Front-end_standards_group
> > https://phabricator.wikimedia.org/project/profile/1616/
> >
> > DJ
> >
> > On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich  >
> > wrote:
> >
> > > Hello Wikitext-l,
> > >
> > > ---
> > > TL;DR: The Wikidata team is considering to use a MVVM/Single-State
> > solution
> > > for Wikidata’s UI. What are requirements and concerns would be
> important
> > to
> > > consider?
> > > ---
> > >
> > > Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be
> > faded
> > > out, we are looking at possible future frameworks or paradigms to build
> > our
> > > UI on. Our needs are:
> > >
> > > - Having a sustainable foundation
> > > - Being able to handle complex state dependencies (simplest are like:
> "if
> > > element x is in edit mode, set element y to saving mode")
> > > - A solution that is easy to learn for beginners and easy to read and
> > > reason about for our engineers.
> > >
> > >
> > > State management and data/event propagation goes beyond of what OOUI
> can
> > > provide, as far as I (Jan) know. So an obvious candidate was looking
> into
> > > MVVM solutions of which the most well known is the React library.
> > >
> > > We had a deeper look at Vue.js which is known for having a large
> > community,
> > > too, but being easier to understand and not using an additional patent
> > > clause in its licensing.
> > >
> > >
> > > We see the following possible advantages:
> > >
> > > - Better modularization
> > > - understandability of our code, in particular reasoning about event-
> and
> > > data-flow
> > > - better separation of concerns and testability for:
> > > -- HTML templates
> > > -- Component interactivity
> > > -- Data manipulation
> > > -- connection to backend-API
> > >
> > >
> > > - If we use a well documented framework, learning to contribute is much
> > > easier compared to software for which there is only auto-generated
> > > code-level-docs
> > >
> > >
> > > Here are some answers to obvious questions:
> > >
> > > 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> > > syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> > > too) normal HTML templates are used
> > >
> > > 2) Does that mean that people coming from Object oriented languages
> will
> > > need to learn a whole new paradigm – reactive, pure-functional
> > programming?
> > > -> While there are some elements of functional programming used in
> > > react-like-frameworks, I would (subjectively) say that few additional,
> > > totally new knowledge is needed and most can be covered by "take
> > > parameters, work with them, return values; don't manipulate non-local
> > > values"
> > >
> > > 3) How does DOM access work? Does this mean no jQuery?
> > >
> > >
> > > -> DOM can be still be directly accessed. Libraries like jQuery can
> still
> > > be reused (even if they might not be necessary in many points any
> more).
> > > However, to change data or dom persistently, you need to tell the
> library
> > > (which is not unusual, afaic)
> > >
> > >
> > > There are also some other concerns:
> > >
> > > - Should we introduce a new dependency like a framework as Vue?
> > > - What would be the process of introducing such a dependency (if we
> agree
> > > on one)?
> > > - Can we agree on this (or another?) paradigm 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Joaquin Oltra Hernandez]

Hi Jan,

Regardless of UI framework, for state management I'd strongly recommend
using redux , and after the fact pair it with
whatever UI framework you prefer. Here are some of the reasons for using it:


   - Very popular and widely used
   - Excellent documentation (see http://redux.js.org/)
   - Plenty of educational materials (articles, tutorials, videos,
   examples, and the docs site itself)
   - Really small size (<2kb)
   - Architecture that forces a single source of true state tree with clear
   state transitions
   - Eases unit testing of the system with the clear boundaries and state
   separation
   - Amazing developer tools making the store a full event sourcing system
    allowing for
   great introspection into the system, importing/exporting event logs, time
   travelling through the action log, etc.

Here are some reasons for not using it:

   - It is different from what we usually do, which means there is some
   ramp up time and learning to do from people that are used to what is
   usually done.

I personally think it is very worth it, given it imposes a clear separation
between the business logic and state manipulation and the UI and side
effects (like in the boundaries talk
). If you are
interested let me know and we can set some time to discuss and show you how
we're using it (we still need to write documentation about it so that's why
I can't point you to much now).

Cheers.

On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich 
wrote:

> Hello Wikitext-l,
>
> ---
> TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
> for Wikidata’s UI. What are requirements and concerns would be important to
> consider?
> ---
>
> Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
> out, we are looking at possible future frameworks or paradigms to build our
> UI on. Our needs are:
>
> - Having a sustainable foundation
> - Being able to handle complex state dependencies (simplest are like: "if
> element x is in edit mode, set element y to saving mode")
> - A solution that is easy to learn for beginners and easy to read and
> reason about for our engineers.
>
>
> State management and data/event propagation goes beyond of what OOUI can
> provide, as far as I (Jan) know. So an obvious candidate was looking into
> MVVM solutions of which the most well known is the React library.
>
> We had a deeper look at Vue.js which is known for having a large community,
> too, but being easier to understand and not using an additional patent
> clause in its licensing.
>
>
> We see the following possible advantages:
>
> - Better modularization
> - understandability of our code, in particular reasoning about event- and
> data-flow
> - better separation of concerns and testability for:
> -- HTML templates
> -- Component interactivity
> -- Data manipulation
> -- connection to backend-API
>
>
> - If we use a well documented framework, learning to contribute is much
> easier compared to software for which there is only auto-generated
> code-level-docs
>
>
> Here are some answers to obvious questions:
>
> 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> too) normal HTML templates are used
>
> 2) Does that mean that people coming from Object oriented languages will
> need to learn a whole new paradigm – reactive, pure-functional programming?
> -> While there are some elements of functional programming used in
> react-like-frameworks, I would (subjectively) say that few additional,
> totally new knowledge is needed and most can be covered by "take
> parameters, work with them, return values; don't manipulate non-local
> values"
>
> 3) How does DOM access work? Does this mean no jQuery?
>
>
> -> DOM can be still be directly accessed. Libraries like jQuery can still
> be reused (even if they might not be necessary in many points any more).
> However, to change data or dom persistently, you need to tell the library
> (which is not unusual, afaic)
>
>
> There are also some other concerns:
>
> - Should we introduce a new dependency like a framework as Vue?
> - What would be the process of introducing such a dependency (if we agree
> on one)?
> - Can we agree on this (or another?) paradigm for managing complex UIs, so
> that it is not a Wikidata-only solution, but could be used by other
> Wikimedia projects in the future, too?
> - How will this work with OOUIjs? OOUI seems to be mainly responsible for
> creating DOM elements and this actions are usually owned by the MVVM
> framework. One can use hooks to use libraries like OOUI and such, but it
> feels like having the same functionality twice. A possible solution would
> be using OOUI styles and markup but leaving DOM 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jon Robson]

I think at this point Mediawiki's frontend stack and its dependencies on RL
and supporting user gadgets don't lend itself well to frameworks like React
or Vue.  With regards to moving away from jQuery UI your path of least
resistance inside MediaWiki feels like it might be to use a library such as
Redux for managing your state and OOjs UI for rendering the UI components.

Frameworks by definition provide you with rules and constraints to prevent
you from writing code in bad ways leading you to easier to work with code.
The MediaWiki ecosystem doesn't do well with constraints - it's about
experimenting.

That aside, I'm curious if you have considered a different approach. One
big issue we commonly see in the reading web team in working with
MobileFrontend and our apps team who depend on our APIs is that the lines
of model and view get blurred frequently. There are certain things our API
doesn't do and that we workaround in PHP code - the only place we can do
this. I was a little worried about this, so as a side project I explored
how difficult it was to render the existing mobile site without MediaWiki's
PHP layer.  I built a progressive web app (PWA) using React (just a
personal preference but any framework could be used to do the same). The
result is deployed on labs: https://trending.wmflabs.org
and the code on Github: https://github.com/jdlrobson/weekipedia

At first, this may seem like a lot of work but it wasn't. I reused Mediawiki
 code where possible (packaging up into npm libraries) and what I found was
feature development became extremely easy the more that I implemented as
reuse was extremely useful within the framework.

The React web app now has feature parity with the mobile site - it looks th
esame, you can login support via OAuth (thanks to the awesome work from Gergő
Tisza and co), there's i18n support
,
you can edit you can view history/diffs etc etc... we've been using it
for user testing. Since things got so easy I even got carried away and
built features I've wanted forever ;-) [1]:

If I exclude the time I spent improving Mediawiki REST APIs to support this
app I reckon building this took about a month of work (and that wasn't even
full time). Yes, the solution had many trade-offs... My app cannot run
gadgets or CSS/JS from the Mediawiki namespace and certain pages which
require additional JavaScript e.g. maps/pages with math do not load that Js
- but I see those problems as easily solvable and I value the benefits I
experienced through working within a well-documented framework...

So I'm curious... for something like Wikidata which is so different from
standard Mediawiki instances =(the rendering and editing experiences are
fundamentally different) what's stopping you from adding a layer on top of
the stack and using Mediawiki as a black box for storage and API... at
least as an alternative editing experience?

Having complete APIs and enabling our future and present community members
to be able to build things like this easily should be our goal as engineers.

It's worth pointing out that Chrome has plans to allow developers to
package web apps as installable APKs (see
https://joreteg.com/blog/installing-web-apps-for-real). What this means is
with a bit of configuration I could update my PWA to override all visits to
Wikimedia domains and steal traffic. I think when this happens lots of
developers will be jumping on this opportunity. This is great for
distributing our knowledge, not so good about keeping a unified experience
for all our visitors. I'd rather we were ahead of that trend rather than
lagging behind.

Happy to chat more if you find this conversation interesting. I've covered
a lot here... :)
[1] e.g.
* infinite random -  https://trending.wmflabs.org/en/wiki/Special:Random
* the trending work turned into a REST API that we're still experimenting
with and offline support.
* cross-wiki search -
https://trending.wmflabs.org/en.wikiquote/Special:Search/San%20Francisco


On Tue, 31 Jan 2017, 5:06 a.m. Jan Drewniak, 
wrote:

Certainly a topic for the front-end standards group, but to give my two
cents:

Many of these new JS libraries, such as React, have some very heavy
dependancies.
React requires JSX which needs to be transpiled into JS, ES6 Class syntax
which needs to be transpiled into ES5, which requires Babel and probably a
task runner like Grunt or Gulp (or webpack), which of course require Node
and NPM... so already you've built a very heavy dependancy chain which
itself needs to be maintained (ex: Gulp 4 is coming with breaking changes)
and all this needs to be integrated into MediaWiki which has its own way of
doing things.

None of that sounds like fun to me, so however you proceed I would
certainly aim to avoid all that .


On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Drewniak]

Certainly a topic for the front-end standards group, but to give my two
cents:

Many of these new JS libraries, such as React, have some very heavy
dependancies.
React requires JSX which needs to be transpiled into JS, ES6 Class syntax
which needs to be transpiled into ES5, which requires Babel and probably a
task runner like Grunt or Gulp (or webpack), which of course require Node
and NPM... so already you've built a very heavy dependancy chain which
itself needs to be maintained (ex: Gulp 4 is coming with breaking changes)
and all this needs to be integrated into MediaWiki which has its own way of
doing things.

None of that sounds like fun to me, so however you proceed I would
certainly aim to avoid all that .


On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

> This discussion seems exactly what we have a Frontend Standards group for:
> https://www.mediawiki.org/wiki/Front-end_standards_group
> https://phabricator.wikimedia.org/project/profile/1616/
>
> DJ
>
> On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich 
> wrote:
>
> > Hello Wikitext-l,
> >
> > ---
> > TL;DR: The Wikidata team is considering to use a MVVM/Single-State
> solution
> > for Wikidata’s UI. What are requirements and concerns would be important
> to
> > consider?
> > ---
> >
> > Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be
> faded
> > out, we are looking at possible future frameworks or paradigms to build
> our
> > UI on. Our needs are:
> >
> > - Having a sustainable foundation
> > - Being able to handle complex state dependencies (simplest are like: "if
> > element x is in edit mode, set element y to saving mode")
> > - A solution that is easy to learn for beginners and easy to read and
> > reason about for our engineers.
> >
> >
> > State management and data/event propagation goes beyond of what OOUI can
> > provide, as far as I (Jan) know. So an obvious candidate was looking into
> > MVVM solutions of which the most well known is the React library.
> >
> > We had a deeper look at Vue.js which is known for having a large
> community,
> > too, but being easier to understand and not using an additional patent
> > clause in its licensing.
> >
> >
> > We see the following possible advantages:
> >
> > - Better modularization
> > - understandability of our code, in particular reasoning about event- and
> > data-flow
> > - better separation of concerns and testability for:
> > -- HTML templates
> > -- Component interactivity
> > -- Data manipulation
> > -- connection to backend-API
> >
> >
> > - If we use a well documented framework, learning to contribute is much
> > easier compared to software for which there is only auto-generated
> > code-level-docs
> >
> >
> > Here are some answers to obvious questions:
> >
> > 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> > syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> > too) normal HTML templates are used
> >
> > 2) Does that mean that people coming from Object oriented languages will
> > need to learn a whole new paradigm – reactive, pure-functional
> programming?
> > -> While there are some elements of functional programming used in
> > react-like-frameworks, I would (subjectively) say that few additional,
> > totally new knowledge is needed and most can be covered by "take
> > parameters, work with them, return values; don't manipulate non-local
> > values"
> >
> > 3) How does DOM access work? Does this mean no jQuery?
> >
> >
> > -> DOM can be still be directly accessed. Libraries like jQuery can still
> > be reused (even if they might not be necessary in many points any more).
> > However, to change data or dom persistently, you need to tell the library
> > (which is not unusual, afaic)
> >
> >
> > There are also some other concerns:
> >
> > - Should we introduce a new dependency like a framework as Vue?
> > - What would be the process of introducing such a dependency (if we agree
> > on one)?
> > - Can we agree on this (or another?) paradigm for managing complex UIs,
> so
> > that it is not a Wikidata-only solution, but could be used by other
> > Wikimedia projects in the future, too?
> > - How will this work with OOUIjs? OOUI seems to be mainly responsible for
> > creating DOM elements and this actions are usually owned by the MVVM
> > framework. One can use hooks to use libraries like OOUI and such, but it
> > feels like having the same functionality twice. A possible solution would
> > be using OOUI styles and markup but leaving DOM creation to the
> framework.
> >
> >
> > Do you think using Vue (or a similar framework) is an option for us? What
> > are requirements and concerns which would be important?
> >
> >
> > Kind Regards,
> >  Jan
> >
> > --
> > Jan Dittrich
> > UX Design/ User Research
> >
> > Wikimedia Deutschland e.V. | Tempelhofer Ufer 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Derk-Jan Hartman]

This discussion seems exactly what we have a Frontend Standards group for:
https://www.mediawiki.org/wiki/Front-end_standards_group
https://phabricator.wikimedia.org/project/profile/1616/

DJ

On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich 
wrote:

> Hello Wikitext-l,
>
> ---
> TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
> for Wikidata’s UI. What are requirements and concerns would be important to
> consider?
> ---
>
> Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
> out, we are looking at possible future frameworks or paradigms to build our
> UI on. Our needs are:
>
> - Having a sustainable foundation
> - Being able to handle complex state dependencies (simplest are like: "if
> element x is in edit mode, set element y to saving mode")
> - A solution that is easy to learn for beginners and easy to read and
> reason about for our engineers.
>
>
> State management and data/event propagation goes beyond of what OOUI can
> provide, as far as I (Jan) know. So an obvious candidate was looking into
> MVVM solutions of which the most well known is the React library.
>
> We had a deeper look at Vue.js which is known for having a large community,
> too, but being easier to understand and not using an additional patent
> clause in its licensing.
>
>
> We see the following possible advantages:
>
> - Better modularization
> - understandability of our code, in particular reasoning about event- and
> data-flow
> - better separation of concerns and testability for:
> -- HTML templates
> -- Component interactivity
> -- Data manipulation
> -- connection to backend-API
>
>
> - If we use a well documented framework, learning to contribute is much
> easier compared to software for which there is only auto-generated
> code-level-docs
>
>
> Here are some answers to obvious questions:
>
> 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> too) normal HTML templates are used
>
> 2) Does that mean that people coming from Object oriented languages will
> need to learn a whole new paradigm – reactive, pure-functional programming?
> -> While there are some elements of functional programming used in
> react-like-frameworks, I would (subjectively) say that few additional,
> totally new knowledge is needed and most can be covered by "take
> parameters, work with them, return values; don't manipulate non-local
> values"
>
> 3) How does DOM access work? Does this mean no jQuery?
>
>
> -> DOM can be still be directly accessed. Libraries like jQuery can still
> be reused (even if they might not be necessary in many points any more).
> However, to change data or dom persistently, you need to tell the library
> (which is not unusual, afaic)
>
>
> There are also some other concerns:
>
> - Should we introduce a new dependency like a framework as Vue?
> - What would be the process of introducing such a dependency (if we agree
> on one)?
> - Can we agree on this (or another?) paradigm for managing complex UIs, so
> that it is not a Wikidata-only solution, but could be used by other
> Wikimedia projects in the future, too?
> - How will this work with OOUIjs? OOUI seems to be mainly responsible for
> creating DOM elements and this actions are usually owned by the MVVM
> framework. One can use hooks to use libraries like OOUI and such, but it
> feels like having the same functionality twice. A possible solution would
> be using OOUI styles and markup but leaving DOM creation to the framework.
>
>
> Do you think using Vue (or a similar framework) is an option for us? What
> are requirements and concerns which would be important?
>
>
> Kind Regards,
>  Jan
>
> --
> Jan Dittrich
> UX Design/ User Research
>
> Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> http://wikimedia.de
>
> Imagine a world, in which every single human being can freely share in the
> sum of all knowledge. That‘s our commitment.
>
> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/029/42207.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Cyken Zeraux]

Vue.js is becoming quite popular, and is more unrestrictive than other
frameworks of its kind. Laravel is backing it, and overall, though young
for V2, seems quite capable of solving UI problems elegantly.

https://vuejs.org/
https://about.gitlab.com/2016/10/20/why-we-chose-vue/


On Mon, Jan 30, 2017 at 11:25 AM, Bryan Davis  wrote:

> On Mon, Jan 30, 2017 at 10:17 AM, Isarra Yos  wrote:
> > Er, what does this mean? What is MVVM?
>
> A bit of software pattern jargon:
> https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel
>
> > On 30/01/17 13:57, Jan Dittrich wrote:
> >>
> >> Hello Wikitext-l,
> >>
> >> ---
> >> TL;DR: The Wikidata team is considering to use a MVVM/Single-State
> >> solution
> >> for Wikidata’s UI. What are requirements and concerns would be important
> >> to
> >> consider?
> >> ---
> >>
> >> Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be
> faded
> >> out, we are looking at possible future frameworks or paradigms to build
> >> our
> >> UI on. Our needs are:
> >>
> >> - Having a sustainable foundation
> >> - Being able to handle complex state dependencies (simplest are like:
> "if
> >> element x is in edit mode, set element y to saving mode")
> >> - A solution that is easy to learn for beginners and easy to read and
> >> reason about for our engineers.
> >>
> >>
> >> State management and data/event propagation goes beyond of what OOUI can
> >> provide, as far as I (Jan) know. So an obvious candidate was looking
> into
> >> MVVM solutions of which the most well known is the React library.
> >>
> >> We had a deeper look at Vue.js which is known for having a large
> >> community,
> >> too, but being easier to understand and not using an additional patent
> >> clause in its licensing.
> >>
> >>
> >> We see the following possible advantages:
> >>
> >> - Better modularization
> >> - understandability of our code, in particular reasoning about event-
> and
> >> data-flow
> >> - better separation of concerns and testability for:
> >> -- HTML templates
> >> -- Component interactivity
> >> -- Data manipulation
> >> -- connection to backend-API
> >>
> >>
> >> - If we use a well documented framework, learning to contribute is much
> >> easier compared to software for which there is only auto-generated
> >> code-level-docs
> >>
> >>
> >> Here are some answers to obvious questions:
> >>
> >> 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
> >> syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
> >> too) normal HTML templates are used
> >>
> >> 2) Does that mean that people coming from Object oriented languages will
> >> need to learn a whole new paradigm – reactive, pure-functional
> >> programming?
> >> -> While there are some elements of functional programming used in
> >> react-like-frameworks, I would (subjectively) say that few additional,
> >> totally new knowledge is needed and most can be covered by "take
> >> parameters, work with them, return values; don't manipulate non-local
> >> values"
> >>
> >> 3) How does DOM access work? Does this mean no jQuery?
> >>
> >>
> >> -> DOM can be still be directly accessed. Libraries like jQuery can
> still
> >> be reused (even if they might not be necessary in many points any more).
> >> However, to change data or dom persistently, you need to tell the
> library
> >> (which is not unusual, afaic)
> >>
> >>
> >> There are also some other concerns:
> >>
> >> - Should we introduce a new dependency like a framework as Vue?
> >> - What would be the process of introducing such a dependency (if we
> agree
> >> on one)?
> >> - Can we agree on this (or another?) paradigm for managing complex UIs,
> so
> >> that it is not a Wikidata-only solution, but could be used by other
> >> Wikimedia projects in the future, too?
> >> - How will this work with OOUIjs? OOUI seems to be mainly responsible
> for
> >> creating DOM elements and this actions are usually owned by the MVVM
> >> framework. One can use hooks to use libraries like OOUI and such, but it
> >> feels like having the same functionality twice. A possible solution
> would
> >> be using OOUI styles and markup but leaving DOM creation to the
> framework.
> >>
> >>
> >> Do you think using Vue (or a similar framework) is an option for us?
> What
> >> are requirements and concerns which would be important?
>
> I don't know if it would meet all of your requirements, but I would
> suggest at least sitting down with some of the folks who develop and
> maintain OOjs UI () and having
> them help you evaluate the pros and cons of using the same view
> abstraction layer that is used for Visual Editor and Flow, and which
> is already available as a core component in MediaWiki.
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Bryan Davis]

On Mon, Jan 30, 2017 at 10:17 AM, Isarra Yos  wrote:
> Er, what does this mean? What is MVVM?

A bit of software pattern jargon:
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel

> On 30/01/17 13:57, Jan Dittrich wrote:
>>
>> Hello Wikitext-l,
>>
>> ---
>> TL;DR: The Wikidata team is considering to use a MVVM/Single-State
>> solution
>> for Wikidata’s UI. What are requirements and concerns would be important
>> to
>> consider?
>> ---
>>
>> Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
>> out, we are looking at possible future frameworks or paradigms to build
>> our
>> UI on. Our needs are:
>>
>> - Having a sustainable foundation
>> - Being able to handle complex state dependencies (simplest are like: "if
>> element x is in edit mode, set element y to saving mode")
>> - A solution that is easy to learn for beginners and easy to read and
>> reason about for our engineers.
>>
>>
>> State management and data/event propagation goes beyond of what OOUI can
>> provide, as far as I (Jan) know. So an obvious candidate was looking into
>> MVVM solutions of which the most well known is the React library.
>>
>> We had a deeper look at Vue.js which is known for having a large
>> community,
>> too, but being easier to understand and not using an additional patent
>> clause in its licensing.
>>
>>
>> We see the following possible advantages:
>>
>> - Better modularization
>> - understandability of our code, in particular reasoning about event- and
>> data-flow
>> - better separation of concerns and testability for:
>> -- HTML templates
>> -- Component interactivity
>> -- Data manipulation
>> -- connection to backend-API
>>
>>
>> - If we use a well documented framework, learning to contribute is much
>> easier compared to software for which there is only auto-generated
>> code-level-docs
>>
>>
>> Here are some answers to obvious questions:
>>
>> 1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
>> syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
>> too) normal HTML templates are used
>>
>> 2) Does that mean that people coming from Object oriented languages will
>> need to learn a whole new paradigm – reactive, pure-functional
>> programming?
>> -> While there are some elements of functional programming used in
>> react-like-frameworks, I would (subjectively) say that few additional,
>> totally new knowledge is needed and most can be covered by "take
>> parameters, work with them, return values; don't manipulate non-local
>> values"
>>
>> 3) How does DOM access work? Does this mean no jQuery?
>>
>>
>> -> DOM can be still be directly accessed. Libraries like jQuery can still
>> be reused (even if they might not be necessary in many points any more).
>> However, to change data or dom persistently, you need to tell the library
>> (which is not unusual, afaic)
>>
>>
>> There are also some other concerns:
>>
>> - Should we introduce a new dependency like a framework as Vue?
>> - What would be the process of introducing such a dependency (if we agree
>> on one)?
>> - Can we agree on this (or another?) paradigm for managing complex UIs, so
>> that it is not a Wikidata-only solution, but could be used by other
>> Wikimedia projects in the future, too?
>> - How will this work with OOUIjs? OOUI seems to be mainly responsible for
>> creating DOM elements and this actions are usually owned by the MVVM
>> framework. One can use hooks to use libraries like OOUI and such, but it
>> feels like having the same functionality twice. A possible solution would
>> be using OOUI styles and markup but leaving DOM creation to the framework.
>>
>>
>> Do you think using Vue (or a similar framework) is an option for us? What
>> are requirements and concerns which would be important?

I don't know if it would meet all of your requirements, but I would
suggest at least sitting down with some of the folks who develop and
maintain OOjs UI () and having
them help you evaluate the pros and cons of using the same view
abstraction layer that is used for Visual Editor and Flow, and which
is already available as a core component in MediaWiki.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Isarra Yos]

Er, what does this mean? What is MVVM?

On 30/01/17 13:57, Jan Dittrich wrote:

Hello Wikitext-l,

---
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
---

Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:

- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.


State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.

We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.


We see the following possible advantages:

- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API


- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs


Here are some answers to obvious questions:

1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used

2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"

3) How does DOM access work? Does this mean no jQuery?


-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)


There are also some other concerns:

- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.


Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?


Kind Regards,
  Jan




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

Hello Wikitext-l,

---
TL;DR: The Wikidata team is considering to use a MVVM/Single-State solution
for Wikidata’s UI. What are requirements and concerns would be important to
consider?
---

Wikidata’s current UI is built on jQuery UI. Since jQueryUI shall be faded
out, we are looking at possible future frameworks or paradigms to build our
UI on. Our needs are:

- Having a sustainable foundation
- Being able to handle complex state dependencies (simplest are like: "if
element x is in edit mode, set element y to saving mode")
- A solution that is easy to learn for beginners and easy to read and
reason about for our engineers.


State management and data/event propagation goes beyond of what OOUI can
provide, as far as I (Jan) know. So an obvious candidate was looking into
MVVM solutions of which the most well known is the React library.

We had a deeper look at Vue.js which is known for having a large community,
too, but being easier to understand and not using an additional patent
clause in its licensing.


We see the following possible advantages:

- Better modularization
- understandability of our code, in particular reasoning about event- and
data-flow
- better separation of concerns and testability for:
-- HTML templates
-- Component interactivity
-- Data manipulation
-- connection to backend-API


- If we use a well documented framework, learning to contribute is much
easier compared to software for which there is only auto-generated
code-level-docs


Here are some answers to obvious questions:

1) Does using a MVVM mean we need to write mixed JS/CSS/HTML in a new
syntax? (aka JSX)? -> No, it is possible, but for most frameworks (Vue,
too) normal HTML templates are used

2) Does that mean that people coming from Object oriented languages will
need to learn a whole new paradigm – reactive, pure-functional programming?
-> While there are some elements of functional programming used in
react-like-frameworks, I would (subjectively) say that few additional,
totally new knowledge is needed and most can be covered by "take
parameters, work with them, return values; don't manipulate non-local
values"

3) How does DOM access work? Does this mean no jQuery?


-> DOM can be still be directly accessed. Libraries like jQuery can still
be reused (even if they might not be necessary in many points any more).
However, to change data or dom persistently, you need to tell the library
(which is not unusual, afaic)


There are also some other concerns:

- Should we introduce a new dependency like a framework as Vue?
- What would be the process of introducing such a dependency (if we agree
on one)?
- Can we agree on this (or another?) paradigm for managing complex UIs, so
that it is not a Wikidata-only solution, but could be used by other
Wikimedia projects in the future, too?
- How will this work with OOUIjs? OOUI seems to be mainly responsible for
creating DOM elements and this actions are usually owned by the MVVM
framework. One can use hooks to use libraries like OOUI and such, but it
feels like having the same functionality twice. A possible solution would
be using OOUI styles and markup but leaving DOM creation to the framework.


Do you think using Vue (or a similar framework) is an option for us? What
are requirements and concerns which would be important?


Kind Regards,
 Jan

-- 
Jan Dittrich
UX Design/ User Research

Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
http://wikimedia.de

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l