Machine-checked explicit state: An arrow in the heart of complex web apps

I&#x27;m not sure that Elm architecture really solves the fundamental problem, so much as just moves it to another layer.<p>If you have a big global model, with messages modifying that model, then eventually you&#x27;re going to notice that many places in that model are similar. E.g., widget state for identical widgets on different parts of the page. So you tag the messages that pertain to a particular widget with some kind of coordinate into the global model, and then you call generic widget code with the local widget state as an argument, and the message, to produce a new local widget state. Congratulations, you&#x27;ve reinvented objects.

&gt; 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.<p>I don&#x27;t understand this. There&#x27;s a lot of things that is &quot;available in the application to your users&quot; that is outside of the control of Elm - for example, the text selection, scroll position, window position and resolution...<p>&gt; With Elm, there’s no place to &quot;hide&quot; state in your application that aren’t threaded through the type checker<p>State isn&#x27;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.<p>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?

Maybe better titled &quot;Type-checked explicit state&quot; ...&quot;?

Sounds a lot like Redux?

This doesn&#x27;t make much sense to put in the view. The view is the state and the data that is not visual or the representations of the visual (checkbox :checked = 1 otherwise 0 in the model) isn&#x27;t solved by this. You have now just made the whole view more complicated. Your webservices (or equivalent datasource layer) should have these guarantees about service availability and data formats checked by both sides. I don&#x27;t understand how this is an innovation, since checking the contextual data representation in multiple layers does nothing to address the complexity. Also, testing is increased by spreading it over development time, to solve message format issues...leaving the sinister reality that models are often either mistranslated to&#x2F;from visual elements or there are business logic conditions that are unaccounted for. Complex systems are named such, when you cannot remember every single control in every state. That only takes a few weeks of coding to achieve.

uhh so is this supposed to be web devs meet state machines?<p>I see they&#x27;ve invented a new name to label the innovation as such.