Q170: React Activity, Preserved State and Hidden UI

What Interviewers Want To Evaluate

This question checks whether you understand the trade-off between unmounting UI and keeping it mounted. Interviewers want preserved state, hidden effects, tabbed interfaces, modals, background work, memory cost, accessibility, and when React Activity-style patterns are useful.

Senior answers should reason about user continuity and resource ownership.

Short Interview Answer

Preserved hidden UI keeps component state alive while the user is not currently viewing it. This is useful for tabs, side panels, drafts, and workflows where unmounting would lose progress. React's Activity model is designed for hiding UI while preserving state and suspending hidden effects. The trade-off is memory and complexity: not every hidden component should stay alive forever.

Detailed Interview Answer

Many interfaces have this choice:

unmount inactive UI and lose local state
keep inactive UI mounted and risk background work
preserve state while limiting hidden activity

Tabbed interfaces show the problem clearly.

If each tab unmounts on switch, form drafts and scroll positions may reset.

If all tabs stay mounted with CSS, effects may continue running unnecessarily.

Classic Conditional Rendering

{activeTab === "details" ? <Details /> : null}
{activeTab === "history" ? <History /> : null}

This unmounts inactive tabs.

That is fine when inactive state should reset.

It is frustrating when users lose draft work.

CSS Hidden Approach

<section hidden={activeTab !== "details"}>
  <Details />
</section>
<section hidden={activeTab !== "history"}>
  <History />
</section>

This can preserve state.

But effects inside hidden sections may still run, depending on the implementation.

That can waste resources or keep subscriptions alive when the user does not need them.

Activity Mental Model

React Activity-style hidden UI aims to preserve component state while treating hidden work differently.

The useful mental model:

visible: UI is active and effects run
hidden: UI state is preserved but visible work is paused or deprioritized

This helps solve the unmount vs keep-mounted trade-off.

Good Use Cases

Preserved hidden state is useful for:

multi-tab forms
wizard steps
side panels
draft editors
modal workflows that reopen soon
expensive panels that should not refetch each time
background route-like sections

The common theme is continuity.

Poor Use Cases

Do not preserve everything.

Bad candidates:

huge virtualized tables no longer needed
media players that should stop
live subscriptions for invisible data
security-sensitive flows after timeout
large canvases or charts with high memory cost
rarely revisited pages

Preserving state has a cost.

Accessibility Considerations

Hidden UI should not be reachable by keyboard or screen readers unless it is meant to be active.

Check:

focus does not move into hidden panels
hidden headings are not announced as current content
aria-selected and tab relationships are correct
modal hidden content is inert
visible labels describe the active region

State preservation should not break navigation semantics.

Effects and Subscriptions

Hidden UI often owns effects.

Examples:

polling
websocket subscription
animation loop
resize observer
timer
media playback
analytics heartbeat

If hidden UI remains mounted, these effects need clear behavior.

Some should pause. Some should continue. Some should move to a parent store.

State Ownership

Sometimes preserving local state is the wrong fix.

If state must survive navigation, reloads, sharing, or collaboration, local hidden state is not enough.

Consider:

URL state
server draft state
local storage
external store
form library state
route cache

Use hidden state for short-lived UI continuity, not durable persistence.

Common Mistakes

A common mistake is unmounting forms and losing user input.

Another mistake is hiding content visually but leaving it focusable.

Another mistake is keeping expensive effects alive in hidden panels.

Another mistake is preserving sensitive UI after logout or timeout.

Another mistake is treating state preservation as a substitute for persistence.

Senior Trade-Offs

Unmounting is simple and releases resources.

Keeping mounted preserves continuity but can waste memory and background work.

Activity-style preserved UI gives a better middle path, but the app still needs ownership rules for effects, focus, memory, and security.

Code or Design Example

function SettingsTabs({ activeTab }) {
  return (
    <>
      <Panel active={activeTab === "profile"}>
        <ProfileForm />
      </Panel>
      <Panel active={activeTab === "billing"}>
        <BillingSettings />
      </Panel>
    </>
  );
}

The implementation should preserve or reset state intentionally, not accidentally.

Debugging Workflow

When hidden UI causes bugs:

check whether it is mounted or unmounted
inspect local state reset behavior
test focus movement
check active subscriptions
measure memory
verify timers and animations pause
test logout and permission changes
decide whether state should be durable

Interview Framing

Start with the unmount vs preserve trade-off. Then discuss Activity-style hidden UI, effects, accessibility, memory, security, and persistence alternatives.

Revision Notes

Preserved UI state is about continuity. It needs clear limits.

Key Takeaways

Keep user progress when it matters, but do not keep hidden work alive by accident.

Follow-Up Questions

1. What happens when a component unmounts?
2. Why preserve hidden UI state?
3. What is the risk of CSS-only hiding?
4. What kinds of effects should pause when hidden?
5. How can hidden UI break accessibility?
6. When should state reset intentionally?
7. When should state be persisted instead?
8. What memory costs can preserved UI create?
9. How should sensitive hidden UI behave after logout?
10. How would you test a tabbed form workflow?

How I Would Answer This In A Real Interview

I would say preserved hidden UI helps users keep progress in tabs, panels, and drafts, but it has memory, effect, accessibility, and security costs. I would preserve state only where continuity matters, pause hidden work where possible, and persist state elsewhere when the lifetime must exceed the component.