Hi John, Thanks for sharing your evaluation and your experiences – and, in, particular, working examples.
> So I'm curious... for something like Wikidata which is so different from > standard Mediawiki instances =(the rendering and editing experiences are > fundamentally different) what's stopping you from adding a layer on top of > the stack and using Mediawiki as a black box for storage and API... at > least as an alternative editing experience? I am not sure (I am not very deep into our current code base), but if I am right that is pretty much what is already done, anyway in Wikibase: Its server part exposes an api to which we push the data. Jan 2017-02-01 2:11 GMT+01:00 Jon Robson <[email protected]>: > I think at this point Mediawiki's frontend stack and its dependencies on RL > and supporting user gadgets don't lend itself well to frameworks like React > or Vue. With regards to moving away from jQuery UI your path of least > resistance inside MediaWiki feels like it might be to use a library such as > Redux for managing your state and OOjs UI for rendering the UI components. > > Frameworks by definition provide you with rules and constraints to prevent > you from writing code in bad ways leading you to easier to work with code. > The MediaWiki ecosystem doesn't do well with constraints - it's about > experimenting. > > That aside, I'm curious if you have considered a different approach. One > big issue we commonly see in the reading web team in working with > MobileFrontend and our apps team who depend on our APIs is that the lines > of model and view get blurred frequently. There are certain things our API > doesn't do and that we workaround in PHP code - the only place we can do > this. I was a little worried about this, so as a side project I explored > how difficult it was to render the existing mobile site without MediaWiki's > PHP layer. I built a progressive web app (PWA) using React (just a > personal preference but any framework could be used to do the same). The > result is deployed on labs: https://trending.wmflabs.org > and the code on Github: https://github.com/jdlrobson/weekipedia > > At first, this may seem like a lot of work but it wasn't. I reused > Mediawiki > code where possible (packaging up into npm libraries) and what I found was > feature development became extremely easy the more that I implemented as > reuse was extremely useful within the framework. > > The React web app now has feature parity with the mobile site - it looks th > esame, you can login support via OAuth (thanks to the awesome work from > Gergő > Tisza and co), there's i18n support > <https://trending.wmflabs.org/he.wikipedia/%D7%99%D7%A9%D7% > A8%D7%90%D7%9C?uselang=he>, > you can edit.... you can view history/diffs etc etc... we've been using it > for user testing. Since things got so easy I even got carried away and > built features I've wanted forever ;-) [1]: > > If I exclude the time I spent improving Mediawiki REST APIs to support this > app I reckon building this took about a month of work (and that wasn't even > full time). Yes, the solution had many trade-offs... My app cannot run > gadgets or CSS/JS from the Mediawiki namespace and certain pages which > require additional JavaScript e.g. maps/pages with math do not load that Js > - but I see those problems as easily solvable and I value the benefits I > experienced through working within a well-documented framework... > > So I'm curious... for something like Wikidata which is so different from > standard Mediawiki instances =(the rendering and editing experiences are > fundamentally different) what's stopping you from adding a layer on top of > the stack and using Mediawiki as a black box for storage and API... at > least as an alternative editing experience? > > Having complete APIs and enabling our future and present community members > to be able to build things like this easily should be our goal as > engineers. > > It's worth pointing out that Chrome has plans to allow developers to > package web apps as installable APKs (see > https://joreteg.com/blog/installing-web-apps-for-real). What this means is > with a bit of configuration I could update my PWA to override all visits to > Wikimedia domains and steal traffic. I think when this happens lots of > developers will be jumping on this opportunity. This is great for > distributing our knowledge, not so good about keeping a unified experience > for all our visitors. I'd rather we were ahead of that trend rather than > lagging behind. > > Happy to chat more if you find this conversation interesting. I've covered > a lot here... :) > [1] e.g. > * infinite random - https://trending.wmflabs.org/en/wiki/Special:Random > * the trending work turned into a REST API that we're still experimenting > with and offline support. > * cross-wiki search - > https://trending.wmflabs.org/en.wikiquote/Special:Search/San%20Francisco > > > On Tue, 31 Jan 2017, 5:06 a.m. Jan Drewniak, <[email protected]> > wrote: > > Certainly a topic for the front-end standards group, but to give my two > cents: > > Many of these new JS libraries, such as React, have some very heavy > dependancies. > React requires JSX which needs to be transpiled into JS, ES6 Class syntax > which needs to be transpiled into ES5, which requires Babel and probably a > task runner like Grunt or Gulp (or webpack), which of course require Node > and NPM... so already you've built a very heavy dependancy chain which > itself needs to be maintained (ex: Gulp 4 is coming with breaking changes) > and all this needs to be integrated into MediaWiki which has its own way of > doing things. > > None of that sounds like fun to me, so however you proceed I would > certainly aim to avoid all that <https://getpocket.com/a/read/1434444086>. > > > On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman < > [email protected]> wrote: > > > This discussion seems exactly what we have a Frontend Standards group > for: > > https://www.mediawiki.org/wiki/Front-end_standards_group > > https://phabricator.wikimedia.org/project/profile/1616/ > > > > DJ > > > > On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich <[email protected] > > > > 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 > > > [email protected] > > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > -- > Jan Drewniak > UX Engineer, Discovery > Wikimedia Foundation > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ > Wikitech-l mailing list > [email protected] > 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
