We're still awaiting an official answer from Evan. In the meantime, the best answer I've seen from the standpoint of not contaminating the counter messages and update function with something that they don't care about is to put the complexity in the view function which is, I would argue, where it belongs since this it's a view layout issue that forces the remove button to be included in the counter view. One way to do this is to extend the view function with two arguments: one is a function to map the counter messages to the parent message space and the other is the parent message that the remove button should send.
Mark > On Jul 7, 2016, at 10:50 AM, Sandi Dušić <[email protected]> wrote: > > In Elm 0.16 the Architecture tutorial had one more button list example (I dug > that up from an old commit), aside from this one. Each counter would have > it's own remove button which would remove that exact one when clicked, unlike > in the simpler example with a sole remove button that removes the first > counter. This was accomplished by passing two addresses to the counter view, > one for it's own actions and another which it's father component > (CounterList) handled, used for signaling removal. > > I did the exact same thing in my application. I have a bunch of small > components in a big component, and the big component needs to know when one > of the small ones has been clicked. How do you do this in 0.17? Is it > impossible, since they removed the example which is supposed to implement it? > > This is the only thing I can think of: Add the message that needs to be sent > upwards to the big component to the message union of the small component (in > the CounterList, this would mean Counter.Msg has Remove). When the big > component gets a small component action, it would first check with an if > whether it's the one it needs to handle (if msg == Counter.Remove then ...). > If so, it can handle it (remove the Counter), otherwise it would just > regularly pass it to Counter.update. > > To me that seems like it goes against the principles of Elm Architecture. You > can no longer treat components (and especially their actions) like black > boxes, but rather you have to tear them apart in a way. They cannot fully > define their interface. I don't know, it's just weird. > > If there's a way to define custom subscriptions they might be leveraged to > solve this, but I don't see a way to do that in the API. I apologize if this > is a silly question, 0.17 is still new to me. > -- > 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.
