Decide where frontend state should live

Interview framing: State placement is an architecture decision. The right owner reduces bugs, rerenders, and coordination cost.

Decision framework:

1. Local component state:

• Use for temporary UI state: open menus, focused fields, local form sections.
• Keeps updates close to the UI that uses them.

2. URL state:

• Use for shareable and restorable state: filters, selected tenant, active tab, search query.
• Important for admin tools where users share exact views.

3. Server cache/query state:

• Use for remote data: policies, users, resources, audit records.
• Needs loading, error, stale, refetch, and invalidation behavior.

4. Context:

• Use for low-frequency cross-cutting state: theme, locale, current tenant, current capabilities.
• Avoid putting rapidly changing data in broad context because it rerenders many consumers.

5. External store:

• Useful for complex client workflows shared by distant components.
• Examples: policy builder draft, simulator workspace, collaborative editor state.

6. Backend-owned state:

• Use for source-of-truth data, security decisions, published policy versions, and audit history.

PlainID-style examples:

• Policy filters belong in the URL.
• Published policy state belongs on the backend.
• Draft editor state may live in a feature store with autosave.
• Allowed actions should come from backend capabilities, not local assumptions.

Good closing: "I keep state as local as possible, make shareable state explicit, and keep security-sensitive state owned by the backend."