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?
We have:
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.
Pain
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
Other hacks
Future
"Stateful user components" could define own internal state record
Read-only API? Could be useful to have access to the app data model via CollectionModel.fields