4 ms·

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 messa

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.
  - dgreensp 9y ago
    "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.
- KurtMueller 9y ago
  I like Elm and have been creating little side projects here and there but this is a pain point for me. Richard Feldman recently released an open source large Elm app to show how he structures his models, views, and update functions in a large Elm app. Other than that however, the resources don't exist quite yet - it seems like the Elm community is currently debating this however.
KurtMueller 9y ago
A lot of the influential developers in the Elm community argue against components keeping their own local state. In fact, if you try to do this in Elm, you'll run into a lot of pain. Instead, all state is stored in a global tree and is passed down to components as needed.
runeks 9y ago
> Congratulations, you've reinvented objects. Objects are opaque handles to a state machine which contains an undefined state, that's not what Elm is. Elm is pure, so you only define transformations, and compose them together. The runtime system keeps track of state, not you as the programmer. You just define transformations from one or more types to another one, compose them together to form descriptions of how to transform one, e.g., UI layout into another, connect it to user input, and everything is guaranteed to fit together (unless you ignore important warnings). You no longer keep track of state, you define functions that transform one piece of information into another, and define functions that render a static piece of information into a UI.

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.
- dgreensp 9y ago
  "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.
KurtMueller 9y ago
I like Elm and have been creating little side projects here and there but this is a pain point for me. Richard Feldman recently released an open source large Elm app to show how he structures his models, views, and update functions in a large Elm app. Other than that however, the resources don't exist quite yet - it seems like the Elm community is currently debating this however.

KurtMueller 9y ago

A lot of the influential developers in the Elm community argue against components keeping their own local state. In fact, if you try to do this in Elm, you'll run into a lot of pain. Instead, all state is stored in a global tree and is passed down to components as needed.

runeks 9y ago

> Congratulations, you've reinvented objects. Objects are opaque handles to a state machine which contains an undefined state, that's not what Elm is. Elm is pure, so you only define transformations, and compose them together. The runtime system keeps track of state, not you as the programmer. You just define transformations from one or more types to another one, compose them together to form descriptions of how to transform one, e.g., UI layout into another, connect it to user input, and everything is guaranteed to fit together (unless you ignore important warnings). You no longer keep track of state, you define functions that transform one piece of information into another, and define functions that render a static piece of information into a UI.