4 ms·

Yes. The deeply nested components thing isn’t an issue at all. You build “components” as stateless views. It’s fundamentally the same as building an application

Yes. The deeply nested components thing isn’t an issue at all. You build “components” as stateless views. It’s fundamentally the same as building an application out of all stateless components in redux. Your model (the central state) becomes larger and more complex, but the size of your update function doesn’t expand as much as you’d think. Meanwhile, the benefits from type-safety, pure functions, and extremely well-designed libraries like elm/parser & elm-UI are really terrific.

ModernMech 8y ago
What is meant by "deeply nested components" and why can't you do them in Elm?
- zoul 8y ago
  I think “deeply nesting components” means dropping a stateful component (view+behaviour+state) anywhere in your app without anything else changing. That’s not possible in Elm since the only place to store state is the central state storage. Which makes perfect sense, but often freaks people out, since it’s an uncommon design constraint.
  - badfrog 8y ago
    With only one store, how do you keep your state reasonably organized when you get up to hundreds of pieces of data to manage? And what do you do about generic reusuable components that need state? Say a typeahead search that needs to track the input string and the list of results from the server?
    - pault 8y ago
      You can think of each root-level branch of the state tree as its own "model". In redux (I haven't used elm much) I implement generic components by finding a property that can be used to derive a unique key and creating an entry for each component in the reducer.
    - danabrams 8y ago
      If you really really really can’t live without a statefull component, you can always build a custom element (which can be a wrapper around an elm app). But reusable views with fairly complex state are used; they require a little bit of wiring up, but it means you know exactly where to look when there’s a big/problem.
    - razze 8y ago
      Your state can be a tree, if it needs to be, so you can nest. A normal practice is to have a model per page. For e.g. https://github.com/rtfeldman/elm-spa-example/blob/master/src/Page/Home.elm#L31-L40 https://github.com/rtfeldman/elm-spa-example/blob/master/src... And you can have another item next to it for global state if you need to. https://github.com/ohanhi/elm-shared-state https://github.com/ohanhi/elm-shared-state explains one way to do this
- pdamoc 8y ago
  This has to do with state partitioning. The official Elm Architecture tutorial used to contain some examples of encapsulating functionality into modules that would then be reused. The pattern presented there was abused by some folks and some problems that were introduced by state partitioning started to appear. There was a lot of talk about boilerplate and inter-component communication. A lot of these problems could have been avoided by not being so aggressive with the partitioning and so, "thinking in terms of components" has been discouraged ever since. You can still define components by implementing the model/update/view triplet pattern but the main recommendation is to do it only when this is unavoidable (e.g. Pages or highly complex widgets).

ModernMech 8y ago

What is meant by "deeply nested components" and why can't you do them in Elm?

zoul 8y ago
I think “deeply nesting components” means dropping a stateful component (view+behaviour+state) anywhere in your app without anything else changing. That’s not possible in Elm since the only place to store state is the central state storage. Which makes perfect sense, but often freaks people out, since it’s an uncommon design constraint.
- badfrog 8y ago
  With only one store, how do you keep your state reasonably organized when you get up to hundreds of pieces of data to manage? And what do you do about generic reusuable components that need state? Say a typeahead search that needs to track the input string and the list of results from the server?
  - pault 8y ago
    You can think of each root-level branch of the state tree as its own "model". In redux (I haven't used elm much) I implement generic components by finding a property that can be used to derive a unique key and creating an entry for each component in the reducer.
  - danabrams 8y ago
    If you really really really can’t live without a statefull component, you can always build a custom element (which can be a wrapper around an elm app). But reusable views with fairly complex state are used; they require a little bit of wiring up, but it means you know exactly where to look when there’s a big/problem.
  - razze 8y ago
    Your state can be a tree, if it needs to be, so you can nest. A normal practice is to have a model per page. For e.g. https://github.com/rtfeldman/elm-spa-example/blob/master/src/Page/Home.elm#L31-L40 https://github.com/rtfeldman/elm-spa-example/blob/master/src... And you can have another item next to it for global state if you need to. https://github.com/ohanhi/elm-shared-state https://github.com/ohanhi/elm-shared-state explains one way to do this
pdamoc 8y ago
This has to do with state partitioning. The official Elm Architecture tutorial used to contain some examples of encapsulating functionality into modules that would then be reused. The pattern presented there was abused by some folks and some problems that were introduced by state partitioning started to appear. There was a lot of talk about boilerplate and inter-component communication. A lot of these problems could have been avoided by not being so aggressive with the partitioning and so, "thinking in terms of components" has been discouraged ever since. You can still define components by implementing the model/update/view triplet pattern but the main recommendation is to do it only when this is unavoidable (e.g. Pages or highly complex widgets).