Re: [w3c/webcomponents] CE reaction queue's not-really-sync behavior doesn't provide strong enough guarantees about when reactions occur (#616)

Right, now that I see the proposed solution written out, it does indeed not work great. The push/pop pairs go together; we can't introduce a third pop, as that will make things unbalanced.

I'm not sure what a better solution would be, though :-/. If someone has one, it'd be great to investigate.

The spec notes the constraints here:

> Additionally, the precise ordering of these reactions is managed via a somewhat-complicated stack-of-queues system, described below. The intention behind this system is to guarantee that custom element reactions always are invoked in the same order as their triggering actions, at least within the local context of a single custom element. (Because custom element reaction code can perform its own mutations, it is not possible to give a global ordering guarantee across multiple elements.)

That is, it's specifically not guaranteed that ordering *between* elements is preserved; it's only within a single element. I believe this came from an analysis by @dominiccooney explaining that it was impossible to satisfy both constraints at once. I can't find that document now though.

It does seem like if your goal is to get the current state of the attribute, instead of a log of what happened to it, actually using getAttribute is best. The arguments tell you that at some point in time the attribute changed, but the attribute could have changed multiple times; you don't know if you're in the first attributeChangedCallback or the second. All you know is that ordering will be preserved.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/616#issuecomment-266578782