On Wednesday, October 12, 2016 at 5:32:09 AM UTC-6, Max Froumentin wrote: > > Thanks OvermindDL1, that's very helpful. I now understand it's down to the > lack of two-way binding. Makes sense. > Wouldn't it be useful to use a change of id attribute as a change of key? >
Yep, adding an attribute ID of some sort would make that 'more expected', and some vdom libraries do indeed do that (that I could link you to if you are curious at seeing the implementation). :-) On Wednesday, October 12, 2016 at 9:59:47 AM UTC-6, Mark Hamburg wrote: > > On Oct 11, 2016, at 1:09 PM, OvermindDL1 <overm...@gmail.com> wrote: > > > > And as for cocoa, unlike the DOM anytime something like, say a checkbox > is checked, cocoa sends a message to the application to handle the change, > if unhandled then no update would happen... and the app would be frozen as > the event loop would not be processing, unlike the DOM in a browser that > would just keep on puttering along even if no handlers for any events were > registered in javascript at all. They are entirely different programming > domains. > > Actually, no, with respect to Cocoa. If a Cocoa view sends out a message > that the value changed, the controller is not required or even expected to > echo that change back. The message can disappear into the aether and the > state will remain. (Caveat: It's been a while since I've coded against the > Cocoa APIs.) So, it is essentially an identical situation of there being > extra state that is tied to the existence of a Cocoa view object or a DOM > element. This is indeed true that you do not need to handle it, however you still need to `pump` the message loop so, in elm terminology, it gets processed to the right effect manager (in reality when the message loop gets pumped anything listening to the messages can react as you wish, but you yourself still have to pump it, although that code is generally already set up for you via the normal scaffolds, but it is very explicit where elm is more implicit and magical). On Thursday, October 13, 2016 at 2:20:36 PM UTC-6, Rupert Smith wrote: By making it keyed then it is like "oh, these do not match at all, probably > a major structural change, kill the old, create the new". > I have to admit I am not really sure how Html.Keyed works, so this is an illuminating discussion for me. Could you answer some basic questions about it for me? If the 'key' of a keyed node is the same, is it never updated? If 'key' of a keyed node changes, is the whole node built anew? Or something else, please explain it to me, thanks. In Elm if a 'keyed node' is changed then it will diff as normal. If a keyed node has an ID change then it tests the node before and after in the old version and shuffles around as necessary (only 1 at a time, larger jumps cause destroy/recreations), and if none nearby match then it entirely destroys or creates it as necessary. I went a different route with my VDom but I'm still unsure about my style, though it does work well and gets rid of the keyed node and lazy node concepts in a larger singular super-node thing... On Thursday, October 13, 2016 at 2:23:04 PM UTC-6, Rupert Smith wrote: Some other questions relating to this. I have a node that I changed an Html.Attribute.property on. The node had 2 properties, but I only changed one. However, the node as a webcomponent fired triggered an observer on the other property that was not changed. If I change just one property of a node, are all properties updated? What about atttributes, if I change one attribute are all updated? Uh, it should not do that I would think, sounds like a bug as an un-touched attribute should not be touched. Unsure if Elm or the webcomponent-library-that-you-are-using kind of bug, but it sounds like a bug (I'd wager in the webcomponent polyfill you are using most likely, does sound weird...). -- 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.
