Page MenuHomePhabricator

[Epic] Migration of front-end modules to Vue.js components
Open, MediumPublic

Description

As stated in T241180: RFC: Adopt a modern JavaScript framework for use with MediaWiki VueJS was chosen as the main UI framework to evolve the front-end architecture of MW core. The adoption of it on MW extensions/skins is not mandatory and there isn't a clear dead line for the transitioning. Still it seems a good idea to anticipate the move. This task is open to gather the team thoughts on starting the migration to Vue.js of some of the Growth Extension front-end modules.

GrowthExperiments client module candidates
A list of module candidates to be migrated to Vue, take in account that SSR ( Server side rendering ) is still in a prototype phase T286963: Prototype a Vue SSR implementation using a Node service.

OOUI components GrowthExperiments is using and need a Codex replacement

Links

Related Objects

StatusSubtypeAssignedTask
OpenSgs
In ProgressNone
ResolvedSgs
OpenNone
ResolvedSgs
OpenNone
ResolvedSgs
OpenNone
ResolvedBUG REPORTSgs
ResolvedBUG REPORTUrbanecm_WMF
ResolvedSgs
ResolvedBUG REPORTSgs
ResolvedBUG REPORTSgs
In ProgressSgs
ResolvedBUG REPORTSgs
ResolvedBUG REPORTSgs
ResolvedBUG REPORTSgs
StalledNone
OpenNone
ResolvedSgs
OpenNone
ResolvedSgs
ResolvedSgs
ResolvedSgs
StalledNone
OpenNone

Event Timeline

kostajh added a project: Epic.
kostajh updated the task description. (Show Details)

After looking deeper into the different JS I think the complete migration of all our existing JS to Vue.js code is complex because many of the current code abstractions and entities do not fit well in a component approach framework like Vue. IMO this task should be marked as an EPIC and sliced into several.

Some challenges we may face are:

  • Have a clear server-side strategy. Until now we use PHP to serve HTML then enhance it with JS. We can continue to do so but we need to come up with a solution for replacing the OOUI infuse mechanism
  • OOUI components and ours built on top would ideally use the new WM Design System Codex which is still in development
  • New Codex and old OOUI components won't have the same HTML structure so our LESS code will need to change accordingly

However there are several actions that we could make to modernize our front-end codebase which would facilitate a later adoption of Vue. These are some:

For anyone interested here's an attempt of refactoring the help panel button to a Vue component.

After looking deeper into the different JS I think the complete migration of all our existing JS to Vue.js code is complex because many of the current code abstractions and entities do not fit well in a component approach framework like Vue. IMO this task should be marked as an EPIC and sliced into several.

Some challenges we may face are:

  • Have a clear server-side strategy. Until now we use PHP to serve HTML then enhance it with JS. We can continue to do so but we need to come up with a solution for replacing the OOUI infuse mechanism

I found prototypes for a Node service (T286963) and V8JS (T286966), but I'm not sure what the timeline is for first-class server-side rendering support.

For some of our features, we don't need to think about server-side rendering. For example:

  • help panel button (simple enough that we should be able to live with code duplication)
  • help panel (all client-side)
  • mentor dashboard overview module (no server-side rendering currently)
  • suggested edits task type and topic filters
  • post-edit dialog
  • OOUI components and ours built on top would ideally use the new WM Design System Codex which is still in development
  • New Codex and old OOUI components won't have the same HTML structure so our LESS code will need to change accordingly

However there are several actions that we could make to modernize our front-end codebase which would facilitate a later adoption of Vue. These are some:

Yes, I think the main thing we need to know is how adopting Vue for e.g. suggested edits would impact the userbase of growth features in countries / locations where IE11 usage is relatively high.

  • Create unit tests for existing JS business logic

+1, a good first step would be to catalog what is important for us to test and perhaps group by priorities so we can start making progress on this.

  • Start using and refactoring modules to ES6 (based on IE11 support decision we could use a build step in case we want to transpile to ES5)

This is complicated (see T279108 and T199004). We could work around that by committing the artifacts to the repo. I've not been excited about that approach so far, but if there's good arguments for doing so, I'm open to doing that.

  • De-couple JS code as much as possible from jQuery and OOUI

+1

  • Remove OOUI-coupled LESS code as much as possible

+1

For anyone interested here's an attempt of refactoring the help panel button to a Vue component.

Thanks! As we discussed in chat, could you please post to gerrit so we can review and discuss there?

I found prototypes for a Node service (T286963) and V8JS (T286966), but I'm not sure what the timeline is for first-class server-side rendering support.

These are promising. We can continue to use OOUI for some interim period for the server-side rendered interfaces and eventually start migrating them to a VueSSR mechanism or keep just HTML + CSS but drop OOUI styles and replace them by new Codex design tokens.

For some of our features, we don't need to think about server-side rendering. For example:

  • help panel button (simple enough that we should be able to live with code duplication)
  • help panel (all client-side)
  • mentor dashboard overview module (no server-side rendering currently)
  • suggested edits task type and topic filters
  • post-edit dialog

Nice, these are great starting points.

Yes, I think the main thing we need to know is how adopting Vue for e.g. suggested edits would impact the userbase of growth features in countries / locations where IE11 usage is relatively high.

I've seen some numbers in https://www.mediawiki.org/wiki/Compatibility/IE11 but it would be nice to see which are the shares for newcomers edits. An optimistic hypothesis is that newcomers use newer browsers.

  • Create unit tests for existing JS business logic

+1, a good first step would be to catalog what is important for us to test and perhaps group by priorities so we can start making progress on this.

This is tricky because many logic is hidden inside OOUI widgets so the creation of the unit tests would imply diving into heavy mocking. For me a good starting thumb-rule would be to test anything that doesn't inherit from OOUI.

  • Start using and refactoring modules to ES6 (based on IE11 support decision we could use a build step in case we want to transpile to ES5)

This is complicated (see T279108 and T199004). We could work around that by committing the artifacts to the repo. I've not been excited about that approach so far, but if there's good arguments for doing so, I'm open to doing that.

Since ResourceLoader supports ES6 we would not need the build step if we downgrade IE11 to Grade C support (in our extension) and provide server-side fallbacks.

  • De-couple JS code as much as possible from jQuery and OOUI

+1

Based on the IE11 decision we could make a list of warning deprecations or lint rules to help us clean up. ie: Prefer Object.assign over $.extend to remove jquery dependency

  • Remove OOUI-coupled LESS code as much as possible

+1

It is not only LESS code actually but also JS and PHP. I created a specific task for this T300557: Remove oo-ui-* references in Growth Experiments extension

Thanks! As we discussed in chat, could you please post to gerrit so we can review and discuss there?

I pushed the experiments code to gerrit and linked in T297764: Add Vue tooling and scaffolding for GrowthExperiments and T300532: Migration of mentee overview to Vue tasks.

I'm happy to see this discussion here. @Sgs, you are correct to point out the bigger-picture problems the Design Systems Team is still investigating (SSR or other progressive enhancement strategy for Vue, front-end build tooling, etc). I agree that identifying some smaller/simpler modules for migration is a good starting point.

The Design Systems Team is currently working towards an "alpha" release of Codex. I've added the Mentor Dashboard project to the list of projects (see T300280) that may be interested in serving as early adopters to alpha-test the library once we make it available inside NPM and ResourceLoader. That should happen in 1-2 weeks, once T294993 is resolved.

Finally, since it looks like some implementation work has already begun, you may find this example project useful: https://gitlab.wikimedia.org/egardner/mediawiki-extensions-vuetest

That repo includes examples of how to set up linters, Jest, and other related scaffolding in a manner that is suitable for Vue 3 & MediaWiki usage. Single-file .vue components are supported in RL, and you can now write them in ES6 syntax (using vue as a dependency now automatically sets es6: true in ResourceLoader settings). Finally, once the Codex icons package is available in RL, you will probably want to use the callback feature in your extension.json file so that only the necessary icons get loaded: here's an example.

MShilova_WMF renamed this task from Migration of front-end modules to Vue.js components to [Epic] Migration of front-end modules to Vue.js components.Mar 22 2022, 2:06 PM
MShilova_WMF triaged this task as Medium priority.
MShilova_WMF edited projects, added Growth-Team (Current Sprint); removed Growth-Team.