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
> 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
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
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
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.