
Machine-checked explicit state: An arrow in the heart of complex web apps - mrbbk
https://blog.reifyworks.com/machine-checked-explicit-state-an-arrow-in-the-heart-of-complex-web-applications-bbe1ef2038ed
======
jhpriestley
I'm not sure that Elm architecture really solves the fundamental problem, so
much as just moves it to another layer.

If you have a big global model, with messages modifying that model, then
eventually you'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've reinvented objects.

~~~
dgreensp
I've looked into Elm a little bit, read the docs and watched the videos, and I
tend to agree with the first paragraph. The architecture is mostly about how
to handle updates to a single state machine and render it. There is no deep
insight about how to compose stateful components into larger stateful
components, and up and up, to build a sophisticated app without things getting
out of hand, except: "A component is just a module with types and functions.
Compose them however you want." As people build more and more sophisticated
widgets with Elm, it pushes the state of the art in this respect, but the
problem is still there as far as I can tell.

~~~
zoul
I think that Elm’s deep insight into composing stateful components is that _if
you keep important state hidden inside components, it will always hurt_.

~~~
dgreensp
"Hidden" isn't the same as implicit. State might be hidden in the sense that
it is encapsulated. For example, sometimes we want to treat a text field
component as just an "editor for a string value," without worrying about the
cursor and selection state, or the state of the autocomplete dropdown if there
is one, etc. That said, in the fullness of time, you do eventually find
yourself wanting access to this state for some purpose or another.

Every time you use an HTML input tag, you are using an abstraction over state,
and the first time you need access to the input element's cursor and
selection, you realize you've been pretending the element had less state than
it had, which is a pretty useful thing to do.

If I can write a form component that needs an "editor for a string" component,
specified as a type, and fill that need with a "fancy editor for a string"
component that has a more elaborate model that I can abstract away, then I
think we're in business, but I can't quite picture how that would work.

------
millstone
> 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
Detailed 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.

------
cpr
Maybe better titled "Type-checked explicit state" ..."?

~~~
mrbbk
Maybe! But I liked separating it from type-checking for the sake of the title.

------
woah
Sounds a lot like Redux?

~~~
mrbbk
I think the ideas are similar, but does Redux have the statically checked
component? That's the killer here.

~~~
wwwigham
If you use redux with a type checked language like TypeScript or Flow it does.

~~~
ng12
Not without conscious effort on the part of the developer. I almost wish there
were a Typescript-first re-implementation of Redux.

~~~
Keats
Redux makes it a bit annoying with the actions/actions creators. I've switched
my project (written in TypeScript) from redux to mobx and, since it's just
calling normal functions, everything is typed without making any extra effort.

------
jack9
This doesn'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'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'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/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.

------
theincredulousk
uhh so is this supposed to be web devs meet state machines?

I see they've invented a new name to label the innovation as such.

~~~
coldtea
Yes, because of course every state machine use is the same thing, regardless
of the domain and other considerations...

