skip to content

When a design-system-based app remembers a player's chosen theme, what should it store, and where, so the choice survives restarts and devices?

level: juniorimportance: should knowfreq 38%

answer

  1. a name, not the values
  2. what survives a system update
  3. local for startup speed
  4. account for other devices
  5. what if the theme is retired

basics

~20 s

Store a stable theme identifier, not resolved values, locally for instant startup and on the account for other devices. On load, validate the identifier and fall back to the default if the theme no longer exists.

solid answer

~40 s

Persist the **theme's identifier**, never its resolved values: values change with design-system releases, and a stored name picks up those changes while stored values freeze old colors. Keep one copy **on the device**, readable at startup so the first frame is right, and, if the choice should follow the player, one copy **on the account** for other devices. On every load, **validate** the identifier against the themes the app ships and fall back to the default when it is unknown, for example after a seasonal event theme is retired. When the device and account copies disagree, apply one documented rule, such as the most recent change winning. Store only the choice, never per-component values.

go deeper

for a junior

Recall the rule: store the theme's name, keep a copy on the device for startup, and fall back to the default if it is unknown.

for a middle

Explain why stored values go stale after releases and why the device and account copies serve different moments.

for a senior

Handle the edges: retired and renamed themes, disagreeing copies, and newer app versions writing themes older versions lack.

for a principal

Set a cross-product contract for where theme choices live and which copy wins, so every app on the system behaves the same way.

## What is being persisted In a multiplayer game's companion app, a player picks their faction's theme. The app must remember that choice across restarts, updates and, ideally, devices. The design-system question is not which storage API to use but **what** to store and **how** the stored choice behaves when the system changes around it. ## Store the identifier, not the values A theme is a set of values resolved from semantic tokens. Those values change: a design-system release retunes the red faction's accent, fixes a contrast failure, or adds a token. If the app stores: - **the identifier** (for example, the red faction theme), it resolves the current values on every launch and picks up every fix; - **the resolved values**, it freezes whatever they were on the day the player chose, keeps failing contrast after the fix ships and breaks when a token is added. Storing the identifier is the rule; storing values is the classic mistake. ## Where to keep it | Copy | Purpose | Weakness | |---|---|---| | On the device | read at startup, before the first frame | lost on reinstall or a new device | | On the account | follows the player to other devices | arrives after startup, too late for first paint | | Both | fast startup and cross-device | needs a rule for disagreement | Most apps keep both: the device copy for the first frame, the account copy for continuity. ## Validate on load A stored identifier can outlive its theme: 1. A seasonal event theme is retired after the event. 2. A theme is renamed in a design-system release. 3. A player's account copy was written by a newer app version with a theme this version does not ship. So the app checks the identifier against the themes it actually has, falls back to the **default** when it is unknown, and, for renames, maps the old identifier to the new one. Silently rendering a half-resolved theme is the worst outcome. ## When copies disagree The player changed theme on a tablet; the phone still has the old choice. The system needs one documented rule, commonly: - the **most recent** change wins, using a timestamp stored with the choice; - the device copy is used for the first frame, then updated quietly when the account's newer choice arrives. Other rules are defensible, such as keeping themes per device on purpose, but the rule should be written down and shared by every app using the system. ## What not to persist - Per-component values or overrides: they bypass the theme and survive fixes. - The whole token set: it duplicates what the app already ships. - Anything that is not the player's choice, such as a default the player never picked, since storing it would stop future default changes from reaching them. ## Why interviewers ask this It is a small question that reveals whether a candidate sees a theme as a **reference to living values** rather than a snapshot. Candidates who store values, or forget that a stored theme can disappear, have not yet run a system through several releases.

  • Why not store the default theme's identifier for players who never chose one?
    Because then a future change of default never reaches them: the app would treat an old default as a deliberate choice. Store only what the player picked, and leave the absence of a choice to mean follow the current default.
  • A stored theme was renamed in a design-system release. How should the app handle it?
    Keep a small map from old identifiers to new ones, resolve through it on load, and rewrite the stored copy with the new name. Without that map the player silently falls back to the default and loses a choice they made.

saying these in an interview costs you the question

  • Store the resolved colors so the theme loads without lookups.
  • Storing the choice only on the account is enough.
  • A stored theme identifier will always exist in later releases.
  • Save the default theme for players who never picked one.
  • Persist each component's values so they look identical later.