Thank you for the answer! Wrapping function approach looks the most promising, but it's really worse than using multiple addresses in 0.16. :(
On Friday, June 10, 2016 at 11:52:48 PM UTC+3, Mark Hamburg wrote: > > 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] > <javascript:>> 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] <javascript:>. > > 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.
