3 ms·
From my small experience with Elm all that boilerplate is nicely dealt by compression-oriented programming [1]. It is easy to move common code into helper funct
by fpoling 9y ago
From my small experience with Elm all that boilerplate is nicely dealt by compression-oriented programming [1]. It is easy to move common code into helper function and Elm pure functional nature makes that rather maintainable. The hard part is to come up with good names for those helpers and avoid being too generic when refactoring code.
[1] https://mollyrocket.com/casey/stream_0019.html https://mollyrocket.com/casey/stream_0019.html
- mistersys 9y agoI think the bigger problem here is the load it takes to change from stateless to stateful. Let's say a create a stateless subscribe button component, that's part a of a stateless header component. It just accepts a listener that is called when the button is clicked. Now, my designer wants me to add a dropdown menu to the subscribe button that allows people to enable email notifications. The dropdown menu needs state, so now I add a reducer and model to my subscribe button, I need to wire that up through the stateless header component making it stateful, then finally wire it into the the atom for the app. I ended up doing these chains of updates and adding parameters to add simple features. Also, elm lacks typeclasses. Try making a modular form builder with elm that allows other authors to define fields with custom state, it's a mess.