On Jun 28, 2016, at 6:12 AM, Wouter In t Velt <[email protected]> wrote: > > My specific use case: I have a list of children with a number of internal > messages (e.g. updates on each child). One of the functions I need to > implement is 'RemoveMeFromList', which is a button on each child. This > message type can only be handled by the parent, through removing child from > list and no longer rendering it in view.
This is a place where presentation (view) hierarchy and data (model) hierarchy mix uncomfortably. Removal from the list of children has little to do with the child unless there are other updates that accompany the removal that only the child understands. It is purely an update to the parent. This is different from the child needing a way to express "I've run out of money". That is based on an update to information local to the child. What muddles this up is that the remove button is often presented as part of the presentation of the child and, in The Elm Architecture, we are trained to think of the presentation as being built by a view function from model to HTML and hence if the presentation contains a removal button then remove must be a message destined for the model. The Elm 0.16 architecture tutorial handled this by providing a separate address to which the remove message could be delivered. The Elm 0.17 documentation at present is silent on the subject. There have been proposals for how to deal with this in an Elm 0.16 style but they haven't been officially endorsed and result in view functions with a return type of Html parentMsg as opposed to Html ChildMsg which is a little ugly. There are also suggestions to use extra return values from the update function (as the essays linked to in this thread do) but those result in the child update function containing entries that basically just serve to route the remove message up to the parent thereby contaminating the update function with a complexity that previously only affected the view function. I've still been on Elm 0.16 because I've been waiting for key support, but I've been looking at 0.17 and one thing that does have me worried is that in getting rid of addresses may have increased coupling between the view hierarchy — driven by UX design concerns — and the model hierarchy which should be driven by data consistency concerns. While the default handling in the past for addresses led to a tight correspondence between the hierarchies, one could always work around it by providing an address along with a model (or as part of a model) wherever appropriate and it didn't feel too unnatural. One could probably do something similar by using routing functions(*) in much the same way as addresses in 0.16 but they feel like a fight against the intended use pattern. But all of those judgments are suspended pending more complete documentation for these cases for 0.17. Mark (*) view : (msg -> rootMsg) -> model -> Html rootMsg This could just use the standard Elm 0.17 routing instead (or in its implementation) but it stresses that the route isn't driven by the presentation but is rather information describing how to get messages to the relevant portion of the model. To make it work well with lazy HTML, it really needs to be based on embedding the route into the model and only computing it at initialization time for that piece of the model. -- 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.
