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

Rich Text: Remove restoreContentAndSplit #7618

Merged
merged 2 commits into from
Jul 19, 2018

Conversation

aduth
Copy link
Member

@aduth aduth commented Jun 28, 2018

Related: https://github.com/WordPress/gutenberg/pull/5100/files#r198953121

This pull request seeks to simplify the RichText component, removing its restoreContentAndSplit function which had been used to preserve content through a block split. In my testing, I had found that this was not a behavior caused by TinyMCE, as indicated by the function's comment, but rather in our use of Range#extractContents which moves (i.e. destroys) contents of a range. Updating this code to use Range#cloneContents instead avoids the need to re-set the RichText content which, in turn, should be a boon to performance and avoid the need for this pass-through function.

Testing instructions:

Verify that there are no regressions in block splitting. Particularly, ensure that a paragraphs contents are not destroyed after pressing Enter within.

@aduth aduth added [Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable [Type] Performance Related to performance efforts labels Jun 28, 2018
@aduth aduth requested a review from youknowriad June 28, 2018 19:45
@aduth
Copy link
Member Author

aduth commented Jun 28, 2018

Funny enough, this will incidentally fix the issue described at #5095 (comment), which is still technically an issue for updateContent, but since we don't call it anymore on the split, works for the given steps.

Some related discussion today in Slack with @tofumatt

@aduth
Copy link
Member Author

aduth commented Jun 28, 2018

The end-to-end test failure is a legitimate bug where the caret is in the first paragraph wrongly when splitting in two from the middle: But in fact it's the same bug observed at #5095 (comment) and proposed to be fixed by #7620 . You can observe that it becomes fixed again if you cherry-pick 29bcba5 into your local branch.

Thus, considering #7620 as a blocker for this.

@aduth aduth added the [Status] Blocked Used to indicate that a current effort isn't able to move forward label Jun 28, 2018
const beforeFragment = beforeRange.extractContents();
const afterFragment = afterRange.extractContents();
const beforeFragment = beforeRange.cloneContents();
const afterFragment = afterRange.cloneContents();
Copy link
Member

Choose a reason for hiding this comment

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

Could the afterFragment still be extracted, so we can avoid having to set it afterwards? I think this this happens in the block edit component. Or maybe I'm misunderstanding this.

Copy link
Member Author

Choose a reason for hiding this comment

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

so we can avoid having to set it afterwards?

What do you mean by set?

Copy link
Member

Choose a reason for hiding this comment

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

By means of setAttributes in the block edit function.

Copy link
Member Author

Choose a reason for hiding this comment

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

Still not totally sure I understand, but we should want the explicit setAttributes and avoid leveraging any of these more implicit DOM mutations.

@aduth aduth force-pushed the remove/rich-text-restore-content-split branch from 1085589 to 03edbac Compare July 2, 2018 14:34
@aduth aduth force-pushed the remove/rich-text-restore-content-split branch from 03edbac to f3d3852 Compare July 9, 2018 20:07
@aduth aduth force-pushed the remove/rich-text-restore-content-split branch from f3d3852 to 7a61eb0 Compare July 10, 2018 18:38
@gziolo
Copy link
Member

gziolo commented Jul 17, 2018

Thus, considering #7620 as a blocker for this.

It looks like #7620 was resolved, can we rebase this one and merge?

@aduth aduth added this to the 3.3 milestone Jul 18, 2018
Avoid destroying original content incurred by extractContents
@aduth aduth force-pushed the remove/rich-text-restore-content-split branch from 7a61eb0 to 03ded61 Compare July 19, 2018 12:22
@aduth
Copy link
Member Author

aduth commented Jul 19, 2018

Rebased and force pushed. Running locally, all tests / functionality appears to work as expected now.

@aduth aduth removed the [Status] Blocked Used to indicate that a current effort isn't able to move forward label Jul 19, 2018
@tofumatt tofumatt self-requested a review July 19, 2018 18:36
Copy link
Member

@tofumatt tofumatt left a comment

Choose a reason for hiding this comment

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

I tested this locally, split a bunch of blocks, paragraphs, lists, headings, including paragraphs that had bold characters and such–split them inside and outside the bold characters.

All seemed to work well and I encountered no bugs.

Writing a few e2e tests for block splitting would be good, I dunno if we have any. Either way I suppose that's not just related to this PR 😄

🚢

@tofumatt
Copy link
Member

more-red-than-green

@aduth
Copy link
Member Author

aduth commented Jul 19, 2018

Writing a few e2e tests for block splitting would be good, I dunno if we have any. Either way I suppose that's not just related to this PR 😄

There's quite a few split across splitting-merging.test.js and writing-flow.test.js, though I'm open to adding more if there's a problematic flow not currently covered.

@aduth aduth merged commit b28a678 into master Jul 19, 2018
@aduth aduth deleted the remove/rich-text-restore-content-split branch July 19, 2018 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Rich Text Related to the Rich Text component that allows developers to render a contenteditable [Type] Performance Related to performance efforts
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants