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(a)wikimedia.org>rg>:
> 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(a)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(a)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(a)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:
> > >
> > > 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
> > > Wikitech-l(a)lists.wikimedia.org
> > >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l(a)lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Jan Drewniak
> UX Engineer, Discovery
> Wikimedia Foundation
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
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.