Centralize semantic tokens for Airflow UI #56347
Conversation
odaneau-astro
force-pushed
the
centralized_tokens
branch
4 times, most recently
from
cc4e1e1 to
fb2f695
Compare
odaneau-astro
force-pushed
the
centralized_tokens
branch
from
b4fee6a to
7cdb452
Compare
odaneau-astro
requested review from
bbovenzi,
jscheffl,
pierrejeambrun,
ryanahamilton and
shubhamraj-git
as code owners
odaneau-astro
force-pushed
the
centralized_tokens
branch
from
55763be to
247bb00
Compare
bbovenzi
left a comment
bbovenzi
left a comment
There was a problem hiding this comment.
Big fan of moving all our colors to semantic tokens.
I think a number of these colors are too specific like calendar.hour-label.color and test-connection.icon.connected and we should try reuse more values. If we have a one-off difference, we should see if we can adjust that HTML element to fit an existing pattern before creating a new color token
| {isParsing ? ( | ||
| <Center mt={2}> | ||
| <Spinner color="brand.solid" marginRight={2} size="sm" /> Parsing file... | ||
| <Spinner color="import-variables.spinner.color" marginRight={2} size="sm" /> Parsing file... |
There was a problem hiding this comment.
This feels oddly specific. I feel like brand.solid was perfectly fine as a semantic token?
| failed: { value: "{colors.red.500}" }, | ||
| running: { value: "{colors.cyan.500}" }, | ||
| queued: { value: "{colors.yellow.500}" }, | ||
| skipped: { value: "{colors.gray.400}" }, |
There was a problem hiding this comment.
I think skipped is supposed to be pink, no?
|
I agree, I'll do a second pass to regroup tokens, especially for reusable ones like Spinners, Boxes, Task States, etc. |
|
Some merge conflicts |
|
Gently pinging to know where we are on this one, should we convert it to draft in the meantime? |
3 participants
Semantic Tokens Design Plan
Goal
Establish a well-structured semantic tokens hierarchy that provides clear separation between primitive design tokens, system-level semantic tokens, and component-specific tokens. This will improve maintainability, consistency, and developer experience when working with the Airflow UI theme system.
Current State
The current theme structure mixes reference tokens and semantic tokens without a clear hierarchy. Component-specific tokens are scattered throughout the codebase, making it difficult to maintain consistency and update the design system.
Proposed Solution: 3-Layer Token Hierarchy
Layer 1: Reference Tokens
Definition: All available Chakra UI "primitive" tokens. These tokens make up all of the style options available in Chakra UI's design system. The tokens point to a static value.
Example:
tokens.colors.blue.50is defined as"oklch(0.97 0.014 254.604)"Chakra UI Token Types:
Purpose: These are the foundational building blocks. They represent raw design values and should rarely be used directly in components.
Layer 2: System Tokens
Definition: Airflow UI-specific "global" semantic tokens. The tokens point to a reference token and provide semantic meaning.
Example:
semanticTokens.colors.info.solidis defined astokens.colors.blue.600Current System Tokens:
brand.*- Brand colors (solid, fg, bg, muted, subtle, emphasized, contrast, focusRing)warning.*- Warning/alert colorsdanger.*- Danger/error colorserror.*- Error colorsinfo.*- Informational colorsactive.*- Active state colorsnone.*,scheduled.*,queued.*,running.*,success.*,restarting.*,failed.*,skipped.*,upstream_failed.*,up_for_retry.*,up_for_reschedule.*,deferred.*,removed.*sys.text.*,sys.background.*,sys.surface.*,sys.border.*,sys.interaction.*Purpose: These tokens provide semantic meaning and can be used across multiple components. They abstract away the specific color values and allow for easy theme updates.
Layer 3: Component Tokens
Definition: Single-use component-specific tokens that don't fit into the system-level semantic tokens.
Purpose: These tokens are specific to individual components and should be used sparingly. They allow for component-specific customization while maintaining consistency with the overall design system.
Out of scope: