Fully agreed on what Max said here, but I'd like to add one little point of advice.
Splitting view code that has event handlers out of the original "TEA component" module can feel a little hard because the Msg type needs to be from the original module. The way to go about this is to add a "tagger" parameter in your split-out view function. The "tagger" is either a valid "parent Msg", or a function that returns a valid "parent Msg" type. So as an example, the view helper function's signature could be: `myForm : (a -> msg) -> Html msg`, which means you can use it in any module with a call such as `myForm PostMyForm`, where `PostMyForm FormContents` would be the Msg tagger. You are most likely using this pattern already from the outside. Think of how `onClick NewCatGif` works. You are giving `NewCatGif` as a parameter to the `onClick` helper function, and when the click happens, the resulting Msg is of the correct type for the current module. The exact same thing is what you can do with your view functions. Just add the Msg tagger as a parameter and you are good to go! The sentiment of not refactoring until it's actually necessary was something I tried to put forward in my ElmConf talk a couple of days ago. This advice on how to split view functions out of the modules was, however, something that I now wish I had covered in the talk as well. So I'll try and write a blog post about the subject. :) On Sunday, September 18, 2016 at 11:31:19 AM UTC-5, Max Goldstein wrote: > > 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
