Page MenuHomePhabricator

Consider providing Vue Router in MW for use by Vue-using MW extensions/skins
Open, Needs TriagePublic

Description

Currently we have OOjs-Router wrapped as "mediawiki.router"; https://router.vuejs.org/ would probably work better for us in a post-Vue world. We're thinking we need this for WikiLambda and I believe it might be of value to other teams too?

Event Timeline

The Inuka-Team needs this for Wikistories

We'll include our own copy in the short term, like WikiLambda is doing.

I found this task, since I was also looking for a router to use in my code.

To my surprise, ContentTranslation seems to be the only remaining user of Vue Router in production. Both WikiLambda and Wikistories have dropped their use of Vue Router (in T301520 and T313839), replacing them with very simple custom implementations (~200 lines for WikiLambda, and ~60 lines for Wikistories, and in both cases that includes the route definitions).

Would it be correct to think that Vue Router is no longer the obvious choice, and writing the code ourselves is preferable for many applications?

I guess Vue Router may be too big of a dependency. Maybe if we were building the whole website as a Vue app, it would be worth it, but as it stands MediaWiki itself handles most of the routing. It also became easier to implement client-side routing using HTML5 History API as we dropped support for older browsers.

Would it be correct to think that Vue Router is no longer the obvious choice, and writing the code ourselves is preferable for many applications?

I guess Vue Router may be too big of a dependency. Maybe if we were building the whole website as a Vue app, it would be worth it, but as it stands MediaWiki itself handles most of the routing. It also became easier to implement client-side routing using HTML5 History API as we dropped support for older browsers.

I think Vue Router is still widely used in the larger Vue community, but it will probably see limited use here for exactly the reason you mention. A client-side router is the definitive SPA feature in my opinion, whereas MW is very much a multi-page app. For more complicated dashboard or "wizard" features with multi-step flows it may make sense (and I'm okay with making it available as part of MW if folks need it) but for most other on-wiki features it's probably overkill.

Sometimes I do wonder if there would ever be interest in a rich, SPA-style MW skin – such a skin could use Vue-router to make API requests for subsequent navigation after server rendering the initial page, etc. But I don't think anyone is planning to build such a thing any time soon...

Content Translation is essentially an SPA (it uses its own internal hidden skin under the hood) so its usage makes sense in this context.