Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Krinkle]

On Mon, Jan 30, 2017 at 1:57 PM, Jan Dittrich 
 wrote:

>
> 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.


If considering React, I would start by recommending Preact instead.
Especially since we're starting clean, we won't need any compat layer (and
yet feels similar enough to existing users).

https://preactjs.com/


On Wed, Feb 1, 2017 at 1:11 AM, Jon Robson  wrote:

>
> Redux for managing your state and OOjs UI for rendering the UI components.
>


Indeed, Redux is also a good option.

-- Timo
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOjs UI 0.19.0 release (breaking change)

[Volker E.]

Hello everyone,

we've released OOjs UI 0.19.0 today. It will be in MediaWiki core from
1.29.0-wmf.11, which will be deployed to Wikimedia production in the
regular train, starting on
Tuesday 07 February. As there are three breaking changes in this
release, at least
nominally, please carefully look over them to see if they affect your code.

Breaking changes since last release:

* ButtonWidget: Switch `box-sizing` over to `border-box` (Volker E)
Switching `box-sizing` to `border-box` value, making it easier
to calculate sizes and centralizing occurrences already in use
by widgets with buttons. It also aligns with the current way other
widgets are internally calculated. A rare, though possible side-effect could be
that different sized buttons are changing the layout slightly. If you run
into broken layouts with buttons, you'll need to adapt the size,
`padding` and `border`.

* LabelElement: Drop no-op fitLabel() method. (James D. Forrester)
This was a deprecated no-op since v0.16.0. Note that ProcessDialog#fitLabel()
still exists and is not a no-op. We're now removing the old function;
if you're still using it, you'll need to switch over.

* WindowManager: Error if `.static.name` is not defined when adding a
window (Bartosz Dziewoński)
WindowManager was already emitting a warning if `.static.name` was not defined,
now it throws an error. If you're still adding windows without it
defined, you'll need to
do so.


Deprecations since last release:
* MessageDialog: Default 'verbose' option to true (James D. Forrester)
This was an arbitrary styling choice that eventually became the
default in our designs;
rather than keep actively choosing it, instead let's just do it always.
We'll remove the ability to choose compact styling in an upcoming release.

* icons: Deprecate the 'beta' and 'ribbonPrize' icons (James D. Forrester)
If you use them, be prepared that they'll removed from the libary in
an upcoming release.

* icons: Rename '*Undo' to 'un*' (James D. Forrester)
For consistency:
** blockUndo is now unBlock
** flagUndo is now unFlag
** trashUndo is now unTrash
This fits in with the pre-existing unLock and unStar patterns.

* icons: Rename 'betaLaunch' to 'logoWikimediaDiscovery', move pack
(James D. Forrester)

Additional details are in the full changelog[0]. If you have any further queries
or need help dealing with breaking changes, please let me know. As
always, a general
set of library documentation is available on mediawiki.org[1], and there is some
comprehensive generated code-level documentation and interactive demos hosted on
doc.wikimedia.org[2].

[0] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md
[1] - https://www.mediawiki.org/wiki/OOjs_UI
[2] - https://doc.wikimedia.org/oojs-ui/master/


Best,
Volker

--
Senior UX Engineer, Editing
Wikimedia Foundation

volker.e [at] wikimedia | @Volker_E

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] So many search options! :)

[Deborah Tankersley]

Hello,


*Apologies in advance for the cross-post!*


The Discovery Search Team would like to open the conversation about some
future improvements to search that we’re considering. We’ve been thinking
about how to display additional results that might be interesting and
helpful to our users, and we’d like to get feedback on these plans.

Currently, we’re busy with our quarterly goals
 of
upgrading to ElasticSearch 5 ,
setting up A/B tests for sister project search results
, and researching new language
analyzers. [1] [2] [3] This means that the new work discussed here won’t be
started for a few months, leaving lots of time to give input. :-)

Over the last year, we’ve worked hard to reduce the zero results rate
(which measures how many queries get zero results returned) so that even
really obscure queries can get useful results. To that end, we have made a
number of enhancements to the search system: stripping question marks
 (replacing with spaces)
and language
detection  (cross language
searching). [4] [5]

What we’d like to do now is to provide additional results: helpful
suggestions and links to articles - or additional search results pages - to
aid in finding information that users are looking for. These additional
results will most likely be placed near the bottom of the page, at the end
of the list of original results returned. We’ll also make these additional
results available to the search API.

In gathering these additional results, we will use several techniques that
have been researched but not yet put into production; some of these methods
include

wrong keyboard layout, quote stripping, and sister wiki searching
(cross-project). [6]

We would love to have your comments and/or suggestions posted on the talk
page

of the ‘So Many Search Options
’
page or on the Phabricator task .
[7] [8] [9]

Cheers,

The Discovery Search Team

[1] https://www.mediawiki.org/wiki/Wikimedia_Engineering/2016-17_Q3_Goals
[2] https://phabricator.wikimedia.org/T154501
[3] https://phabricator.wikimedia.org/T145917
[4] https://phabricator.wikimedia.org/T133711
[5] https://phabricator.wikimedia.org/T149316
[6]
https://www.mediawiki.org/wiki/Wikimedia_Discovery/So_Many_Search_Options
[7]
https://www.mediawiki.org/wiki/Talk:Wikimedia_Discovery/So_Many_Search_Options
[8]
https://www.mediawiki.org/wiki/Wikimedia_Discovery/So_Many_Search_Options
[9] https://phabricator.wikimedia.org/T156019

--
deb tankersley
irc: debt
Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2017-02-10 Scrum of Scrums meeting notes

[Olga Vasileva]

> What exactly is "PagePreviews"?
>
> From
> <
> https://www.mediawiki.org/w/index.php?title=Special:Search=pagepreviews
> >
> it looks to be the second renaming of the Popups extension/Hovercards,
> except this time it's named very similarly to the actual "show preview"
> feature...? Is there a rationale somewhere about the renaming?
>

Hi - sorry for the confusion!  The name change came as one of the results
from the qualitative testing

on the feature.  Since not all of our users know the definition of "hover",
the previous name was inappropriate.  "Page previews" was the most common
name with which the tested users referred to the feature naturally.

There's also a (very) short note on the beta feature page

explaining the rationale.

- Olga
-- 
Olga Vasileva // Product Manager // Reading Web Team
https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2017-02-10 Scrum of Scrums meeting notes

[Legoktm]

Hi,

On 02/01/2017 11:03 AM, Grace Gellerman wrote:
> == Product ==
> === Reading ===
>  Web 
> ** PagePreviews schema changes.
> ** Ongoing work towards enabling PagePreviews to use the RESTBase endpoint.
> * Next week: https://phabricator.wikimedia.org/project/view/2460/

What exactly is "PagePreviews"?

From

it looks to be the second renaming of the Popups extension/Hovercards,
except this time it's named very similarly to the actual "show preview"
feature...? Is there a rationale somewhere about the renaming?

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2017-02-10 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-02-01

= 2017-02-01 =

== Product ==

=== Reading ===

 Web 
* Last week:
** Finished up the majority of the branding work. Unfortunately, the specs
were not clear from the beginning,
so we assumed that changes needed to be done on mobile web stable. Now
we're looking
at ways to deploy these changes to a smaller wiki (as opposed to every
wiki, in beta mode only).
** Related Pages can now be displayed to a subset of users.
** PagePreviews schema changes.
** Ongoing work towards enabling PagePreviews to use the RESTBase endpoint.
* Next week: https://phabricator.wikimedia.org/project/view/2460/
** Deploy related pages to mobile french wikipedia stable channel
** More branding work.
** Try and finish using the RESTBase endpoint (/page in PagePreviews

Android
* Last week:
** Trying to wrap up Wikidata description editing for a beta
https://phabricator.wikimedia.org/T155917
** Wikidata description eventlogging in code review
** Wikidata description UI and notification polish
** Wikidata description edits will use Wikipedia page permissions in
Android client
** Custom cache implementation replaced with standard library implementation
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** Work towards release of Wikidata description editing
** Continue on improved offline experience

Reading Infrastructure
* working on TemplateStyles, ORES architecture review
* TemplateStyles RfC: https://phabricator.wikimedia.org/T155813
** seeking input especially from Parsing, VE, Performance, Services
* not blocking
* blocked:
** WMDE on the last API i18n patch before we can move to hard deprecation:
https://gerrit.wikimedia.org/r/#/c/321464/

= Mobile Content Service (MCS) =
* Kanban Board: https://phabricator.wikimedia.org/project/view/2445/
* Working on:
** Added regression testing of JSON output
** New endpoint for 'On this day' (aka. Anniversaries).

 iOS native app 
* Last Week
** Continued work on 5.4, released to Alpha channel
https://phabricator.wikimedia.org/project/view/2326/
*** Initial UI for Places
*** API integration for places
*** Continued work on login
* This week
** Continue work on 5.4
*** UI refinements for Places, Login updates

=== Editing ===
 Collaboration 
* Blocked - Spec for ReviewStream/state table. We're working to resolve
this with Research and Analytics.
* Blocking - None
* Updates:
** RC Filters UI:
*** Add 'remove' and 'restore defaults' to filter list
*** Read default states of filters
** Echo and Flow bug fixes

== German Technical Wishlist ==
* Working on 2ColConflict resolution UI.
* Looking for an other name for the "2ColConflict" extension.
* Working on redesigning the form on top of Special:Search.

== Wikidata ==
* Focussing heavily on Lexeme entity type for Wiktionary
https://phabricator.wikimedia.org/T146662
* Adding support for the Commons Data: namespace
https://phabricator.wikimedia.org/T57549
* Investigating our usage of customized UsageException, getting a better
understanding of what needs to be done https://gerrit.wikimedia.org/r/327704

=== Community Tech ===
* Blocking: None
* Blockers: Update page_assessments_projects schema for subprojects in
production https://phabricator.wikimedia.org/T156305
* Updates:
** Pageviews app updates:
*** It now supports the new monthly endpoint recently rolled out by
Analytics
*** Shows article classifications (class, quality etc.) via PageAssessments
API
*** New tool: https://tools.wmflabs.org/userviews/ to see pageviews of all
the pages created by a user
** Continued work on Special:RangeContributions page to support viewing
contributions across an IP range: https://phabricator.wikimedia.org/T145912
** Continued work on cookie blocking for anonymous users
https://phabricator.wikimedia.org/T152462

== Technology ==

=== Security ===
* Security Reviews:
** OIT Apps
** Newsletter extension
* MediaWiki 1.28.1/1.27.2/1.23.16 security release is being planned with
RelEng; no date schedule yet

=== Services ===
* Blockers: none
* Updates:
** Revision support in mobile-sections endpoints
***
https://en.wikipedia.org/api/rest_v1/#!/Mobile/get_page_mobile_sections_title_revision
** OriginalImage property in the summary endpoint
***
https://en.wikipedia.org/api/rest_v1/#!/Page_content/get_page_summary_title
** Ongoing discussions, please participate
*** Thumbnailing API: https://phabricator.wikimedia.org/T66214
*** Language variants support in REST API:
https://phabricator.wikimedia.org/T154190

=== Technical Operations ===
* '''Blocked''':
** None
* '''Blocking''':
** None
* Updates:
** Filippo taking over SoS from Alex for TechOps
** TechOps working on the DC preparation goal mostly

=== Fundraising Tech ===
* Getting PayPal express checkout integration ready for external test
* Making it easy to purge a single CentralNotice banner from all the
caches  https://phabricator.wikimedia.org/T154954
* Import 

Re: [Wikitech-l] CREDIT next week, and a survey

[Adam Baso]

Reminder: this is in about 25 minutes.

On Fri, Jan 27, 2017 at 12:33 PM, Adam Baso  wrote:

> Hi everybody!
>
> As a reminder the CREDIT Showcase is next week on Wednesday,
> 1-February-2017 (see https://www.mediawiki.org/wiki/CREDIT_showcase for
> details). Also, as I mentioned previously we're conducting a survey about
> CREDIT. We'd appreciate your feedback! Here is a link to the survey (which
> is hosted on a third-party service), and, for information about privacy and
> data handling, the survey privacy statement.
>
> https://docs.google.com/a/wikimedia.org/forms/d/e/
> 1FAIpQLSedAtyPfcEhT6OVd26Y-3v_jm3yM3ShvMqgAWBUPxb24u_Y9g/viewform
>
> https://wikimediafoundation.org/wiki/CREDIT_Feedback_
> Survey_Privacy_Statement.
>
> This email is being sent to several mailing lists in order to reach
> multiple audiences. As always, please follow the list link at the very
> bottom of this email in case you want to manage your list subscription
> options such as digest, unsubscribe, and so on.
>
> And, as usual, if you'd like to share the news about the upcoming CREDIT,
> here's some suggested verbiage.
>
> *Hi *
>
> *I hope all is well with you! I wanted to let you know about CREDIT, a
> monthly demo series that we’re running to showcase open source tech
> projects from Wikimedia’s Community, Reading, Editing, Discovery,
> Infrastructure and Technology teams. *
>
> *CREDIT is open to the public, and we welcome questions and discussion.
> The next CREDIT will be held on February 1st at 11am PT / 2pm ET / 19:00
> UTC. *
>
> *There’s more info on MediaWiki
> , and on Etherpad
> , which is where we take notes and
> ask questions. You can also ask questions on IRC in the Freenode chatroom
> #wikimedia-office (web-based access here
> ). Links to
> video will become available at these locations shortly before the event.*
>
> *Please feel free to pass this information along to any interested folks.
> Our projects tend to focus on areas that might be of interest to folks
> working across the open source tech community: language detection,
> numerical sort, large data visualizations, maps, and all sorts of other
> things.*
>
> *If you have any questions, please let me know! Thanks, and I hope to see
> you at CREDIT.*
>
> *YOURNAME*
>
>
> Thanks!
>
> Adam Baso
> Director of Engineering, Reading
> Wikimedia Foundation
> ab...@wikimedia.org
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

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 :

> 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
>  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, 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

>
> Regardless of UI framework, for state management I'd strongly recommend
> using redux , and after the fact pair it with
> whatever UI framework you prefer.


Yes,  that (referred to as "State management" or so in my mail) may have
been a bit buried under all the other stuff, but it is something I think of
as a good way too (regardless of the actual DOM generation)

A college of mine (not on the Wikidata team) has used it, too, and we were
both happy.

we can set some time to discuss and show you how
> we're using it (we still need to write documentation about it so that's why
> I can't point you to much now).
>

Thanks! I will get back to the team with all the infos I get here and then
decide about further information needs, but it is pretty likely that we
need some info there. I'll get back to this.


Jan

2017-02-01 7:58 GMT+01:00 Joaquin Oltra Hernandez 
:

> Hi Jan,
>
> Regardless of UI framework, for state management I'd strongly recommend
> using redux , and after the fact pair it with
> whatever UI framework you prefer. Here are some of the reasons for using
> it:
>
>
>- Very popular and widely used
>- Excellent documentation (see http://redux.js.org/)
>- Plenty of educational materials (articles, tutorials, videos,
>examples, and the docs site itself)
>- Really small size (<2kb)
>- Architecture that forces a single source of true state tree with clear
>state transitions
>- Eases unit testing of the system with the clear boundaries and state
>separation
>- Amazing developer tools making the store a full event sourcing system
> allowing for
>great introspection into the system, importing/exporting event logs,
> time
>travelling through the action log, etc.
>
> Here are some reasons for not using it:
>
>- It is different from what we usually do, which means there is some
>ramp up time and learning to do from people that are used to what is
>usually done.
>
> I personally think it is very worth it, given it imposes a clear separation
> between the business logic and state manipulation and the UI and side
> effects (like in the boundaries talk
> ). If you are
> interested let me know and we can set some time to discuss and show you how
> we're using it (we still need to write documentation about it so that's why
> I can't point you to much now).
>
> Cheers.
>
> On Mon, Jan 30, 2017 at 2:57 PM, Jan Dittrich 
> 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 

Re: [Wikitech-l] MVVM/Single-State solution for our UIs?

[Jan Dittrich]

> Many of these new JS libraries, such as React, have some very heavy
> dependancies.


Yes, this is true. The usage of such dependencies is often not connected to
the way such frontends work, though. E.g. vue can be used without a loader
and does not need an extra JSX compiler.
It is often used with a loader (webpack, mostly), because many people seem
to prefer it and it enables you to structure your code in
single-component-files, which I admit, while disliking the dependency, is
very comfortable imho.

Jan



2017-01-31 14:05 GMT+01:00 Jan Drewniak :

> 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 .
>
>
> On Tue, Jan 31, 2017 at 11:13 AM, Derk-Jan Hartman <
> d.j.hartman+wmf...@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  >
> > 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