Size Change: +2 B (0%)

Total Size: 819 kB

_{compressed-size-action}

@youknowriad This PR combined with #21973 fixes the performance issue even without the memo() call. I trust your judgement here and I will remove the memo if you think it's worth it. Just to reiterate my personal opinion: I think memo() is worth having in this specific case. I see it as buying an insurance against accidentally updating <BlockInspector /> in a way that would restore re-renders - our premium is wrapping <BlockStyles /> in memo() . Personally I think it's quite easy to add another hook to BlockInspector without considering the impact on <BlockStyles /> - and this have real UX consequences for one of the core blocks as seen in #21973. At the same time, <BlockStyles/> seems unlikely to become something that's rendered dozens/hundred of times in a single tree so the performance impact of memo() should be marginal, even if it ends up being redundant. Also, before refactoring <BlockStyles /> to use hooks, one of the HOCs still added pure() to the tree - which means even with memo() we're still net neutral with regard to the amount of pure components.

@adamziel Thanks for your work, these improvements are great. I'll take a look at this PR a bit later but keeping "memo" is totally fine.

Good point about BlockStyles being expensive, that said, I wonder if the expensive component is actually BlockPreview used by BlockStyles and not BlockStyles itself so I wonder whether we should move the "memo" there.

Thank you!

I wonder if the expensive component is actually BlockPreview used by BlockStyles and not BlockStyles itself so I wonder whether we should move the "memo" there.

@youknowriad Good point! I'll merge #21973 and spin a new PR for that.

Awesome, thank you so much! Also, that new PR to memo() the BlockPreview is available here: #21993