A removed component must animate out first. What does the runtime have to defer, and what breaks if the animation never reports finished?

An exit animation turns one event into two. "This item is gone" and "this instance is destroyed" used to happen together; now the first happens immediately and the second waits. ## Two removals, not one 1. **Logical removal.** The data no longer contains the item, or the condition that included the component is now false. From the application's point of view it is gone. 2. **Visual removal.** The animation plays. The instance's output is still attached to the host, occupying space or floating above it, for as long as the animation lasts. 3. **Physical teardown.** The registered releases run, the state is dropped, and the host nodes detach. This happens only when something signals that the animation finished. For this to work, the runtime must keep the instance in its tree after the author's data says it is gone - a deliberately inconsistent middle state - and must be told when to end it. ## What the runtime holds open - The instance itself, with its state and its registered releases still pending. - Its output, still attached to the host, still laid out and still hit-testable. - Its position in the tree, so that a re-entry of the same identity can be matched against it. - Any pending work it owns: timers still tick, subscriptions still deliver, requests still resolve. That last point is the one that surprises people. A leaving instance is fully alive. It can respond to input, steal focus, log a click on something the user believes is disappearing, or receive a data push and re-render mid-flight. ## The failure modes | cause | symptom | mitigation | |---|---|---| | the finish signal never arrives | teardown never runs; one stranded instance and its nodes per removal | treat the signal as unreliable: add a timeout, or take a completion promise from the animation itself | | a zero-duration or disabled animation | no end event is emitted at all, so removal appears to hang | detect the no-animation case up front and tear down immediately | | the subtree is hidden rather than animated | the animation never starts, so it never ends | never hide the leaving subtree; animate it, or skip the deferral | | an interrupted exit restarts | the item jumps to its start state and replays | reverse from the current visual state and reuse the same instance | | the leaving subtree stays interactive | clicks and focus land on a ghost | mark it inert: ignore input, stop applying new data, pause its own work | | removal is committed only when the animation ends | the data lies for the duration; a second removal double-fires | commit the removal in data immediately and defer only the visual teardown | ## Interruption is the normal case, not the edge Lists get filtered twice in a second. A dialog is dismissed and reopened. When an identity that is currently leaving comes back, there are three possible behaviours and only one of them looks right: - **Adopt and reverse.** The leaving instance is matched, its pending teardown is cancelled, and the animation runs backwards from wherever it had reached. Continuous, and the instance keeps its state. - **Duplicate.** A second instance is created at the same position, and two copies animate against each other at once. - **Wait and rebuild.** The exit is allowed to finish, teardown runs, and a fresh instance is built - so the item visibly completes its disappearance, pops back, and has lost whatever state it held. Reversal is also why the animation should be expressed as a move between two states rather than as a one-shot sequence: a sequence that only knows how to play forwards has nowhere to reverse from. ## The reorder case is not an exit at all When a keyed list is reordered, nothing leaves: the same instance is reused at a new position. There is nothing to defer, and an exit animation contributes nothing - the item simply appears in its new place. Animating movement needs something else from the runtime: the position **before** the update and the position **after** it, handed to the author at a moment when both are known, so the difference can be animated. Which changes cause reuse rather than replacement is the reconciler's decision and belongs to the identity and keys topic; the lifecycle point here is that "animate removal" and "animate movement" need different hooks. ## Deciding how much of this to own A framework-supplied transition wrapper exists to own exactly this contract: it holds the leaving instance, listens for completion, handles interruption, and applies the transitional states. Doing it by hand with the host's own animation facilities is possible and sometimes necessary, but the hand-rolled version has to reimplement the same five obligations - defer teardown, detect completion, provide a fallback when completion never comes, make the leaving subtree inert, and adopt the leaving instance on re-entry. The obligation list is what to interrogate in a review, whichever route is taken.