RichText: remove Editable & allow React to diff editable element #17779

ellatrix · 2019-10-04T20:07:30Z

Description

This PR eliminates our own diffing for attributes on the content editable element.

Benefits:

No more expensive diffing of style and aria- attributes on every render.
We normally have to manually add new attributes, e.g. reversed or start etc..
No more Editable component.
Gets rid of the shouldComponentUpdate hack.

How has this been tested?

Screenshots

Types of changes

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.
I've included developer documentation if appropriate.

aduth · 2019-11-07T14:50:00Z

It seems really promising. What's the status of this? Just needs a review?

ellatrix · 2019-11-07T15:08:43Z

Yeah, this is ready for review :D

aduth

If I understand correctly, the changes here aren't actually leveraging React to do the rendering of the RichText record?

Even still, I think the benefits here are pretty great, and serve as a nice overall simplification.

I would be curious as well what the measurable performance difference is here, if any (seems there ought to be some improvement to key presses?).

Most of my review comments are minor nit-picks. Functionally, it works great. The only thing I'd consider really blocking is the priority with which we're applying ARIA props seems to have changed.

packages/rich-text/src/component/index.js

aduth · 2019-11-11T20:59:57Z

packages/rich-text/src/component/index.js

-				valueToEditableHTML={ this.valueToEditableHTML }
-				aria-label={ placeholder }
-				{ ...pickAriaProps( this.props ) }
+				style={ { ...style, whiteSpace } }


While it existed previously as well, I wonder if we're incurring unnecessary work here in rendering since React will always consider props.style !== nextProps.style on every render. I guess in real-world usage we'd be doing so anyways, since the paragraph block always passes a new object as well (though that's something on its own to consider refactoring), but even then there's the (albeit trivial) work of merging the objects.

Was it ever considered: Can we apply this style via CSS ? It avoids the whole need to merge the objects at all. I'd even be generally okay with the problem was specificity and we found ourselves needing to !important.

Can we apply this style via CSS ? It avoids the whole need to merge the objects at all.

Oh you mean the white space rule? Yes, I considered using a stylesheet, but then this would be the only rule in the stylesheet, so I picked adding it to the style object instead of creating a whole new stylesheet for this package.

I'll adjust to check the style prop.

I wonder if React has some internal optimisations for the style prop on an element. It's a bit strange to expect React users to optimise these style objects that are so commonly used.

I wonder if React has some internal optimisations for the style prop on an element. It's a bit strange to expect React users to optimise these style objects that are so commonly used.

Yeah, I'm not sure if they do, but as a general principle this is also why I tend to avoid objects as props in the first place. ariaProps is another good example of where this becomes needlessly difficult to manage. In retrospect, I'm not sure why we didn't just expect people to pass the specific prop they wanted to apply (aria-foo). I seem to recall some limitation that led us down that path, but certainly made things more difficult.

Right, I try to avoid them as much as possible too. Worth noting that ariaProps is picked from props though, there's no ariaProps prop. The picking seems to be there to avoid passing all RichText props to the element.

Right, I try to avoid them as much as possible too. Worth noting that ariaProps is picked from props though, there's no ariaProps prop. The picking seems to be there to avoid passing all RichText props to the element.

Oh! You're right, I definitely mis-recalled the behavior.

So maybe the opposite is true, that we have headaches because we chose to pick props than to accept an object 😄 Maybe in the future we could just be passing through all the props, so we don't need to be doing the explicit picking?

I think we either need to pick the props we want to pass on, or delete the props we don't want to pass on. Both of these are explicit in a way I guess, but I'm fine with trying to delete the props we don't want to pass on. :) Either way there will be some sort of picking. We can't pass any unknown props to an element.

packages/rich-text/src/component/index.js

ellatrix · 2019-11-11T21:57:23Z

If I understand correctly, the changes here aren't actually leveraging React to do the rendering of the RichText record?

No, it's just letting React manage the editable element, not its contents. I'd like to explore that in the future, but I ran into some problems with it. React can't seem to update a DOM tree if the current tree is not in a shape that it's expecting. Anyway, that's a different problem.

I would be curious as well what the measurable performance difference is here, if any (seems there ought to be some improvement to key presses?).

I think that, while there is a bit less work being done, the difference is negligible, especially compared to all the work that's being done outside of RichText after onChange.

aduth

Nice 👍

aduth · 2019-11-12T15:29:23Z

packages/rich-text/src/component/index.js

 				onKeyUp={ this.onSelectionChange }
 				onMouseUp={ this.onSelectionChange }
 				onTouchEnd={ this.onSelectionChange }
+				contentEditable


Technically we previously applied props such that someone could contentEditable. I don't think that's a use case we want to support though 😄

Right. I don't think we should support that for now. We might in the future, maybe through a disabled or readonly prop. But probably not by directly setting contentEditable.

packages/rich-text/src/component/index.js

Co-Authored-By: Andrew Duthie <[email protected]>

ellatrix · 2019-11-12T16:16:37Z

Thanks a lot for the review @aduth!

ellatrix marked this pull request as ready for review October 4, 2019 23:51

ellatrix requested review from SergioEstevao, daniloercoli, etoledom and jorgefilipecosta as code owners October 4, 2019 23:51

ellatrix force-pushed the try/editable-react-diff branch from c7c4b11 to 931615c Compare October 7, 2019 14:09

ellatrix added [Type] Code Quality Issues or PRs that relate to code quality [Type] Performance Related to performance efforts [Package] Rich text /packages/rich-text labels Oct 7, 2019

ellatrix changed the title ~~RichText: allow React to diff editable element~~ RichText: remove Editable & allow React to diff editable element Oct 28, 2019

aduth requested changes Nov 11, 2019

View reviewed changes

ellatrix and others added 8 commits November 11, 2019 23:05

RichText: allow React to diff editable element

8dcaf58

Fix prop

dc8c9f3

suppressContentEditableWarning

1fd2a7f

fix unit tests, simplify

c16d168

Remove accidentally added file

172568c

Update docs

769e3c1

Revert React tree

cdfb88f

Address feedback

ba7fb6a

ellatrix force-pushed the try/editable-react-diff branch from 567599a to ba7fb6a Compare November 11, 2019 22:18

ellatrix requested a review from aduth November 12, 2019 14:28

aduth approved these changes Nov 12, 2019

View reviewed changes

Update packages/rich-text/src/component/index.js

a066d9f

Co-Authored-By: Andrew Duthie <[email protected]>

ellatrix merged commit d9de027 into master Nov 12, 2019

ellatrix deleted the try/editable-react-diff branch November 12, 2019 16:42

aduth mentioned this pull request Nov 13, 2019

Smooth Native Multi Block Selection #16835

Merged

5 tasks

youknowriad added this to the Gutenberg 7.0 milestone Nov 25, 2019

jasmussen mentioned this pull request Dec 9, 2020

Preformatted block: Add support for font sizes #27584

Merged

6 tasks

RichText: remove Editable & allow React to diff editable element #17779

RichText: remove Editable & allow React to diff editable element #17779

Uh oh!

Conversation

ellatrix commented Oct 4, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

How has this been tested?

Screenshots

Types of changes

Checklist:

Uh oh!

aduth commented Nov 7, 2019

Uh oh!

ellatrix commented Nov 7, 2019

Uh oh!

aduth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ellatrix commented Nov 11, 2019

Uh oh!

aduth left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ellatrix Nov 12, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ellatrix commented Nov 12, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ellatrix commented Oct 4, 2019 •

edited

Loading

ellatrix Nov 12, 2019 •

edited

Loading