Two points from the above exchange that I'd like to emphasize:

> Making full TEA (init,update,view,subscriptions) reusable components in 
> elm can be painful to wire up, so I would suggest not doing so unless/until 
> you really have to use a component in several places or are publishing a 
> library with one.

> The most elegant solution is to NOT split modules, and keep things 
> together.

By breaking the app up into ListItem and Form modules, you've broken it up 
by UI features. This is very similar to React components, all the button 
code in one place, but before React "separation of concerns" meant 
something different. We kept our styles separate from out document 
structure separate from our logic. Yes, this was partially due to 
boundaries between CSS, HTML, and JS. But in Elm, when your one module gets 
to be 300+ LOC, you need to break it up. How?

Instead of splitting by UI feature, split by purpose of code and location 
in the stack. So you might have a View module that only exposes the 
top-level view function, and hides all its helpers. You might have an Api 
module (btw, sentence case your acronyms) that knows how to make both GET 
and POST requests, exposing functions that return Tasks. You want these 
helper modules to provide functions that Main can use, not components that 
want their own state. Main should own all the state. Oh, and if everyone 
wants to know the type of Model, you can put a select few definitions in a 
Common module which everyone else imports.

In Elm, premature refactoring is the root of all evil.

You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to