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 to [email protected]. For more options, visit https://groups.google.com/d/optout.
