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 
format like:

   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

Mark

> 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 
> code 
> https://www.youtube.com/watch?v=vpc80c5iC6k&list=PLglJM3BYAMPH2zuz1nbKHQyeawE4SN0Cd&index=2
> 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
>>> 
>>> Mark
>>> 
>>> -- 
>>> 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 
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.

Reply via email to