-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Annotations: Add end-to-end tests for annotations API #12186
Conversation
I just tested this with the Yoast annotations, and it works like a charm 😄 |
* | ||
* @return {Function} The onChangeEditableValue function. | ||
*/ | ||
const createOnChangeEditableValue = memize( ( removeAnnotation, updateAnnotationRange, annotations ) => { |
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 feel the memoization is not necessary as it's an onChange handler? And withDispatch
in general don't need memoization?
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 does not go to withDispatch
, but it goes to the onChangeEditableValue
prop in the HOC for RichText
. I don't think we can 'route' this through withDispatch
because withDispatch
only accepts functions in the returned object.
It could be that this is not necessary to prevent re-renders to TinyMCE, but I do think it's necessary to prevent re-renders to RichText
.
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 don't have a strong opinion against this change. I'd like us to move away from systemic memoization for performance optimization in the formats but handle these in the framework instead but I don't see this as a blocker for this PR.
// If we always specify this the selection will go to this RichText | ||
// regardless whether is is actually the currently selected one. | ||
// So check if this RichText is the selected one. | ||
if ( this.props.isSelected ) { |
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.
@iseulde Any thoughts about this particular 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've put some extra context about this change in the commit: 50057fc.
I'll try to look at this today or tomorrow. |
I'm fine with this as a temporary solution since it won't impact the default experience, but we really need to look at moving memoization into the API and making sure it gets invalidated when needed. See #12161 (comment). |
3b2aacb
to
cd76538
Compare
const rerendersAfterAnnotating = await getRerenderCount(); | ||
|
||
// Typing in the second block should not trigger a re-render in the first block. | ||
expect( rerendersAfterAnnotating ).toEqual( rerendersBeforeAnnotating + ANNOTATION_RERENDERS ); |
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 can be written as toBe
.
const FORMAT_NAME = 'rerender/counter'; | ||
|
||
function countRerender( formats, text ) { | ||
if ( text.startsWith( 'RerenderCounter' ) ) { |
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.
Can't we create a separate format type for these tests?
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.
Assuming it is already separate because it's called rerender/counter
. So why do we have this check?
return formats; | ||
} | ||
|
||
domReady( () => { |
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 is a format being registered when the DOM is ready? What does the DOM have to do with this?
|
||
domReady( () => { | ||
registerFormatType( FORMAT_NAME, { | ||
name: FORMAT_NAME, |
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 this attribute is not needed?
|
||
function countRerender( formats, text ) { | ||
if ( text.startsWith( 'RerenderCounter' ) ) { | ||
window.annotationsCountingRerenders++; |
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.
It's strange to me that this is being set in a separate file. I have no idea from looking at the other file where it's coming from. Maybe better to more this registration to the test cases?
@@ -15,9 +20,9 @@ const addAnnotationClassName = ( OriginalComponent ) => { | |||
const annotations = select( 'core/annotations' ).__experimentalGetAnnotationsForBlock( clientId ); | |||
|
|||
return { | |||
className: annotations.map( ( annotation ) => { | |||
className: uniq( annotations.map( ( annotation ) => { |
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.
For what reason do we suddenly need to consider uniqueness of annotations classnames?
I'd not consider this a blocker, in that there ought not be any harm in deduplicating classes, but it'd be better if we could not apply the logic if we're not expecting it to be necessary (or at least have some confidence in whether it is or is not necessary).
@@ -15,6 +15,9 @@ | |||
var registerPlugin = wp.plugins.registerPlugin; | |||
var PluginSidebar = wp.editPost.PluginSidebar; | |||
var PluginSidebarMoreMenuItem = wp.editPost.PluginSidebarMoreMenuItem; | |||
var applyFormat = wp.richText.applyFormat; |
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.
wp-rich-text
must be defined as a dependency of this script.
@@ -15,6 +15,9 @@ | |||
var registerPlugin = wp.plugins.registerPlugin; | |||
var PluginSidebar = wp.editPost.PluginSidebar; | |||
var PluginSidebarMoreMenuItem = wp.editPost.PluginSidebarMoreMenuItem; | |||
var applyFormat = wp.richText.applyFormat; | |||
var registerFormatType = wp.richText.registerFormatType; | |||
var domReady = wp.domReady; |
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.
wp-dom-ready
must be defined as a dependency of this script.
Separate targeted pull requests were made to extract changes into #12737 and #12741 . This branch can be rebased to address the remaining item concerning end-to-end test changes. We should also consider (separately):
|
The test will check that one `RichText` doesn't rerender when typing in a different `RichText`.
cd76538
to
222f942
Compare
@atimmer it looks like there are still some comments that need to be addressed. This branch also got stale because of other changes applied in master. Do you plan to continue working on it? It would be great to have better test coverage for annotations as it isn't used by Gutenberg itself. |
@gziolo This is currently not a focus. The work is still valuable, but I have no short-term plans to actively pursue this to completion. |
Yes, it seems like a good addition, so if someone wants to move it forward, I assume it would be nice to help land this PR :) |
It doesn't look like it is going to be worked on in the upcoming weeks. Let's close it for now. We can always reopen, refresh and land when it's more pressing. Thanks for your initial work on this PR. |
Description
After introducing
prepareEditableTree
we would rerender allRichText
instances when typing in oneRichText
instance. Noted here: #11595 (comment). This was partly fixed in #12161. This PR fixes it completely and adds e2e tests to ensure that this won't happen again in the future.How has this been tested?
Using the e2e tests and applying annotations using Yoast SEO.
Screenshots
Types of changes
Checklist: