5 ms·

Nice, looks very clean. As in Elm, I’ve never fully understood why the events emit a value of some message type that gets interpreted into a function from ‘sta

Nice, looks very clean. As in Elm, I’ve never fully understood why the events emit a value of some message type that gets interpreted into a function from ‘state -> state’ instead of handling with a state transformation directly. Feels like boilerplate to me. I can see situations where this approach is useful, but should it be the default? I guess you can always change your message type to ‘a -> a’ and interpret with ‘id’ if you want to.

fpoling 5y ago
The whole state is immune so it is not possible to handle state change locally in a sub-component. The parent component that embeds it needs to call it and place a new updated component state into a new whole state. But then the parent needs to know which events go into the component. The messages nicely allow for that. Besides already mentioned ability to serialize messages it also allows to preprocess or filter messages in the parent.
pdamoc 5y ago
> I’ve never fully understood why the events emit a value of some message type In Elm, the Model can be updated faster than the DOM. In other words, the view is rendered at the speed of requestAnimationFrame but the model can change in between animation frames. This means that if you handle model changes inside the view you might get out of sync with the model. Here is a program [1] that shows this problem. If you click "SnapShot" you will sometimes get the same number but sometimes get different numbers. [1] https://ellie-app.com/dmddFd9whtYa1 https://ellie-app.com/dmddFd9whtYa1
k_bx 5y ago
Events are always serializeable, inspectable, and can be rewinded backward/forward in Elm. It is indeed producing a lot of boilerplate from my experience, but there is a certain complexity guarantee that comes with it in terms of keeping things simple that I, personally, enjoy.
- sfvisser 5y ago
  Yeah, so the trade-off is you get some stuff for free that you might not need. Paying with some boilerplate. Fine design choice obviously. Writing a lot of react (without redux) I never really miss serializeability and it’s easy to bolt on locally if you need it.
  - k_bx 5y ago
    My personal outcome on this is that I am afraid to touch React after some time or some number of other devs were working on the codebase, while with Elm I’m not afraid to take over a large codebase that was written by someone else. This is very anecdotally and is my personal taste, but I totally stand by it and am having one of these experience right now.
    - mejutoco 5y ago
      This has been my exact experience. After not touching a project I can come back to it pretty much immediately. Also code location (files, one module per file) stops being so important, because the type system just catches everything. Once I learned how to use the occasional escape hatch, with ports, I could mix the random quick hack with the very solid system of elm.

fpoling 5y ago

The whole state is immune so it is not possible to handle state change locally in a sub-component. The parent component that embeds it needs to call it and place a new updated component state into a new whole state. But then the parent needs to know which events go into the component. The messages nicely allow for that. Besides already mentioned ability to serialize messages it also allows to preprocess or filter messages in the parent.

pdamoc 5y ago

> I’ve never fully understood why the events emit a value of some message type In Elm, the Model can be updated faster than the DOM. In other words, the view is rendered at the speed of requestAnimationFrame but the model can change in between animation frames. This means that if you handle model changes inside the view you might get out of sync with the model. Here is a program [1] that shows this problem. If you click "SnapShot" you will sometimes get the same number but sometimes get different numbers. [1] https://ellie-app.com/dmddFd9whtYa1 https://ellie-app.com/dmddFd9whtYa1

k_bx 5y ago

Events are always serializeable, inspectable, and can be rewinded backward/forward in Elm. It is indeed producing a lot of boilerplate from my experience, but there is a certain complexity guarantee that comes with it in terms of keeping things simple that I, personally, enjoy.

sfvisser 5y ago
Yeah, so the trade-off is you get some stuff for free that you might not need. Paying with some boilerplate. Fine design choice obviously. Writing a lot of react (without redux) I never really miss serializeability and it’s easy to bolt on locally if you need it.
- k_bx 5y ago
  My personal outcome on this is that I am afraid to touch React after some time or some number of other devs were working on the codebase, while with Elm I’m not afraid to take over a large codebase that was written by someone else. This is very anecdotally and is my personal taste, but I totally stand by it and am having one of these experience right now.
  - mejutoco 5y ago
    This has been my exact experience. After not touching a project I can come back to it pretty much immediately. Also code location (files, one module per file) stops being so important, because the type system just catches everything. Once I learned how to use the occasional escape hatch, with ports, I could mix the random quick hack with the very solid system of elm.