-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Support Prepare RichText tree #11595
Conversation
packages/rich-text/src/to-dom.js
Outdated
function prepareFormats( value ) { | ||
return getFormatTypes().reduce( ( accumlator, { prepareEditableTree } ) => { | ||
if ( prepareEditableTree ) { | ||
return prepareEditableTree( accumlator, value.text ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason not to pass the entire value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. We don't want to alter the text at this stage. Otherwise the internal value is wrong. This should be purely for applying formatting on top of text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also pass the entire value and only use the formats from what is returned. Also maybe warn if the length is different.
This feels like a great start, can we try to polish the PR for merge. Also, I'm wondering if we should keep |
98bb0f7
to
88740cd
Compare
<br | ||
data-mce-bogus="1" | ||
/> | ||
<li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these changes here normal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it was actually wrong before. We're expecting a padded multiline element.
} ) )( ( props ) => ( | ||
<OriginalComponent | ||
{ ...props } | ||
prepareEditableTree={ [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are generating a new array here on each render, I wonder if this is the source of the rerendering happening in all RichText. I wonder if we could memoize it somehow in withSelect
by using settings.__experimentalGetPropsForEditableTreePreparation( sel )
as the memoization key, as we don't want to generate a new array if the the returned value didn't change.
Anyway, it doesn't feel unsolvable, so for the sake of iterations, I'm fine leaving this optimisation for a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could it also be creating a new object in withSelect
every time? But sure, sounds resolvable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we create an issue for this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Do you want to give it another look @aduth?
Ideally this is followed up with some tests and a Christmas light investigation. |
) { | ||
addFilter( 'experimentalRichText', name, ( OriginalComponent ) => { | ||
return withSelect( ( sel ) => ( { | ||
[ `format_${ name }` ]: settings.__experimentalGetPropsForEditableTreePreparation( sel ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can simplify it to:
return withSelect( ( select, ownProps ) => ( {
prepareEditableTree: [
...ownProps.prepareEditableTree,
settings.__experimentalCreatePrepareEditableTree( settings.__experimentalGetPropsForEditableTreePreparation( select ) ),
],
} ) )( OriginalComponent );
Updated: I thought settings.__experimentalGetPropsForEditableTreePreparation returns a boolean value.
It still has this issue that it will create a new reference each time props change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
☝️ this way you will have only one wrapping HOC instead of two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried this, it doesn't behave exactly the same.
<p></p> | ||
<!-- /wp:paragraph -->" | ||
`; | ||
exports[`Quote can be converted to paragraphs and renders a void paragraph if both the cite and quote are void 1`] = `""`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did this change?
Why did this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no idea tbh. But now this is true, where it wasn't before: "Quote can be converted to paragraphs and renders a void paragraph if both the cite and quote are void".
// date. In the future we could always let it flow back in the live DOM | ||
// if there are no performance issues. | ||
this.onChange( transformed, record === transformed ); | ||
this.onChange( transformed ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This worries me that our standard set of operations for a single input have suddenly become more non-performant. Am I wrong to be worried?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing that changes the difference between the created DOM tree by us will be applied to the live DOM. With most input, there will be no changes.
Before 4.3 I'd hope. |
Description
To test: type "Gutenberg" in a RichText field. The word will be highlighted if it's the first occurrence, and if the "Block" sidebar is open. Now remove a letter, and highlighting will be gone. Add it back to add highlighting and go to the "Document" sidebar. Highlighting will be gone. It depends on the sidebar state.
Example plugin code:
How has this been tested?
Screenshots
Types of changes
Checklist: