date:20170303

[Wikidata-bugs] [Maniphest] [Commented On] T157014: CONSULTATION/PLAN: Managing Complex State and GUI on MediaWiki (e.g. for Wikidata/Wikibase UI)

2017-03-03 Thread Milimetric

Milimetric added a comment.
@Jan_Dittrich this is exciting. We're also looking at Vue.js for the Wikistats 2.0 rewrite. We have to write a prototype and make sure it performs the way we need, so we haven't decided yet but we have similar questions and concerns. We are coming from knockout, so we have a lot of experience with MVVM. I can give some highlights here, but first I want to say:

If you decide to go with Vue.js, I will happily volunteer as much time as I can every week to work on this UI with you. I've been waiting and hoping that our front ends embrace a more mainstream library so I can contribute, and I'm certain that many other developers out there in the world of Open Source feel the same. I have respect for particular pieces of OOJS, such as the sophisticated i18n and RTL work, but it's fighting an impossible battle of attracting real wide scale Open Source collaboration. Vue is modular, and plugins that handle i18n exist. Ideally we can make these better by incorporating the OOJS work in this area. Both are licensed under MIT, so that's not a problem. I think we could of course also use the standard style as defined by @Volker_E and examine how tricky it would be to integrate OOJS UI (not trivial, which is one of the problems: lack of modularity).

From our experience with MVVM and reactive programming, here are my main take-aways:

modularity and testability is fantastic. Having a pure view model that just manages data is inherently easy to test. You set observable properties and check that computed properties are set as expected.
the mentality is different, but closer to the spirit of "manage data, not code". This can take some time getting used to, and it's especially tricky in Knockout because it's not opinionated at all. This was one of the main reasons for us to consider moving to Vue. More opinionated frameworks, if careful, can be easier to learn because there are not as many wrong choices to make.
there is plenty of support on sites like stackoverflow. People sometimes worry that if they don't use React or the other most popular framework of the day they won't be able to find answers to their questions. But even knockout, which has a fairly small user base, has a very nice community of people that will help you out and a good database of topics that have already been covered. Knockout and vue.js are also just so simple that you can read the source and understand how they work pretty quickly.

And finally my quick thoughts on your FAQ:

Does using a reactive/single state, React-like solution mean we need to write mixed JS/CSS/HTML in a new syntax? (aka JSX)? → Html templates are possible, as already stated, but Vue.js "mixed" single file components are much more cleanly separated than React's JSX approach. I dislike JSX aesthetically but have liked Vue's single file components so far. They have good integration with vim which helps.
Does that mean that people coming from Object oriented languages will need to learn a whole new paradigm – reactive, pure-functional programming? → I would add to the already good answer that being very conscious of function scope is useful. For example, arrow functions can't be used in some situations in Vue.js because their context is the parent context and that can be undesirable when creating a view model and expecting the context to be that view model.
How does DOM access work? Does this mean no jQuery? → Honestly, you will love this after a short while. You can of course access the DOM if you wish, and Vue.js has a nice rich component lifecycle that lets you hook into different phases of rendering, where you have access to the DOM. But it is really relaxing to separate DOM access from data management, it's the main reason MVVM is popular.
Don't such libraries need much tooling? → answer given is good. Knockout definitely depends on a lot more tooling than Vue, and I think the Vue creators aimed at directly addressing this problem. There are well thought-out plugins for routing and validation. Though I will say the validation plugins had some bugs, so that's something to consider: some of the ecosystem is still catching up to Vue 2.0.
TASK DETAILhttps://phabricator.wikimedia.org/T157014EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MilimetricCc: Milimetric, Prtksxna, Fjalapeno, phuedx, Jdlrobson, siddharth11, Capt_Swing, TheDJ, Jdforrester-WMF, SBisson, WMDE-leszek, Volker_E, Krinkle, gabriel-wmde, Jonas, thiemowmde, Lydia_Pintscher, Jan_Dittrich, Jhernandez, Jdrewniak, Aklapper, SamanthaNguyen, JGirault, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

41 matches

Mail list logo