Easy to say but less easy to implement if one wants to keep pieces isolated from each other.
Considering the 0.16 counter example, we have an extended view type that can trigger not only counter messages that can be handled by the update function for counter models, it can also generate remove messages that need to be handled further up the hierarchy. In my most recent 0.16 code that needed to deal with this case, I actually found it worked better with lazy view evaluation to supply a similar view function in my code with a Signal.message rather than a Signal.address, but however one handled the exact extra parameters to the view function, the key was that it could generate messages bound for different parts of the model. In 0.17, all messages emerging from a view must be of the same type, so we need to ask "what type?" One approach that has been bandied about here is that the set of counter messages — to continue with referencing the 0.16 counter example — should be extended with a Remove message and the update function should somehow reflect this back up to the parent model. That's ugly because removal is really independent of being a counter. Another approach is to have all of the messages from the view be in the parent model's message set. The view function would know to wrap the child (counter) messages appropriately while leaving the Remove message unwrapped. To do this, the view would need to receive the wrapping function as an extra parameter. Another approach is for the view to define its own message type and then for the parent view to apply a wrapping map that turns these into the appropriate message type for the model hierarchy. These last two seem cleaner in that the low-level model and update functions don't need to learn about the extra functionality that the view can trigger. Both approaches, however, are going to be a bit more convoluted than 0.16 if one needs to send a message that should connect several levels up. Mark (*) Another approach is to extend the counter messages with Remove but treat it as a no-op in the counter update function. The parent update function would specially recognize this action and respond to it rather than passing it on. That seems like a weird coupling mechanism to enforce, however. > On Jun 10, 2016, at 1:17 PM, Max Goldstein <[email protected]> wrote: > > Remember that view will now be view : Model -> Html Msg. Your Msg type should > include multiple tags, one for each old address. > > -- > 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. -- 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.
