**To better determine how to proceed in regards to {T321354}, let's explore what CSS-only Codex components would look like for a moderately complex use-case:** replacing the [[ https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/MediaSearch/+/refs/heads/master/templates/SERPWidget.mustache | MediaSearch server-rendered UI ]] with Codex-compatible HTML/CSS components. This interface uses the following components:
* Search Input
* Icon
* Button
* Tabs
This work should be done as a proof-of-concept patch, and will probably never get merged (at least in its initial form). Instead, this code should help to inform the discussion around {T321354} and its parent – does this approach make sense, are there any drawbacks to consider, etc.#### Research Spike outcome
Some specific questions that should be considered here includI posted a series of patches that explored the feasibility of migrating MediaSearch's custom Vue components to their Codex equivalents. MediaSearch uses the component styles to render a no-JS fallback interface which then gets progressively enhanced by the interactive, JS components. The first patch in the series is here:
- How does this integrate with the design system?https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MediaSearch/+/862409
Based on my exploration, I think that this approach is a good one for Codex to follow when it comes to delivering CSS versions of components alongside JS ones.
However, there are a couple of issues in how we are currently doing things that need to be addressed:
* There is currently no good way to get just the styles from the Codex ResourceLoader module in MW. Since MediaWiki lacks a front-end build step, we can only work with existing modules as they come. It's actually possible to get just the styles from a module using the following work-around, but I consider this kind of an ugly hack:
```lang=php
$this->getOutput()->addLink( [
'rel' => 'stylesheet',
'href' => wfAppendQuery( wfScript( 'load' ), [
'modules' => '@wikimedia/codex',
- How could this impact with the architecture of the design system? 'only' => 'styles'
- How does this integrate with mediawiki? ] )
- How far in scope does this need to be?] );
- What is the cost to build?```
* To address this, we should provide both CSS and JS modules for Codex in MediaWiki. The JS modules can depend on the CSS ones, but the CSS modules should be able to wrk stand-alone. Then, a PHP ui could call `addModuleStyles( [ 'codex-styles' ] )` so that all necessary CSS is part of the page immediately. The equivalent `codex` JS module can be added at runtime when JS initializes for progressive enhancement purposes. If the UI in question didn't need JS at all, then only the CSS module(s) would need to be loaded.
* Having to load all of Codex (CSS and/or JS) just to get a small number of components is not great from a performance perspective. Without a true front-end build system we'll never be able to perfectly optimize this, but we can provide some smaller sub-packages of Codex that contain styles and JS code for only a specific sub-set of components. This approach is already done in OOUI and fits well with ResourceLoader; Codex-based features would just declare the modules they need as dependencies in ResourceLoader. This would require a little bit of re-structuring upstream but it's similar to how we are already handling the `codex-search` package. What is the cost of maintenance?Example patch here: https://gerrit.wikimedia.org/r/c/design/codex/+/865840
In conclusion: features like MediaSearch would benefit from the following things:
* Provide Codex CSS as available as stand-alone modules that can be loaded independently of JS
* Split up Codex into multiple modules for use inside of MW (where we don't have the ability to tree-shake out a feature-specific build)
The approach suggested in {T323180} has been informed by this investigation.