In a component framework, what is the difference between a component's definition, a live instance, and the output it produces?

The word "component" is used for three different things, and most early confusion about component frameworks comes from collapsing them. Separating them makes almost every later rule - where state lives, when cleanup runs, why reusing a component is safe - fall out for free. ## The definition A **definition** is what you author: a function that returns output, a class with a method that returns output, or a template the toolchain compiles into one of those. It is loaded once for the whole application, and it describes three things: - the **inputs** it accepts from whatever uses it, - the **state** it will want once it is alive, - the **output** it produces for a given combination of inputs and state. A definition is not alive. It has no state of its own, no position in a tree, and no lifecycle. Anything declared *beside* it - at module scope, outside the body the runtime calls - is also created once, which is precisely why such a value is shared by every use of the definition and is a classic source of accidental coupling between unrelated parts of a screen. ## The instance An **instance** is created by the runtime when a definition is used at a position in the component tree. It is the live thing: - it holds that position's state, - it holds whatever was acquired for it - a timer, a subscription, an observer, an in-flight request, - it has a lifecycle: created once, updated many times, torn down once. Its lifetime is tied to the position, not to the definition. If the position disappears, the instance is torn down and its state is gone with it. If the same definition is used at three positions, three instances exist, each with its own state; a write in one is invisible to the other two. ## The output On each update the instance produces an **output description**: a lightweight account of what should appear - which elements, with which values, in which order, containing which children. It is a value, not the interface. The runtime consumes it: it compares the description against what is already there, decides which child instances to keep, create or tear down, and applies the smallest set of changes it can to the host. | | definition | instance | output | |---|---|---|---| | created | once, when the code loads | when the definition appears at a tree position | on every update of that instance | | how many exist | one | one per position where it is used | one per update | | owns state | no | yes | no, it is a plain value | | ends when | the application unloads | that tree position is torn down | the runtime has applied it | ## Why the distinction pays for itself 1. **State placement becomes answerable.** Per-use values belong on the instance; values that every use should genuinely share can sit beside the definition; values two positions must agree on belong above both. 2. **Reuse is safe by construction.** Putting one definition into a list a hundred times produces a hundred instances, so a hundred independent open-or-closed flags need no coordination. 3. **Cleanup has an obvious owner.** Resources are acquired by an instance and released when that instance is torn down. The definition cannot own them, because it is never torn down. 4. **Output is discardable.** Because output is a description rather than nodes, the runtime may build it, throw it away, and build it again without the user seeing anything. ## Where the models differ Runtimes disagree about how visible this machinery is. One that re-runs the whole component body on every update makes the per-update description very concrete - you can watch a new tree being built each time. One with fine-grained dependency tracking runs the body once per instance and afterwards re-evaluates only the individual expressions whose sources changed, so there may be no whole-tree description per update at all. A compile-time model turns the definition into instructions that create and patch host nodes directly, so the "description" survives only as a compiled update path. The three-way split still holds in all of them - code loaded once, an instance that is alive, per-update work whose product the runtime applies - but only the first literally hands back a tree. ## The mistakes this distinction prevents - Keeping per-use state at module scope beside the definition, then being surprised that two positions share it. - Expecting state to survive when the position it lived at is removed and later recreated. - Treating the returned output as the live interface and trying to mutate it. - Assuming "the component" writes to the screen, which makes the runtime's batching and ordering look arbitrary.