How can we collaborate, where should that be, and when? There are several existing Vue.js component collections (some embedded in applications) including:
- [[ https://doc.wikimedia.org/wikibase-vuejs-components/master/ui/?path=/story/indeterminateprogressbar--default | WMDE ]]
- [[ https://people.wikimedia.org/~santhosh/storybook/?path=/story/components-button--different-buttons | ContentTranslation ]]
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MachineVision/+/refs/heads/master/resources/components/base/ | MachineVision ]]
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/NearbyPages/+/refs/heads/master/resources/ext.nearby.scripts/ | NearbyPages ]]
- [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WikibaseMediaInfo/+/refs/heads/master/resources/mediasearch-vue/components/base/ | WikibaseMediaInfo ]]
- [[ https://doc.wikimedia.org/wvui/master/ui | WVUI ]]
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.
== Options
An existing library such as [[ https://gerrit.wikimedia.org/r/plugins/gitiles/wikibase/vuejs-components/ | 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 [[ https://phabricator.wikimedia.org/T241180 | 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.