Page MenuHomePhabricator

Lower the maintenance costs of TypeaheadSearch in Vector
Closed, ResolvedPublic

Description

Background

The implementation of TypeaheadSearch in the header in Vector includes a server-rendered search input that is swapped out for the Vue (Codex) version once it loads on click. To ensure a smooth transition, the server-rendered version must be styled to match the Vue version. Since there isn't a no-JS version of Codex components, and Codex design tokens haven't been available in MediaWiki, many styles and tokens are manually copied from Codex into Vector.

This has caused issues as CdxTypeaheadSearch, its subcomponents, and Codex design tokens have continued to be updated in Codex. Each time a new version of Codex is released and added to core, styles and Less variables in Vector must be checked and sometimes updated to prevent regressions.

Although instances of these disruptions should go down as Codex becomes more stable (e.g. as design tokens are finalized), they may still occur occasionally. Because the search bar is so highly visible (at the top of the page on any wiki when using the Vector 2022 skin), we need to find a sustainable way to prevent regressions.


Plan

Goals

  • Keep all Codex styles in Codex, not duplicated in Vector
  • Make it easy to use Codex styles/tokens on the server-rendered UI in Vector

Plan overview

  1. Provide a CSS-only TypeaheadSearch component, which will enable us to add CSS classes to the template of the server-rendered search box that will apply CdxTypeaheadSearch styles. There should be no visual differences (other than the search button appearing) when the Vue app loads and takes over. Once this is done, we will remove all styles in Vector that are no longer needed.
  2. Provide all necessary design tokens for use in Vector, to apply to search-box-related components. This will require creating an inventory of the necessary tokens, then ensuring that any tokens that are still in Codex component SFCs are upstreamed as design tokens (see T295711). Once this is done, we will remove all duplicate Less variables in Vector.
  3. Potential follow-up: Add options in CdxTypeaheadSearch to make the markup more closely match that of the server-rendered search box
  4. Potential follow-up: use design tokens or CSS-only components to style the search box that is rendered server-side when JS is disabled. This would be a design change, since for that search box, the search icon button is on the right.

Order of operations

  • DST provides a CSS-only TypeaheadSearch component, with documentation on its use
  • DST provides all necessary design tokens
  • DST and Web work together to implement CSS-only TypeheadSearch and design tokens in Vector, removing styles and variables that are no longer needed
  • DST and/or Web consider adding options to CdxTypeaheadSearch to enable different markup options
  • Web considers updating the no-JS search box to more closely match the other versions

Acceptance criteria

  • CSS-only TypeaheadSearch component is built and documented
  • All necessary design tokens are available in the @wikimedia/codex-design-tokens package
  • T337966 CSS-only TypeaheadSearch and design tokens are implemented in Vector, with duplicated styles and vars removed

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
AnneT renamed this task from Share TypeaheadSearch-related styles via Less mixins to Lower the maintenance costs of TypeaheadSearch inVector.Jan 19 2023, 11:48 PM
AnneT updated the task description. (Show Details)
AnneT added a subscriber: ldelench_wmf.
ldelench_wmf moved this task from Inbox to Needs Refinement on the Design-System-Team board.

Change 885895 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [proof of concept] Demo CSS-only TypeaheadSearch

https://gerrit.wikimedia.org/r/885895

AnneT changed the task status from Open to In Progress.Feb 15 2023, 5:22 PM
AnneT claimed this task.
AnneT updated the task description. (Show Details)
AnneT added a subscriber: Volker_E.

Tagging @Volker_E, since completing the transformation of TypeaheadSearch SFC tokens to design tokens is part of this task's acceptance criteria

Change 885895 abandoned by Anne Tomasevich:

[design/codex@main] [proof of concept] Demo CSS-only TypeaheadSearch

Reason:

no longer needed; will open a final patch for CSS-only TahS demo

https://gerrit.wikimedia.org/r/885895

Volker_E renamed this task from Lower the maintenance costs of TypeaheadSearch inVector to Lower the maintenance costs of TypeaheadSearch in Vector.Feb 20 2023, 11:34 PM
AnneT changed the task status from In Progress to Stalled.Mar 8 2023, 1:48 PM

Currently blocked by T330468

The scope of " DST and Web work together to implement CSS-only TypeheadSearch and design tokens in Vector, removing styles and variables that are no longer needed" seems pretty big to me.
I wonder if we could break this down into a few smaller steps

  1. [Both teams] Replace variables in Vector with the newly available design tokens
  2. [Both teams] Create local CSS mixins inside Vector that replace the existing implementation and define an agreed expected API that Codex will define and Vector will consume. [Timeboxed activity since this could drag a little]
  3. [DST] Introduce CSS mixins based on spec in 2 and release Codex
  4. [Web team] Use new version of Codex and remove local CSS mixin.

What do you think?

@Jdlrobson I think splitting this work into smaller pieces makes sense, and agree with starting with starting by implementing Codex design tokens in Vector.

RE: mixins, we are discussing ways we could support use of CSS-only components without forcing people to load the CSS for the entire Codex library (I know you, Eric, and Roan were discussing this in Slack recently). IMO, providing mixins for some components based on project-specific needs is not a sustainable solution, so I would prefer to avoid it if we can. The set of mixins that would be needed for TypeaheadSearch and its subcomponents would be quite extensive to implement and maintain, whereas the CSS class-based approach required very few changes to Codex and is much easier to maintain, which is one of the reasons we opted for this approach.

We already have a subset of styles for just TypeaheadSearch: the codex-search-styles RL module (this used to be part of @wikimedia/codex-search but was split off recently). The CSS from codex-search-styles is about 3.2KB gzipped—is that acceptable? Even if we used Less mixins, we would probably need most of the styles from codex-search-styles, so the savings would likely be minimal.

The CSS from codex-search-styles is about 3.2KB gzipped—is that acceptable?

We currently ship 12.3 kB of render blocking CSS, so that would be a pretty big increase. HoweverI talked to @bwang about this and we think that if we could also drop mediawiki.ui.button and mw.ui.icon modules this change should be minimal. That increases the scope of the ticket more, but gets us to a good place.

T334881 would be helpful to do our side to make how we build buttons and icons consistent on our side. After we've done that, we think we should be able to look at using the CSS components in Vector and identify blockers.

We would consider the following two tickets blockers for CSS only component adoption in Vector. Would you be able to get those priortiized?: T322436, T333392

The CSS from codex-search-styles is about 3.2KB gzipped—is that acceptable?

We currently ship 12.3 kB of render blocking CSS, so that would be a pretty big increase. HoweverI talked to @bwang about this and we think that if we could also drop mediawiki.ui.button and mw.ui.icon modules this change should be minimal. That increases the scope of the ticket more, but gets us to a good place.

We would consider the following two tickets blockers for CSS only component adoption in Vector. Would you be able to get those priortiized?: T322436, T333392

That's great, and I think this sounds like a reasonable plan and amount of work compared to the benefits we'll get from doing it this way. I talked with @CCiufo-WMF and we agreed that we can prioritize those two blockers, hopefully in our next sprint (starting next week). I think they will both be fairly easy/quick to complete. If y'all can work on T334881 in the meantime, perhaps we can come back together in 1 or 2 sprints to work on this task.

NBaca-WMF subscribed.

Adding T322436: Codex should provide mechanism for flushing icons and T333392: Button: Increase padding of icon-only buttons on small screens as subtasks to reflect that they're related / blocking this parent task - please move these around if this is not accurate!

AnneT changed the status of subtask T333392: Button: add "large" size from Open to In Progress.May 1 2023, 3:31 PM

Once T322436 and T333392 are addressed the web team plan to look into T335710 to see what is needed to get this over the finish line.

AnneT changed the task status from Stalled to In Progress.May 16 2023, 8:27 PM

Change 922928 had a related patch set uploaded (by Jdlrobson; author: Bernard Wang):

[mediawiki/skins/Vector@master] Use Codex for typeahead search styles

https://gerrit.wikimedia.org/r/922928

Jdlrobson lowered the priority of this task from High to Medium.May 25 2023, 7:57 PM

Estimation instructions: Feel free to estimate this if you think it is not in the scope of T336526.

If not, please retitle it [subtask] Lower the maintenance costs of TypeaheadSearch in Vector

We discussed this in Web team estimation, and we decided to create a new task T337966 for implementing Codex CSS Typeahead Search in Vector. We will keep this task as is as an epic/parent task

Change 922928 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Use Codex for typeahead search styles

https://gerrit.wikimedia.org/r/922928