Why must an entering component's first output carry a start state that changes to the end state only on a later frame?

An entering instance has a timing problem that a static one does not: it wants to be animated from a value it never had. The lifecycle answer is to split its arrival into two committed states. ## Why one frame is not enough A transition is defined by a change: the host notices that a property it can interpolate has a different value than the one it last settled on, and it animates between them. That requires the host to have settled the first value. If an element is attached and the end value is applied in the same pass, the host has a single value, never observes a change, and there is nothing to interpolate - the element appears fully formed. So an entering instance needs two committed states in sequence: 1. Its **first output** is produced with the start state - transparent, offset, collapsed, whatever "not yet arrived" means for this component. 2. The runtime applies that output, so the element now exists in the host carrying the start state. 3. The host is made to settle that state, either by waiting for the next animation frame or by reading a value that forces the host to resolve current style now. 4. The state is changed to the end state, and the host observes a change it can animate. 5. When the animation reports finished, the transitional state is removed so the element is left in its ordinary resting form. Steps 3 and 4 are the two the author can delay. Everything else is the normal first-output path. ## The exception: an animation that declares its own start Not every mechanism needs the two-step dance. A declarative keyframe animation carries its start value inside its own definition, so attaching an element with that animation applied is enough to start it: the host does not need a previous value to compare against. | | interpolate between two values | a self-declaring keyframe animation | |---|---|---| | needs a previously settled value | yes | no | | needs a second committed state | yes | no | | start value lives in | the first output's state | the animation's own declaration | | interruption behaviour | reverses naturally from the current value | restarts or jumps unless explicitly handled | | suits | states that also change later, such as open and closed | one-shot arrivals | ## What the runtime has to offer the author - A hook that runs **after** the first output has been applied to the host, not while it is being produced - before that moment there is no element to animate. - A stable place to keep the entering state, so it can be removed once the animation finishes. - Identity, so an item that leaves and re-enters is matched against the instance that is already animating rather than duplicated. - A completion signal, and therefore the same obligation as an exit animation: if the signal never arrives, the transitional state is never removed and the element is left mid-entrance. ## Failure modes - **Nothing animates.** The end state was in the first output; the element appears complete. This is the default outcome of writing an entrance naively. - **Everything animates at once on first paint.** Every instance in the initial tree is an entering instance, so an unconditional entrance rule fires for the entire screen. Entrances that are meant for later insertions have to distinguish the first output of the whole tree from later ones. - **The transitional state sticks.** No finish signal arrives - the animation was cancelled, had zero duration, or the environment suppressed it - and the element keeps the entering state, often invisible. - **A jump on interruption.** An entering instance that is removed mid-entrance and treated as a fresh exit starts its exit from the end state rather than from where it actually is. - **Layout thrash.** Forcing the host to settle style for every item in a long list, one at a time, is a per-item synchronous cost; whether that is affordable is a host-level performance question, not a lifecycle one. ## Where the models differ The lifecycle is the same everywhere; the seam differs. A runtime that re-runs the component body needs the entering state to be derivable from state that changes between the two commits. A fine-grained runtime can flip a single tracked value and have only that one binding update, which makes the second step very cheap. A compile-time runtime may generate the two-step sequence for a declared transition so the author never writes it. In all three the author's real question is the same: is there a supported moment after my first output reached the host and before the next frame is painted?