Argument for the first style: It extends nicely to handle things like sorted
table where we need to generate messages of the same type for table sort state
changes and for messages from the displayed table data. That's harder to do
with the second style — you basically need to create a type to wrap the message
types just so that it can get unwrapped at the next level up.
Argument for the second style: If you need to add extra parameters as part of
the mapping — remember our old friend the list of counters — this may be better
captured in a curried map function than in building a new config record for
each usage. (In my checkbox example, the currying work is the same and hence
not as obviously an issue, but the first style generalizes to a config record
that can't just be curried.)
One thing I'm liking about the first style is that it could lead to a
convention of writing views that just need to set their state value using a
view SetState model.state
where the message function is essentially paired with the incoming state. If
you want to talk to both local state and shared state directly from the view,
this would extend to:
view SetSharedState model.sharedState SetLocalState model.localState
> On Sep 22, 2016, at 4:03 AM, Joaquín Oltra <joaquin.ol...@gmail.com> wrote:
> First one as goto option for splitting view functions out.
> Second one if viewCheckbox is a standalone reusable triplet with internal
> state and Msg types (much less often).
> This talk from Ossi gives great insight on different ways to organize your
> I found it very useful
>> On Wednesday, September 21, 2016 at 8:16:33 PM UTC+2, Nick H wrote:
>> I prefer the former style. It's less verbose, and it means my Main module is
>> the only one that needs to import Html.App. Also, with the latter style,
>> your helper is going to have something like "Html.Events.onCheck identity",
>> which seems a little silly.
>> That's just my preference though. I think either one seems fine, as long as
>> you're consistent :-)
>>> On Wed, Sep 21, 2016 at 10:19 AM, Mark Hamburg <mhamb...@gmail.com> wrote:
>>> When writing a view function (or helper function that generates part of the
>>> view hierarchy), is it better to take a function mapping values or messages
>>> to parent messages or to use Html.App.map for this? In other words, is it
>>> better to write:
>>> viewCheckbox SetMyCheckboxState "My Checkbox" model.myCheckboxState
>>> viewCheckbox : (Bool -> msg) -> String -> Bool -> Html msg
>>> or to write:
>>> Html.App.map SetMyCheckboxState
>>> <| viewCheckbox "My Checkbox" model.myCheckboxState
>>> viewCheckbox : String -> Bool -> Html Bool
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
> 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.
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.