A collapsible panel's form loses everything typed into it whenever the panel is collapsed and reopened. Why, and what are the options?

This is the most common consequence of the fact that a conditional in described output is not a visibility switch. It decides whether the subtree **exists**, and existence is what instance state is tied to. ## What actually happens on collapse When the condition turns false, the next render's description simply has no such subtree. The runtime compares that with what it had and concludes the whole branch is gone, so it: 1. runs cleanup for every effect, subscription, timer and listener registered by the components inside; 2. discards those component instances, and with them all state they held; 3. removes the host nodes. Anything the host itself was keeping on those nodes goes with them: - the current text of a field the framework was not controlling; - which element had focus, and any selection or caret position inside it; - the scroll offset of a scrollable region; - a transition or animation in progress; - an open native control, such as a date or file picker. On reopen the runtime performs a **first render** of a brand-new instance, so every value starts at its initial state. Nothing is broken; the code asked for exactly this. ## The three ways out | approach | what survives | what it costs | |---|---|---| | lift the values above the conditional | every value you lifted, by construction | the state must be modelled somewhere durable | | keep it described, hide it instead | state and nodes, plus scroll, focus and animations if the node stays rendered | effects and subscriptions keep running; nodes stay in the tree | | save on cleanup, restore on mount | whatever you remembered to save | most code, easiest to drift out of sync | **Lifting** is the fix that scales. Move the form's values to state owned by an ancestor that is not inside the conditional — or to a store, or to the URL when the value belongs in a shareable address — and the subtree becomes a view over data whose lifetime is independent of it. This is usually also the right model: draft form values that matter are application state, not a rendering detail. **Hiding** keeps the instance alive because the subtree is still described. It is the right answer when what must survive is not just values but host-held state — a half-scrolled list, an editor with an undo stack — which lifting cannot reproduce. One caveat: a hide that takes the element out of rendering altogether still drops focus, so preserving focus depends on which hiding mechanism you choose. Be deliberate about the costs: effects, polling and subscriptions inside keep firing, the nodes stay in the tree with their memory and layout cost, and you must ensure hidden content is genuinely removed from the accessibility tree and from keyboard focus order rather than merely made invisible, or keyboard and screen-reader users will land inside a collapsed panel. **Save and restore** is a last resort. You persist the values as part of cleanup and rehydrate them on the next mount. It works, but every new field is a new thing to remember, and there is no compiler to tell you that you forgot one. ## Diagnosing it in the wild The symptom is easy to confirm. Watch whether the subtree's setup work runs again on reopen — a mount-time fetch firing a second time, a log line from initialisation, cleanup running on collapse. If it does, you are unmounting. If the values come back but focus and scroll do not, you have lifted state but the host nodes are still being recreated. A related variant is worth recognising: state can also vanish without a conditional at all, when the runtime concludes the instance at a position is a different instance than before and therefore replaces it rather than updating it. ## The judgment being tested The weak answer is to reach for hiding immediately, because it makes the symptom disappear with one line. The strong answer separates the two questions. *What must survive?* If it is data, lift it, because that is where the data belonged anyway. If it is host-held interaction state you cannot reconstruct, hide it and pay the running cost knowingly. *What must stop when the panel closes?* If there is a subscription, a poll or a video inside that must not keep running while collapsed, hiding is actively wrong and you need the unmount plus lifted state. Stating both halves — and naming the accessibility obligation that comes with hiding — is what distinguishes an engineer who has shipped this from one who has read about it.