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
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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.