Hidden React UI needs an explicit lifetime policy

Returning to a tab should sometimes restore an unfinished task. Returning to a different customer's record should not silently restore the previous customer's choices. React's Activity boundary makes retaining an interface easier, but the product still needs a decision about which state deserves to survive. That decision belongs in navigation design before a team starts wrapping screens in Activity.

This November 2026 retrospective concerns React 19.2, released on 1 October 2025. Its important distinction is between preserving an interface and keeping its external connections active. A hidden screen can retain local state while its Effects are stopped. Treating those as separate lifetimes gives the feature a useful purpose and exposes assumptions that ordinary mounting may have concealed.

What hiding preserves

The release announcement defines two modes. In hidden mode, Activity hides its children, unmounts Effects and defers updates until React has no other work. In visible mode, it shows the children, mounts Effects and processes updates normally. This is the historical contract under discussion, rather than a claim about every React release or every rendering environment.

The Activity reference, read in November 2026 as living documentation, explains DOM hiding through display: none, preservation of previous component state and lower-priority rendering when hidden children receive new props. It also describes restoring DOM state, such as unfinished text in an input. These details explain why hiding can support returning to an interrupted task. They do not make local state durable storage across reloads, destroyed boundaries or a new application session.

Consider an illustrative order editor with a details tab and a preview tab. Preserving unfinished text when switching between those tabs may match the user's expectation. Keeping the same editor when the selected order changes is a different decision. The business identity of the record must remain explicit. Visibility alone cannot establish that previously entered information still belongs to the task now on screen.

That distinction also matters for authorization changes. Retained client state is not evidence of continuing permission. If an account changes or access is withdrawn, the application needs its own invalidation rule. Activity does not turn a previous authorization decision into a current one. The relevant question is what the user may continue doing when the interface returns.

Subscriptions need a responsible owner

An Effect that subscribes to an external source needs cleanup that releases its subscription. Activity can invoke that lifecycle, but it cannot invent a missing unsubscribe operation. The same applies to timers or connections owned by the component. A hidden screen should not be assumed to have stopped external work merely because nobody can see its DOM.

Some work may legitimately need to continue. A shared connection serving several visible screens might belong above the hidden boundary, with ownership independent of one tab. A draft-saving process might have a product requirement to continue after navigation. In each case, move responsibility deliberately and describe what ends the work. Keeping a resource alive accidentally is a poor substitute for assigning it an owner.

The reverse transition deserves equal attention. When Effects are recreated, a subscription may encounter data that changed while the screen was hidden. Preserving a selected row does not prove that the row still exists. The interface needs a rule for reconciling retained choices with the latest external data. That rule may preserve a draft while asking the user to resolve a changed prerequisite.

These are design obligations, not observations from a running application. This article reports no React experiment or performance measurement. A team's later verification should follow the actual task: leave and return, change the selected record, withdraw access, and reconnect after missed updates. Each check should have an expected outcome written before implementation, including what information should disappear.

The compiler answers another question

React Compiler 1.0 was announced on 7 October 2025. It is a build-time tool for automatic memoization, with incremental adoption guidance. Its arrival in the same week does not make Activity a compiler feature or make compiler adoption a prerequisite for choosing a state lifetime. Optimizing repeated work and deciding whether a draft survives navigation remain separate concerns.

This distinction helps scope an upgrade. A team can discuss the runtime behavior of Activity without claiming to have evaluated compiler output. It can also adopt compiler tooling without changing the product's navigation policy. Correct React semantics remain necessary; an optimization tool does not supply the missing business rule about which record or account owns a piece of state.

Sometimes remounting is the better policy

The strongest argument against preservation is simplicity. A short, disposable interaction may be easier to understand when every visit starts fresh. Sensitive information or selections that become invalid quickly can make retention actively undesirable. Keeping a boundary around every possible screen would also retain resources without establishing that users benefit from the retained state.

Choose preservation where returning to the same task has clear value and the application can reconcile external changes. Choose resetting where a new visit should establish fresh prerequisites. For custom software development, write those two outcomes into the navigation requirements. Then give each external subscription an owner and an end condition. Activity becomes useful when the product can explain both what survives and what stops.