Bundle / Bundle and Submodel
When to use which
| Situation | Use |
|---|---|
| A child placed two or more times, or published for others | a Bundle |
| A child with Subscriptions or resources that are easy to forget to lift | a Bundle, checked by placements.complete |
A one-off child in a single place, such as one @foldkit/ui component | a hand-wired Submodel |
| Something with no Model of its own: a one-shot effect, a DOM attachment | a Command or a Mount, neither |
There is a middle path for the one-off case. A Link names where a child
lives (read, write, toParentMessage), and spreads straight into
Update.foldChild; Link.child yields the fold and the h.submodel drawing
from one statement. A page of a dozen @foldkit/ui components is usually
wired that way, without a Bundle each. See
A Link without a Bundle.
An existing Submodel does not have to be rewritten to become a Bundle.
Bundle.fromParts takes a component's Model, Message, init and its
{ update, view } pair as they are, which is how @foldkit/ui components
are placed (Bundle.fromParts).
Limits
- Managed Resources are provided by tag. Two placements of one bundle that
use the same resource tag would replace each other, so
assemblerefuses them; make such a bundle from a function that takes the tag. - Collections cannot hold resources, for the same reason.
Both limits come from the runtime, not from Bundles: a hand-wired Submodel placed twice with the same tag has the same problem, without the startup error.
See also
foldkit-bundle: the full API, from one placement to collections, wiring and lazy bodies.- Surface and Bundle: a Bundle owns transitions; a Surface observes state owned elsewhere.