Page MenuHomePhabricator

Evaluate OOUI integration with vue.js
Open, MediumPublic

Description

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.

NOTE: This is not a blocker for deployment, it's a criterion for adopting vue.js for MediaWiki frontend development in general.

Event Timeline

daniel created this task.Jun 6 2017, 2:31 PM

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.

daniel added a comment.Jun 6 2017, 6:03 PM

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.

Lydia_Pintscher triaged this task as Medium priority.Jun 11 2017, 4:43 PM
Lydia_Pintscher moved this task from incoming to ready to go on the Wikidata board.
Volker_E renamed this task from Evaluate OOUI.js integration with vue.js to Evaluate OOjs UI integration with vue.js.Jun 28 2017, 4:09 PM
Volker_E added a project: OOUI.
Volker_E added a subscriber: Volker_E.
SBisson added a subscriber: SBisson.Dec 1 2017, 4:00 PM
Volker_E renamed this task from Evaluate OOjs UI integration with vue.js to Evaluate OOUI integration with vue.js.Jan 17 2018, 12:47 AM
Volker_E updated the task description. (Show Details)
Addshore added a subscriber: Jdforrester-WMF.
Addshore added a subscriber: Addshore.
TheDJ added a subscriber: TheDJ.Jul 30 2018, 11:20 AM

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.