may need to let some mutation happen during render about mercury HOT 12 CLOSED

I need to somehow add an escape clause in main-loop then update mercury to wire in the correct escape clause, i.e. mutation is allowed in synchronous DOM events from dom-delegator.

from mercury.

wow thats an interesting edge-case!

from mercury.

@neonstalwart so the problem is that it is firing an event registered for an element that no longer in the dom? If so, perhaps we could just do a check for the element being in the DOM before calling the handler
Is there a case where we'd want it to fire even though the element has been removed?

from mercury.

@kumavis the problem removing nodes is not the main point - that is something I've been able to mostly address in virtual-dom. the real problem you should give your attention to is that blur events fire synchronously and if you do something to shift focus during a render then your blur handler will be fired in the middle of a render. if your blur handler mutates state then an error will be thrown because you are not allowed to mutate state during a render. this is something which is actually quite common once you do anything that uses a blur handler.

from mercury.

gotcha!
i remember the ember core folks talking about having to invalidate renders.
i wonder if we could somehow fire blur handlers for to-be-removed elements after virtual render but before dom render...

so we would virtual render twice (or more) and dom render once

from mercury.

after talking more with @kumavis in irc, we came to realize that maybe we could ignore state mutations during the patch phase. the error is really for the purpose of stopping people mutating state during render but this mutation is happening during patch. @Raynos what do you think about changing main-loop so that InvalidUpdateInRender does not throw during the patch phase?

from mercury.

@neonstalwart

We want to gaurd the patch phase to stop people doing naughty things in hooks and widgets.

Can we update dom-delegator to force blur into a next-tick ? Would that fix the problem ?

from mercury.

i don't think we can delay the event - then you can't prevent a blur. also, it's not uncommon for blur and focus logic to work together. if you try to delay the events you'll probably introduce a whole slew of new problems worse than this one.

from mercury.

I would accept allowing state change during a patch as the lesser of evils

from mercury.

@kumavis @neonstalwart seems reasonable. However let's gaurd both tree creation & diff because of how thunks do lazy tree creation.

from mercury.

pending Raynos/main-loop#15
and updating main-loop dep here

from mercury.

Fixed in latest mercury.

from mercury.