Fix reusable block inserter popup performance issue - Fixes - #35719

[sathyapulse]

Description

The PR addresses the performance issue with the Inserter popup(delayed rendering) when the block editor is used with thousands of reusable blocks. Block editor parses the reusable blocks to identify the icon to be displayed in the block library, and it delays the Inserter popup to appear. The PR replaces the parsing with the string operation to identify the icon.

The detailed information is added in Github issue #35719

How has this been tested?

I've added the fixes and verified the same in the local environment with 2500+ reusable blocks. The inserter menu opens immediately without any delay after the fix. I've used VVV to verify the changes. The function is not used in other places, so I expect it wouldn't introduce any other issues.

Screenshots

Not applicable

Types of changes

Bug fix (non-breaking change which fixes an issue).

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @sathyapulse! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[mcsf]

Thanks for identifying the performance issue and for proposing a fix.

The fix, however, is fragile and has some inefficiencies:

• It constructs a collection of matchable blocks based on the currently registered block types. Any block type currently not registered would not be recognised.
• It exhaustively parses the string in search for a registered block type, instead of targeting the outermost / first block.
• It loops over the string up to n times, where n is the number of registered block types.
• It only works with core blocks, since it explicitly replaces 'core/' with 'wp:' and vice-versa.
• Finally, it is prone to mismatches, as I'll show below.

Consider a reusable block with the following markup:

<!-- wp:paragraph -->
  <p>The correct format is <code>&lt;!-- wp:quote --&gt;</code>.</p>
<!-- /wp:paragraph -->

If 'wp:quote' is listed before 'wp:paragraph' in blockTypeNames, then the function will incorrectly detect the type as Quote.

---

I think I have an easy fix for this. I'll work on this now and share it ASAP.

[mcsf]

@sathyapulse: I'm pausing for lunch now, but I just pushed commit cddd173. I can't directly push onto your development branch, but do you mind testing this for correctness and performance? Thanks!

[sathyapulse]

@mcsf Thank you for working on the alternative approach. I agree with your feedback on the looping, and I wasn't aware of the existing tokenizer to catch this serialized data. I've applied the patch from #35763, verified it with ~2500 reusable blocks, and it works as expected. Thank you again for the brilliant work. I'm happy to close this PR and proceed with the discussion on your PR.

[mcsf]

@sathyapulse: thanks for the testing and feedback! Since #35763 is all set up and passes all CI tests (edit: there's an intermittently failing job for the native apps, let's see if it passes now), I think that's what we should approve and merge. I've edited the PR description to reflect your contribution. :)

[mcsf]

Closing in favour of #35763. Thanks again!