Change Details

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. I am going to provide in bullet points 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` - 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! - 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. - 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. - 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."

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. I am going to provide in bullet points 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` - 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! - 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. - 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. - 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."

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. I am going to provide in bullet points 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` - 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! - 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. - 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. - 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."