Restore DOM selection and suppress events

[sophiebits]

This makes Draft mostly work.

[sebmarkbage]

I think that this just happens because we currently always reset the root. Otherwise it is usually to remove and insert the selected node. We can't keep doing that. We will instead use the append/remove child methods for the root too.

However, even in that case this could be needed when a child that is selected is the one that needs to move. It needs to be fixed somewhere else though.

I suspect we need something in the beginning and end of commitAllWork.

[sebmarkbage]

We should do this in a way that covers all mutations in a commit instead of just the top which happens to work right now but won't soon.

[sophiebits]

How about this? Sucks that I had to change all the other files.

[gaearon]

Can you add a test to ReactIncrementalErrorHandling verifying that environment state gets reset after an uncaught error?

[sebmarkbage]

Any reason we need to allocate instead of just mutating something in the closure here?

[sebmarkbage]

It realized that this is not actually the correct behavior because if a life-cycle focuses a different thing we don't want to restore it back again.

Since these transaction wrappers are before the DOM ready queue and they execute in order it seems to me that the restore should actually happen before the life-cycles get invoked. So this whole block needs to move up to line 214.

[sebmarkbage]

Ideally we'd have a DOM specific test for this that tests the observable intent.

[sebmarkbage]

These should both be imported as constants like these

react/src/renderers/shared/fiber/ReactFiberCommitWork.js

Lines 35 to 41 in e3131c1

	const updateContainer = config.updateContainer;
	const commitUpdate = config.commitUpdate;
	const commitTextUpdate = config.commitTextUpdate;
	const appendChild = config.appendChild;
	const insertBefore = config.insertBefore;
	const removeChild = config.removeChild;

[sophiebits]

Better, maybe. Now that we don't run user code before the restoration it's not totally clear to me that we need the try/catch but I guess it's safer to keep it.

[sophiebits]

I added a test that fails if you restore state after lifecycles.

[sebmarkbage]

It is still possible to fail if a ref callback which receives null is invoked. For example: ref={n => n.nodeName}. Those are invoked in the first phase.

[sebmarkbage]

Interestingly that case doesn't seem covered in the same way tryCallComponentWillUnmount is doing. I think we can just remove the try/finally and treat this as a bug in the ref impl.

[sebmarkbage]

I guess we can remove this now since we're not testing this.

[sebmarkbage]

This caused a lint error.

[sophiebits]

Sorry, I turned off my precommit hook yesterday and forgot to reenable it.

[sophiebits]

#8403