Frontend Architecture
Design tokens: multiple-choice review
Six questions that cut across the whole unit. Each mirrors a real decision — where a token belongs, what a component is allowed to reference, when a pipeline pays off — not a definition to recite.
Confirm you can connect the three tiers, semantic theming, the cross-platform build, and the discipline that keeps drift from creeping back — the synthesis the lesson built toward.
A code review shows a button styled with background: var(--color-blue-600). The system has primitive, semantic, and component tiers. Why is this a defect even though the color is technically a token?
Dark mode must recolor every component with no JavaScript and one repaint. Which approach delivers that on the web?
The team authors tokens once in DTCG JSON and runs Style Dictionary. What is the load-bearing step that makes one source correct on web, iOS, and Android?
A five-person team ships one web app, one theme, no native targets. They propose a full three-tier system with a Style Dictionary build. What is the senior read?
Three weeks after rolling out tokens, a grep finds fresh hardcoded hex values scattered through new components. The tier model is sound. What is the durable fix?
A designer asks why the button cannot just reference color.blue.600, since that is what it resolves to anyway. What is the precise reason for the extra semantic hop?
The through-line is one rule with consequences: a component references a semantic token, never a primitive and never a literal. That single discipline is what lets the cascade theme dark mode for free, lets one DTCG source generate correct CSS, Swift, and Android via transforms, and lets a rebrand be one edit to the primitive layer. Size the tiers to the targets you ship, and gate the rule with a linter — because a convention without an enforced gate drifts back to hardcoded hex within weeks.