5 ms·

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

81 points by mrbbk 9y ago

woah 9y ago
Sounds a lot like Redux?
- KirinDave 9y ago
  Redux is actually using a hybrid between message passing and FRP.
- mrbbk 9y ago
  I think the ideas are similar, but does Redux have the statically checked component? That's the killer here.
  - wwwigham 9y ago
    If you use redux with a type checked language like TypeScript or Flow it does.
    - ng12 9y ago
      Not without conscious effort on the part of the developer. I almost wish there were a Typescript-first re-implementation of Redux.
      - ioddly 9y ago
        I was just wishing for the same thing myself.
      - Keats 9y ago
        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.
    - mrbbk 9y ago
      Sounds like Elm! :-D
    - deleted 9y ago
      [deleted]
- dsiegel2275 9y ago
  Yes - the creator of Redux, Dan Abramov, was inspired by the Elm Architecture in his design of Redux.
cpr 9y ago
Maybe better titled "Type-checked explicit state" ..."?
- davidkpiano 9y ago
  I thought this article was about finite state machines at first!
- mrbbk 9y ago
  Maybe! But I liked separating it from type-checking for the sake of the title.
theincredulousk 9y ago
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 9y ago
  Yes, because of course every state machine use is the same thing, regardless of the domain and other considerations...
jhpriestley 9y ago
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.
- zoul 9y ago
  You make it sound like the Elm architecture us just OOP done wrong or by hand. It’s not. The big difference is who owns the state and who is allowed to change it. If anyone inside the object graph that makes up your app can own and freely change important state, we usually get the tangled mess we know so well. When you move the important state into a single place and only allow it to be modified by a privileged, specialized set of objects reacting to a well-defined set of messages, you get the state under much better control. Which sounds like a great proposition to me.
- dgreensp 9y ago
  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 9y ago
    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.
jack9 9y ago
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.
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 ago
  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.

81 points by mrbbk 9y ago

woah 9y ago

Sounds a lot like Redux?

KirinDave 9y ago
Redux is actually using a hybrid between message passing and FRP.
mrbbk 9y ago
I think the ideas are similar, but does Redux have the statically checked component? That's the killer here.
- wwwigham 9y ago
  If you use redux with a type checked language like TypeScript or Flow it does.
  - ng12 9y ago
    Not without conscious effort on the part of the developer. I almost wish there were a Typescript-first re-implementation of Redux.
    - ioddly 9y ago
      I was just wishing for the same thing myself.
    - Keats 9y ago
      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.
  - mrbbk 9y ago
    Sounds like Elm! :-D
  - deleted 9y ago
    [deleted]
dsiegel2275 9y ago
Yes - the creator of Redux, Dan Abramov, was inspired by the Elm Architecture in his design of Redux.

cpr 9y ago

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

davidkpiano 9y ago
I thought this article was about finite state machines at first!
mrbbk 9y ago
Maybe! But I liked separating it from type-checking for the sake of the title.

theincredulousk 9y ago

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 9y ago
Yes, because of course every state machine use is the same thing, regardless of the domain and other considerations...

jhpriestley 9y ago

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.

zoul 9y ago
You make it sound like the Elm architecture us just OOP done wrong or by hand. It’s not. The big difference is who owns the state and who is allowed to change it. If anyone inside the object graph that makes up your app can own and freely change important state, we usually get the tangled mess we know so well. When you move the important state into a single place and only allow it to be modified by a privileged, specialized set of objects reacting to a well-defined set of messages, you get the state under much better control. Which sounds like a great proposition to me.
dgreensp 9y ago
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 9y ago
  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.

jack9 9y ago

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.

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 ago
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.