It can be designed with random auto-generated states, and given a default state. It's kinda like Storybook. See: ./test-app-state/default
It's possible reference other CMS data in the app state.
This page loads that default state html and mounts it in a `template` element. It doesn't do much there, but that seems neat. Then it clones it to div#mount above.
UI defines how we view (and change) the state of an app
I feel like this demo sidesteps a lot of complexity, but... how much of that complexity do we actually need?
typed records for state,
a way to update the state,
and a way to update the DOM.
UI is a function of state, f(x)
In order to keep everything library-agnostic, I wrote the simplest event listener (somewhat inspired by Dynamicland's Realtalk) and a naïve DOM mutator. You can imagine React or Vue or something visual to connect these events with little bits of scripts to mutate state and rerender the app.
Syncing custom attributes and selectors in code
Syncing code between local dev to the Designer
Publish and refresh: I'd prefer a new view that does LiveReload on (auto)save
Text and visibility can be bound in the template page, but not other facets of the state
"Stateful user components" could define own internal state record