Page MenuHomePhabricator

Where should shared Vue.js UI components live for WMDE and WMF projects?
Closed, ResolvedPublicSpike


How can we collaborate, where should that be, and when? There are several existing Vue.js component collections (some embedded in applications) including:

These are each solving the same problems in slightly different ways and with varying functionalities. The WMF Web team is now considering a fourth(?) reinvention of the parts needed for the new Vue.js search experience such as buttons, progress bars, thumbnails, etc. Would it be better to start sharing a codeveloped solution sooner rather than later? That important decision is what this task explores:

  • How: what infrastructure or work is needed so that we can collaborate effectively?
  • Where: in what repo should shared components live?
  • When: Web's new search experience project has pressing Product concerns. We do not wish to repeat the past mistakes but neither can we wait for the perfect solution to arrive.

(To some extent, "who" is implied as it is assumed that all developers are interested in sharing code where practical.)

This task is not about application specific development or isolated use cases but for the common widgets that would be needed by any WMF / WMDE application, many of which exist in some form already. Useful components may develop or "ripen" in isolation but should "graduate" to a shared component library as soon as they're in a state to do so.

Acceptance criteria

  • A decision is made where components should live.
  • A decision is made for when Web should integrate this component library.
  • Immediate follow-up tasks needed for collaboration are created.


An existing library such as WMDE's component library may resolve both concerns if WMDE is open to collaborating at least in terms of providing regular code review for patches submitted. Is this something all parties involved would agree to or is not possible? Should alternatives be considered?

Shared objectives and guiding principles?

Shared components have great aspirations including that they be:

  • Efficient to develop, meeting the expectations of modern developers, and encouraging of a welcoming culture.
  • Sharable and reusable in any context within and without Wikimedia in development and production.
  • Easily composable in any combination.
  • Responsive.
  • Performant both in terms of bandwidth and computationally.
  • Accessible (including screen readers and keyboards).
  • Localizable.
  • Tested.
  • Renderable in any context within and without a browser.
  • Documented.
  • With accurately typed, well-defined, and semantically versioned APIs.
  • Nicely styled.
  • Intelligently divided with explicit dependencies to serve different use cases.
  • Strongly patterned, idiomatic, and intentional; components are designed consistently and cohesively.
  • Favoring composition over inheritance.

Many of these goals were identified as shortcomings of T225453 or requirements in T225572, both of which were inputs to and a supporting rationale for the Vue.js RFC itself. These guiding principles are not impossible and, in the long-term, are not merely aspirational but necessary. The initial components for the new Vue.js search experience will probably fall short but nevertheless, we do not wish to repeat past mistakes and hold these objectives dear. Components in a shared library would be more able to meet them and fan out to all projects.

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptApr 9 2020, 4:13 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I've added the phone book and yet likely forgotten key people! Please help me add all the interested parties and feel free to unsubscribe or mute if it's too noisy or not so relevant.

With my personal sympathy to the idea of sharing common components in all Wikimedia (WMF and WMDE) applications, I'd like to refer to my comment on T249051#6043841, that while developer crew can definitely make a good job grouping those components in a single place, but as long as this strategy is not aligned with the (common) Design strategy, this might lead to having a solid library which solves the other problem that we intend to.

This is not meant as a criticism to the idea, or attempt to pull the break - just trying to highlight what we see as a bigger picture.

Thank you @WMDE-leszek, I completely agree. Much like the vuetify, Material UI, other component libraries adhere with the Material Design spec, any shared component library we create will need to adhere to some design spec to be useful to anyone. Pragmatically, this should be the Wikimedia Design Spec/Style Guide or else we risk ending up with a collection of disparate components that no one wants to use including Wikimedia devs.

Volker_E renamed this task from [Spike] Where should shared components live for WMDE, ContentTranslation, MachineVision, and WMF projects? to [Spike] Where should shared Vue.js UI components live for WMDE and WMF projects?.Apr 14 2020, 11:29 PM

Pulled off epic, as this is no longer part of the initial project scaffolding but still a valuable question to answer.

Is WVUI meant to be the location of shared components now that it exists?

Yes, this would now be a question for @AnneT etc..
My understanding is wvui will be the destination but it would be great to get a written record here.

@DannyS712 The short answer is yes, we intend for WVUI to be that shared library. There's still a lot to figure out in terms of exactly how the library will be developed, how/when existing Vue components from other projects will be unified and incorporated into it, plus all the other components we'll need to build, etc... We're currently working very hard to figure this stuff out so we can get more information out there to anyone who's interested (including how we'll communicate our progress to ensure that people are up-to-date and can contribute if they want to). Stay tuned!

Please note that our design system components (the ones already being used in new WD/WB applications) actually live in this ever-growing GitHub repo and this Storybook. You can also find our tokens and all sorts of documentation in both resources.

That first link included in the task description corresponds to an early exploration.

On a follow-up to what @AnneT said above, there's our current support of WVUI, in example of Desktop Improvements (Vector 2022) rollout of the library's typeahead-search component any time soon after T257579 into production. While its a somewhat urgent need right now, we as Wikimedia Foundation Vue.js team agreed to set out (and have shared on a few occasions like the last front-end developer standards meeting last week), that together with our stakeholders we'll evaluate the whole components architecture requirements in all different teams, chapters & repos and there has no definite decision been made yet about the future library.

Here is the main task and specific questions will be linked to or defined as sub-tasks.

Volker_E renamed this task from [Spike] Where should shared Vue.js UI components live for WMDE and WMF projects? to Where should shared Vue.js UI components live for WMDE and WMF projects?.Mar 1 2021, 6:55 PM
Volker_E removed a subscriber: Pablo-WMDE.

Can we consider this task resolved now that we have started development of a joint WMF-WMDE UI component library?

This has been resolved successfully with the decisions in the Vue.js designer workshop and developer summit and follow-up at the Vue taskforce.
Codex is the (documentation, repository) shared toolkit and component library for Wikimedia (Foundation, Wikimedia Deutschland et al.).