that would be really appreciated. I didn't find many articles on this
topic, and in my opinion, a language in it's "early stages" should be very
opinionated. We also must understand that many developers (like me) comes
to elm from a react perspective, where split into small components is the
way to go. An article that explain elm for react users in this perspective
should become very interesting.
Many thanks ossi and max for sharing your opinions!
Il giorno domenica 18 settembre 2016 21:05:53 UTC+2, Ossi Hanhinen ha
> 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
>> 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.