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?
Context: 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 reactive ModelViewViewModel solutions like the React or Vue library, which combine with their respective single state libs, namely redux and vuex. (The MVVM would manage the DOM, Templates, event propagation, component composition, while the single state lib would manage the state/model and its connection to the backend)
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
Such idea poses the following questions:
- 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.
- One could also combine OOUIjs with a single state lib like Redux. (as suggested by @Jhernandez) However, I don't know how well suited OOUI is to be combined e.g. with Redux.
FAQ on reactive/single state frameworks
- Does using a reactive/single state, React-like solution mean we need to write mixed JS/CSS/HTML in a new syntax? (aka JSX)? → No, it is possible, but for many frameworks (e.g. Vue), HTML templates are used.
- 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"
- 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)
- Don't such libraries need much tooling? → It depends… 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. (thanks to @Jdrewniak for asking this)