Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore DOM selection and suppress events #8353

Merged
merged 1 commit into from
Nov 23, 2016

Conversation

sophiebits
Copy link
Collaborator

@sophiebits sophiebits commented Nov 18, 2016

This makes Draft mostly work.

@sebmarkbage
Copy link
Collaborator

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.

Copy link
Collaborator

@sebmarkbage sebmarkbage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 sophiebits changed the title Restore DOM selection and suppress events in updateContainer Restore DOM selection and suppress events Nov 23, 2016
@sophiebits
Copy link
Collaborator Author

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

@gaearon
Copy link
Collaborator

gaearon commented Nov 23, 2016

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

return {
eventsEnabled,
selectionInformation: ReactInputSelection.getSelectionInformation(),
};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

if (!isCommitting) {
isCommitting = true;
config.prepareForCommit();
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@@ -275,4 +275,24 @@ describe('ReactIncrementalErrorHandling', () => {
expect(ReactNoop.getChildren('e')).toEqual(null);
expect(ReactNoop.getChildren('f')).toEqual(null);
});

it('restores environment state despite error during commit', () => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

break;
if (!isCommitting) {
isCommitting = true;
config.prepareForCommit();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should both be imported as constants like these

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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

@sebmarkbage
Copy link
Collaborator

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
Copy link
Collaborator

sebmarkbage commented Nov 23, 2016

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.

This makes Draft mostly work.
@@ -255,6 +270,8 @@ var ReactNoop = {

syncUpdates: NoopRenderer.syncUpdates,

isCommitting: () => isCommitting,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

// something that could happen when manipulating DOM nodes (but is hard to
// deterministically force without relying intensely on React DOM
// implementation details)
var div = container.firstChild;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This caused a lint error.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sophiebits added a commit to sophiebits/react that referenced this pull request Nov 23, 2016
sophiebits added a commit to sophiebits/react that referenced this pull request Nov 23, 2016
sophiebits added a commit to sophiebits/react that referenced this pull request Nov 23, 2016
sophiebits added a commit that referenced this pull request Nov 23, 2016
acusti pushed a commit to brandcast/react that referenced this pull request Mar 15, 2017
acusti pushed a commit to brandcast/react that referenced this pull request Mar 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants