== Background
I have raised this issue as an action point from a discussion that we had in the engineering enclave on May the 23rd.
Below is my "personal" experience of working on the re-organization of the [[ https://phabricator.wikimedia.org/T303384 | button states ]].
"The current division of designs token is not working very well from a development experience point of view. The most problematic layer of the token has been the "codex-components". This seems to be very useful on paper, but its current usage of it turns out to create more headaches than development support.
A few issues that I have encountered while developing the above-mentioned task:
- Not all button states have a `codex-component` token: for example `@border-color-progressive--hover`
- ~~There is no distinction within the tokens to understand where the token comes from so `@border-color-progressive--hover` is from `codex-base` but `@background-color-quiet--hover" is from `codex-components`~~
-- Good point. For context, `-quiet` was inherited from OOUI/WikimediaUI Base. All other tokens in 'codex-components.json' are already applying the component that they are used for in their name. We'll update to `-button-quiet` accordingly.
- Sometimes a `codex-base` token may not align with a component one, so a "progress-base--hover` may need to be overridden in `codex-components` just because the Progress-base-hover of the button is not the same as the base!
-- VE: Not sure, I understand what's meant here.
- We try to avoid the creation of many tokens, so if a couple of states share a value we try to reuse it, but this turns out to be not very clean to read in the `.vue` files. You may find a "hover" in an active state or a "Normal" declaration in the progressive.
-- VE: This is a problematic gap that should not happening with the full tokens nomenclature settled. Modifier tokens should be exclusive to states.
- The Figma designs are always (until now) being provided with the use of the `codex-base`, and it is time-consuming to decode what the colour meant at a "codex-component" level.. (lots of Find All)
- ~~Components could have a very nested level of requirements (eg button-normal-progressive-active). This is quite verbose to define in tokens and can be cleaner and easier to see within a full CSS declaration where.~~
-- VE: That's not the case anymore with updated color tokens in place T296995
- We are not making good use of the actual `.vue` file. These are supposed to include the full scope of the components, and I think we could remove the `codex-component` and actually declare component-specific token (or more specifically CSS declaration) directly within the component and just call the Codex-base file."
-- VE: As much as this might make sense from a pure developer view, it's important to collect the component tokens in one place in order to see emerging patterns or be clear about the discrepancies of one-offs.
== Doc to collect feedback
| [[ https://docs.google.com/spreadsheets/d/1Sn9rnG9C-6tmq3u6o-mDi0UEjUqj-zW3NZJbXKdQ878/edit#gid=0 | Spreadsheet here ]] |