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 jrobson@wikimedia.org:
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, jdrewniak@wikimedia.org 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 < d.j.hartman+wmf_ml@gmail.com> 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 <jan.dittrich@wikimedia.de
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:
- 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
- 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)
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jan Drewniak UX Engineer, Discovery Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l