> > 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 <jhernan...@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.dittr...@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@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 > -- 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
