So I guess, my question becomes: why is it frowned upon in the Elm community to divide your development into components?
I mean, as of now, Elm is used to develop user interfaces. User interfaces are naturally made of components. Date pickers, schedules, tabbed panes, menus, road maps, grids, pages, music staffs, pdf viewers, toasts, chatboxes, graphs, are just a few examples that come to mind. Having an Elm module that implements a component is great for reuse. Why would it be a bad thing?
Say I have an application that allows you to produce and edit documents that are sequences of paragraphs, images and music staffs.
Wouldn’t it be stupid to insist on putting all the messages into one update function ?
Wouldn’t it be more reasonable to make
- a module that implements a music staff, that allows you to place a note on a staff when you click on it, change the time signature etc…
- an image holder module that allows you to resize an image by a drag, or other kind of behaviors
- a paragraph module that allows you to change its font size, font colors etc…
- And have the main application delegate these behaviors to the smaller components ?
I could then publish, say, the music staff component on package.elm-lang.org for other people to use, or improve. This is better for the Elm community than a monolithic approach, where the messages dedicated to my music staffs would be some subtypes of a Message type of some big application I’m the only person to use.