It is best practice to rely on OOUI standard widgets when developing user interfaces for Wikimedia products. Ideally, if we want to use vue.js for state management / value binding, this should be possible using these standard widgets.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Lydia_Pintscher | T167134 Blockers for using the vue.js framework for Wikibase on the Wikimedia cluster | |||
| Declined | None | T167145 Evaluate OOUI integration with vue.js |
I would say it depends on the exact component we might want to use, but it is possible.
Here is example of jQuery widget integration (OOUI.js widgets are conceptually similar): https://vuejs.org/v2/examples/select2.html
Example of Wikibase widget integration: https://gerrit.wikimedia.org/r/#/c/346765/
…rely on OOUI.js standard widgets…
I would question that it needs to be the OOUI code that creates the widgets – most important is that the Widgets we create *look* and *behave* like the OOUIjs widgets and that we don't need to maintain too much in parallel in the long run (If it makes sense to wrap, fine with me, and I also think that is the agreed-on strategy but we should not forget that there might be other possibilites)
PS.: Wrapping seems an OK thing; in contrast, to let vuex do the state and OOUIjs the view part of MVC was tried and as far as I remember it was not very great.
Quote from the notes taken at the discussion at the Vienna hackathon:
A possible approach is to wrap OOUI widgets in Vue components. This would incur a slight performance penalty as data flowing towards the widgets would have to be touched twice (once by Vue and once by OOJS. Events flowing back out of the widgets would be watched roughly the same way whether they were rendered by Vue directly or through OOUI. However the big pain point right now is that OOUI is not modularized at all. There is no explicit dependency graph between the widgets and the parents and utilities they depend on. So currently it’s only feasible to import the whole library at once. This is even worse because it needs global scope which implies hacky script-loader solutions in modern build systems like webpack. I (Dan Andreescu) have an outstanding ask to the OOUI team to modularize the components but so far I haven’t heard back anything positive. For my purpose, using OOUI in Wikistats 2.0, this is a non-starter.
P.S. with the browser space slowly seeming to adapt custom elements v1, I thought https://karol-f.github.io/vue-custom-element/ https://alligator.io/vuejs/custom-elements/ was rather interesting. Especially if that can be combined with serverside rendering of non-JS fallback content as we currently have with OOUI.
I assume this ticket should be closed nowadays? Its parent has been closed for two years.