Completely hide state management from the app declaration:
32
51
My goal is to define apps by their datatype. The rest -- glueing some backends, solving accessibility issues with the fragmented web platform, reinventing UX patterns -- should not be part of my app code.
Restrictive already puts the complete Ui state into the Url so that the model and update is much simpler. Now, what if a similar framework would encode and decode the model and store it on the backend without any message wrangling inside the app? Then we could say the Url is the single source of the Ui state, the backend (or an offline-first local store) is the single source for the model, and all the application does is to declare how they work together. If we embrace the elm-multitool, we only need to describe the data structure once, including all the invariants, and then, as far as necessary, tweak the default controls offered by elm-any-type-forms. While tweaking, we can use the Link type to describe Ui state transitions and their effect on the visibility of Ui items (Pages, Tabs, Filters, Progressive Disclosure, Snacks). Every bit of information is either part of the synced model, or part of the Url. None is just in-memory.
Completely hide state management from the app declaration:
32
51
My goal is to define apps by their datatype. The rest -- glueing some backends, solving accessibility issues with the fragmented web platform, reinventing UX patterns -- should not be part of my app code.
Restrictivealready puts the complete Ui state into the Url so that the model and update is much simpler. Now, what if a similar framework would encode and decode the model and store it on the backend without any message wrangling inside the app? Then we could say the Url is the single source of the Ui state, the backend (or an offline-first local store) is the single source for the model, and all the application does is to declare how they work together. If we embrace the elm-multitool, we only need to describe the data structure once, including all the invariants, and then, as far as necessary, tweak the default controls offered by elm-any-type-forms. While tweaking, we can use theLinktype to describe Ui state transitions and their effect on the visibility of Ui items (Pages, Tabs, Filters, Progressive Disclosure, Snacks). Every bit of information is either part of the synced model, or part of the Url. None is just in-memory.