What is it?

TLDR: Design systems team will produce a mixin to allow web team to sync styles of mediawiki UI with Codex for typeahead search and message boxes. Web team will provide assistance with integration and testing. This will reduce interrupt work between the two teams.

Longer version:
Design systems team and web team regularly interrupt each other's work whenever a Codex release occurs. This is because:

1. the web team primarily uses legacy CSS as a stopgap solution while there is no server side rendering (SSR) solution for Codex
2. The Codex library in evolving with design input
3. The legacy library is not evolving with the Codex library

Whenever a release occurs the web team and DST team must collaborate to ensure that the SSR versions of buttons/icons. This usually requires modifications to Vector that take into account the old and recent versions of Codex.

Regularly design review in the web team is slowed down as designs do not match the style guide because they are not built using Codex. Most recently, this led to an unnecessary delay in deploying the fixed width toggle (T319449).

Another recent example is these bugs which block a Codex deploy:
T322384, T322383

Our expectation is server side rendering will not be practical inside the web team for some time, and possibly never which means continuous interrupt work.

During the offsite a mixin approach was suggested as potentially providing a stopgap, and possibly even a long term solution to address the web team's needs. We would evaluate this approach for low-use components "search" and "message". If this is successful the design systems team would be able to use this blueprint for more widely used button and icons. If this is not successful, the DST will gain very useful insight into the requirements for SSR that will aid web team on the long run in finding a solution that solves our problems.

End-User Impact

• The UI will be consistent across all pages. Currently button colors differ slightly between interfaces built in Vue and the site chrome (Vector 2022 skin)
• New products will be shipped quicker due to less interrupt work and fewer design blockers.
• Fewer UI regressions relating to Codex releases. (e.g. T323245)
• The navigation restructure in Q3 will require buttons and icons in the mobile site. Without this work being done we will not be able to do that work without inheriting the technical debt we've already built in Vector.

Engineering Impact

• Codex can evolve without needing input from the web team
• Reduce code duplication, the web team will ultimately maintain less code.
• The web team is not required to monitor Codex development and invest energy keeping legacy libraries up to date with Codex.
• The DST team is not required to coordinate with web team on Codex version updates.
• Editing team are not blocked on DST/Web team for changes like T314488

Design Impact

• New interfaces built by the web team that use buttons, icons, message boxes will meet designer expectations by default.
• Fewer UI regressions relating to Codex releases.

Other Impact

• When there are inconsistencies, design blockers emerge slowing down deployments
• This will support using Codex in mobile and other places in web interfaces. Currently the lack of any viable SSR solution hinders the web team from benefiting from using Codex in any part of our UI. As a result we invest more time than other teams in building out new experiences as we cannot directly use the shared component library.

What does it block?

• Any radical change in existing Codex components. e.g. T319449
• Building any experiences in the mobile site (Using Codex/Vue in the mobile site is not viable without being able to render search input, icons and buttons on the server side)

Phases of Work and Owners

Majority of work would be on the DST. Web team would invest 1-2 people, 24hrs (3 days work over 3 weeks)

• Design systems team builds a mixin for message and typeahead search styles and publishes it as part of Codex release (2 weeks)
• Web team attempts to integrate these styles into core, feeding back any problems (1 week) with the approach.
• Design systems team tweaks approach (1 week)
• Web team re-attempts to integrate approach. (1 week)
• Web and DST team assess approach and long-term viability and next steps. (1 week)

Cross-Team Dependencies

Design system team would be driving this work.

@NHillard-WMF / Jdlrobson: Hi, the Due Date set for this open task passed a while ago.
Could you please either update or reset the Due Date (by clicking Edit Task), or set the status of this task to resolved in case this task is done? Thanks!

No reply; resetting Due Date.