State model
Five short essays, part 4 of 5.
Svelte v2 shipped
store.js: an importable, framework-level store object that components anywhere in a tree could subscribe to, independent of where on the page it was created.
ARKlight's
State("count", 0)works differently: it has to appear as a declared child of the
Page(...)it belongs to (or, for a user-defined
@component, instance-scoped to one call of that component) before anything else on the page can
Bind(...)to it, act on it with
Action.*(...), or gate on it with
Show(Predicate.*(...)).
- State(...) called as a bare statement instead of a Page(...) child produces "<state> isn't declared on this page" at build time -- a build-time check a free-floating store object can't offer in the same way.
- Component-scoped state is genuinely instance-scoped: two calls to the same @component on one page never share one value, with no extra wiring needed to keep them apart.
- There is no cross-page store: state doesn't persist across a navigation, which follows directly from there being no large-SPA-style persistent app state at all (see rendering model).
The trade-off is explicit: a store you can import from anywhere is more flexible, but also harder for a static analyzer to reason about than state that must be declared where it's used. Walked through hands-on in
state and actions.