Page MenuHomePhabricator

Develop guidelines for quality assessment of Vue.js projects
Closed, ResolvedPublic

Description

This task is meant to capture guidelines and suggestions for effectively assessing the quality of Vue.js components and projects. The Foundation is ramping up Vue.js work, both with the development of the WVUI library and by migrating existing UIs to Vue.js. Since Vue.js is new to many of us, we should think through how to best ensure quality to avoid introducing bugs to existing projects as we migrate them.

Please feel free to add comments or edit the list below directly.

General guidelines

  • There is a Vue.js devtools browser extension for Chrome and Firefox that allows you to examine component data and Vuex state, observe events, and more. To enable it:
    • Install the browser extension
    • If you're testing a MediaWiki project, add ?debug=true to the URL. This will run Vue in development mode
    • Open the dev tools panel and look for a "Vue" tab (if you already had the panel open, you. might need to close and reopen it)

Shared UI library code

These suggestions are specific to WVUI or any reusable component.

  • Alignment with Design Style Guide. Each component should fulfill all specifications in the DSG.
  • Adherence to browser coverage matrix. All components should reasonably work in all the browsers we commit to supporting.
  • Proper reactivity. Interactions with components should be functional, predictable, and consistent.

Project/app code

  • Data flow. In Vue, data is passed from a parent component down to a child via props, and from a child component up to a parent by emitting an event. Data can also be stored outside the component hierarchy with Vue's state management library, Vuex, which has a state, actions, mutations, and getters. Passing data around improperly is a common issue that comes up when building a complex app. User stories must be tested thoroughly to ensure that every use case is properly handled.
  • Error handling. If there is a way that the app can be broken (e.g. entering an invalid search term), the error must be caught and handled gracefully. Unhandled errors may lead to empty or missing UI components, or a problematic error state (e.g. an empty search results grid with no error text, a select list with no value displayed).

Event Timeline

egardner claimed this task.

In the ~1.5 years since this task was written, the Design Systems Team has generated a lot of documentation both on- and off-wiki that is relevant to this. Closing this task as resolved.