Regardless of UI framework, for state management I'd strongly recommend
using redux <http://redux.js.org/>, 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 <jhernandez(a)wikimedia.org>
:
> Hi Jan,
>
> Regardless of UI framework, for state management I'd strongly recommend
> using redux <http://redux.js.org/>, 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
> <https://msdn.microsoft.com/en-us/library/dn589792.aspx> 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
> <https://www.destroyallsoftware.com/talks/boundaries>). 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 <jan.dittrich(a)wikimedia.de>
> 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(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
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.