Vue.js

Vue.js is Wikimedia Foundation's official choice for adoption as future JavaScript framework for use with MediaWiki. It's currently experimental (based on Vue.js v2.x) and not ready for wide use as there are a number of things in flux (see the Current Status section below). This page documents guidelines, best practices, and resources for using Vue within MediaWiki. In general, this documentation should be minimal because it defines only MediaWiki-specific pieces and largely refers to the official documentation, which we aim to follow as much as possible.

Vue within MediaWiki
Vue is bundled with MediaWiki as a ResourceLoader module. See below for details. MediaWiki currently includes Vue.js v2.x. Work is currently underway to update to Vue 3 in core, which will happen in phases (including an initial migration to the Vue 3.2 compatibility build). See T289017 for more details.

Single-file components (.vue files) are supported via ResourceLoader.

Server-side rendering of Vue components is not currently possible but is on the Wikimedia Foundation Design System Team's roadmap.

See the Design System Team's page or Phabricator workboard for more information about current work and future changes to Vue-related infrastructure.

Vue UI library (Codex)
A new library containing Vue 3 components, design tokens, icons, and documentation is under development and will soon become available for projects within (and beyond) MediaWiki. The library, Codex, is managed by the Design Systems Team and built by collaborators across the community (including the Wikimedia Foundation, Wikimedia Deutschland, and volunteers). An initial release is planned for Q3 of the 2021-2022 fiscal year and will replicate the components and functionality offered by the legacy Wikimedia Foundation Vue 3 component library, Wikimedia Vue UI (WVUI), which is now deprecated and in maintenance mode.

To learn more about Codex, check out:


 * Phabricator workboard
 * Code (or GitHub mirror)
 * Live demo site

Pre-built (bandwidth and client performant at the expense of extra initial set up)
For professional developers building high performance experiences, pre-compilation and minificiation is recommended. However, this requires extra per-repo configuration changes which are currently undocumented. This extra configuration will be eliminated or formalized and minimized if the deploy build step RFC succeeds.

On the fly compilation (less performant but easy to develop)
ResourceLoader has built-in support for parsing single-file components. This lets you write Vue.js with very little configuration in the context of a MediaWiki installation which may be valuable in some contexts as well as for developers uncomfortable with compilers. Please note the following limitations:
 * Scoped styles are unsupported.
 * What you write is what you ship--No ES6, TypeScript, or language compilation support. At time of writing, this means ES5 only.
 * Vue.js directive shorthands are unsupported  for   and   for.
 * The version of Less used must match MediaWiki's version (very old). However, everything that works in normal MediaWiki styles works here (e.g., CSSJanus, relative URLs, imports, etc).

How to use on the fly compilation
You can add a .vue file to any package module as if it were a script file: The .vue file must contain a template and JavaScript code that exports a component registration object. It can also (optionally) contain styles: You can then  the .vue file just like any other script file. For example, you can use it as a root component as follows: Or you can use it as a nested component inside another component: Some modules have an init script as their main file (usually called ) that creates a new Vue instance to take over a DOM element on the page and replace it with a Vue component. Other modules just export one or more reusable components; their main file is either a  file with the component that's exported, or a script file that exports several components, e.g.:

The module in ResourceLoader
MediaWiki core comes with a copy of Vue (v2.x) and some small MediaWiki-specific plugins for Vue. These live in the  module. In code that sets up a new Vue instance, (i.e. calls ), you should make the   module a dependency of your module, then obtain the Vue object using. You do not have to call  to register the MediaWiki-specific plugins; this is done for you.

General guidelines

 * Avoid globals of all kinds. Instead, pass the dependencies needed in from the outermost to the part that needs it.
 * Avoid jQuery as a dependency. There are several reasons for limiting jQuery usage including:
 * jQuery is a large dependency both in terms of bytes shipped to users (performance) and comprehension (API) but its usefulness is less and less. For libraries, jQuery as a dependency especially limits reusability by third parties.
 * The jQuery API is invasive--any usage returns jQuery specific types that are cumbersome to pick apart and usually results in further usage whether it’s truly necessary or not.
 * Usage of jQuery has encouraged construction of entire user interfaces by manually assembling bits and pieces of HTML wrapped in jQuery parser calls. This imperative style is challenging to read, verbose, difficult to maintain, unwieldy to compose, and doesn’t scale well to application development. For user interface development especially, Vue.js is the greatly preferred alternative.
 * Since the need for jQuery is diminishing, it is perceived as a redundant technology (e.g., GitHub removed its usage in 2018 and close proximity to or, worse, dependency on it makes our code appear out of fashion which is unbecoming to newcomers.

The i18n plugin
The  module comes with a small i18n plugin that wraps MediaWiki's i18n system, so you can use MediaWiki i18n messages in your templates. This plugin creates an  function that you can use inside templates, which is an alias for. For plain text messages (most cases), you can simply use: You can pass parameters either variadically, or as an array: The  function returns a Message object, so you can use it in all the same ways that you can use   in "normal" JS code. Remember that all message keys you use have to be added to the  array in the ResourceLoader module definition.

Parsed messages
One important limitation of  is that you can't use it for parsed messages that return HTML. This is because template interpolations ( syntax) can only return plain text, and are always HTML-escaped: The code above displays , as plain text. To get Vue to accept raw HTML, you have to use the  directive. Because writing  is verbose and annoying, the i18n plugin provides a shortcut using the   directive, which you'll want to use instead unless you need to pass message parameters or reference the message name from a variable. See the documentation comments in  for a more detailed explanation.

Parsed messages with parameters
The  directive does not currently support passing parameters to the message. Support for this may be added in the future. The recommended way to pass a parameter to a parsed message (or to do other complicated things) is to put the parsed message in a computed property. It's possible to do these kinds of things inline, but using a computed property is recommended for readability.

Code conventions
Check out MediaWiki's Vue coding conventions, which are largely based on the official Vue Style Guide since we seek parity with default Vue style and behavior as much as possible. This should improve the onboarding process for new MediaWiki developers who have past Vue experience.

Testing
You should write tests! The current recommendation is to use Jest.

See the Vue.js testing guide for more information about how to test Vue components in a MediaWiki environment.

Error reporting
Client side errors can be monitored in Logstash. Dedicated documentation forthcoming in T248884.

TypeScript
(coming soon)

Skin

 * New Searchbar for Desktop Improvements (part of WVUI)
 * Synthetic performance tests were also setup as part of this project that compare the lazy load time, query to render time, etc between legacy search and the Vue search implementation. The dashboard can be seen at https://grafana-rw.wikimedia.org/d/GivPpdsGk/vue-vs-legacy-search?orgId=1

Extension

 * Extension:MediaSearch
 * Uses Vuex
 * Has a fallback PHP implementation of the basic UI for a no-JS experience
 * Jest unit tests
 * Content Translation's new dashboard and section translation
 * This approach uses webpack based build and offers hot reloading and close integration with Vue dev tools
 * Extension:MachineVision
 * Uses Vuex
 * Extension:GlobalWatchlist
 * Extension:NearbyPages
 * Extension:WikiLambda
 * MediaWiki Vue.js Sandbox (test extension)

WMDE/Wikibase

 * "microfrontends" "termbox" (currently on mobile only)
 * Wikidata Bridge (currently on selected Wikipedias only), see code
 * Tainted References

Miscellaneous

 * Codex UI toolkit (see live demo)
 * WMDE
 * Simple Query Builder (An easier way than SPARQL of querying Wikidata), see code
 * Wikit (Design System and Component Library), see code
 * Wikibase Vue.js components repo
 * The Toolhub catalogue

Most important

 * Official guide
 * Official API documentation
 * Official style guide
 * Official devtools browser extensions

Additional

 * Vue.js News (weekly newsletter)
 * Mozilla Developer Network (MDN) Vue.js documentation

Training vendors

 * Vue School
 * Frontend Masters
 * Vue Mastery (includes some free courses too)

From around MediaWiki

 * Successful Technical RFC on evaluating front-end frameworks within the MediaWiki ecosystem
 * 2020: The Year in Vue from the Wikimedia Tech Blog

GitLab

 * Vue.js frontend development guidelines
 * Why we chose Vue.js
 * How we do Vue: one year later