5 ms·
> state is the stuff that changes. In the Elm architecture, State has to be represented in code, in a very specific way, for it to be available in your applicat
by millstone 9y ago
> state is the stuff that changes. In the Elm architecture, State has to be represented in code, in a very specific way, for it to be available in your application to your users.
I don't understand this. There's a lot of things that is "available in the application to your users" that is outside of the control of Elm - for example, the text selection, scroll position, window position and resolution...
> With Elm, there’s no place to "hide" state in your application that aren’t threaded through the type checker
State isn't so much hidden as collaborative. Multiple components participate and have a need to store independent UI state. For example, a table component might want to control scrolling, filtering, and selection state, while delegating populating the row data to the app.
Is it possible in Elm to allow separate software components to maintain their own independent states, without requiring some god-component to have global knowledge?
- zoul 9y agoDetailed UI state like scrollbar position usually isn’t interesting in the sense that you would need to directly respond to it, share it, persist it, etc. That’s why you don’t usually include it in your application model. State being collaborative is precisely the problem. If all the components owned important state, they would need to share it with each other. This gets real complicated very quickly, especially when multiple parts of the app need to change that state. So the main proposition of Elm is exactly that separate components should not hold important state and whatever that needs to be shared should be centralized and modified in one place. Which sounds like the God Object antipattern, but is not, mainly because you can only change the state indirectly, by sending well-defined messages.