Uh oh!
There was an error while loading. Please reload this page.
Centralize semantic tokens for Airflow UI - #56347
Conversation
- Implement comprehensive UI playground showcasing Chakra UI v3 components - Add sections for color palette, buttons, forms, progress indicators, charts, and graphs - Update to Chakra UI v3 API patterns and best practices - Fix all linting and formatting issues - Add proper accessibility features and semantic HTML - Implement collapsible sections with consistent styling - Add task instance states visualization with progress bars - Include ReactFlow graph components matching DAGs view - Add comprehensive color matrix display similar to Tailwind CSS - Remove all custom margins/padding for consistent design - Add proper TypeScript types and error handling - Ensure full ESLint and Prettier compliance Components added: - Playground.tsx - Main playground page with state management - ColorPaletteSection.tsx - Color palette matrix display - ButtonsCodeSection.tsx - Button variations and code examples - FormsInputsSection.tsx - Form controls and input examples - ProgressTaskStatesSection.tsx - Progress bars and task states - ChartsGanttSection.tsx - Chart.js integration with proper theming - GraphSection.tsx - ReactFlow graph visualization - BadgesAvatarsSection.tsx - Badge and avatar components - ModalDialog.tsx - Modal and dialog examples - TableOfContents.tsx - Navigation with expand/collapse controls - forms/ - Individual form component examples Fixes: - All ESLint errors resolved with proper disable comments where needed - Prettier formatting applied consistently - TypeScript compilation errors resolved - Chakra UI v3 API migration completed - Accessibility improvements implemented # Conflicts: # airflow-core/src/airflow/ui/src/theme.ts
cc4e1e1 to
fb2f695Compareb4fee6a to
7cdb452Compare55763be to
247bb00Compare
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. |
bbovenzi
commented
Nov 20, 2025
Some merge conflicts |
pierrejeambrun
commented
Jan 13, 2026
Gently pinging to know where we are on this one, should we convert it to draft in the meantime? |
guan404ming
commented
Feb 6, 2026
Hi, this one looks really interesting and valuable for our ui consistency. Could I help finish this one? Thanks! |
jscheffl
commented
Mar 15, 2026
@odaneau-astro This PR has been converted to draft because it does not yet meet our Pull Request quality criteria. Issues found:
What to do next:
Converting a PR to draft is not a rejection — it is an invitation to bring the PR up to the project's standards so that maintainer review time is spent productively. If you have questions, feel free to ask on the Airflow Slack. |
* fix MyPy type errors in log_reader.py * fix ruff errors * remove cast
* Fix mypy warnings for SQLA2 migration * Revert soucing from TaskInstanceState from common.compat.sdk
* Migrate FAB POST /roles to FastAPI * Remove unnecessary casting and model * Validate non-empty role name via Pydantic * Move auth dep to provider security and fixtureize dependency_overrides * Add test for roles data model and security provider
…perator Now Share Common Startup Logic (apache#56875) * Move container-related functions from PodManager to a separate file * Moved unit tests * Sync and async workflow use the same code to track Pod startup * Reworked unit tests and pod startup logic * Add api permission error detection for triggerer * Fix pytest fixture * Removed not requried code --------- Co-authored-by: AutomationDev85 <AutomationDev85>
* Fix MyPy type errors in providers utils/sql.py * fix: ignore MyPy arg-type error in select().filter() * Fix: cast filter clauses to ColumnElement for MyPy compatibility * Refactor: remove unnecessary cast to ColumnElement in filter clauses
* Fix MyPy type errors in providers utils/utils.py * Fix mypy error in utils.py by modify type hint for tasksState
It was wrong to load the serdag and not use it. The initial idea was to use the serdag at line 437 but was omitted. Thinking about it now, it will be faster to only load serdag when there's a TI associated with the dag version
- Replace getReactFlowThemeStyle with useToken + graph.* semantic tokens in Playground/graphs/Graph.tsx (new file added to main after branch diverged) - Replace getComputedCSSVariableValue with resolveTokenValue in Playground/charts/Charts.tsx (same rename from main's theme.ts) Made-with: Cursor
e002166 to
4fcd09fComparebbovenzi
commented
Apr 7, 2026
This is 3000 commits behind now. If we still want to do this then I would recommend we just open a fresh PR. |
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: