-
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
Exclude reusable blocks from the global block count #11787
Exclude reusable blocks from the global block count #11787
Conversation
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.
Hi @noisysocks, this seems an improvement and addresses some problems.
But we need to take into consideration the descendants of the child blocks.
If we convert a columns block with two columns and with one paragraph inside each column to a reusable block, the columns block is not counted but the 2 "column" blocks and 2 paragraph blocks are counted so we have an additional four blocks in the global block count.
We are also taking into account all paragraphs and headings inside reusable blocks in the global headings and paragraphs counts.
I'd consider this a nice to have and not high priority. The most important is to fix the surplus in the counts. |
488bb0d
to
30bcbdb
Compare
Thanks Jorge! Good catch. I've modified the selector to use |
30bcbdb
to
a248a9d
Compare
Modifies getGlobalBlockCount() to exclude reusable blocks from its count. This fixes the block count including reusable blocks that have been fetched and parsed but not inserted into the post or page.
a248a9d
to
7e70858
Compare
}, | ||
( state ) => [ | ||
state.editor.present.blocks.order, | ||
state.editor.present.blocks.byClientId, |
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.
Is it really worth memoizing selectors if they depend on these two elements particularly? I feel state.editor.present.blocks.byClientId
changes so often that it's just a waste of time to memoize these selectors.
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.
Thoughts on this @aduth?
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.
But it seems wasteful to have this selector run when something unrelated e.g. a post attribute is modified, no?
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 know honestly, it feels like typing in blocks is the most impactful thing in terms of performance, changing an attribute only get triggered once and not extensively.
Anyway, just something to keep in mind for now, there's no clear "winner"
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 👍
Fixes #11744.
Modifies
getGlobalBlockCount()
to exclude reusable blocks from its count. This fixes the block count including reusable blocks that have been parsed and stored intoblocks.byClientId
but not inserted into the post or page.How to test