Refactor the BlockToolbar compoonent to avoid getSelectedBlock #11843
Conversation
jorgefilipecosta
left a comment
jorgefilipecosta
left a comment
There was a problem hiding this comment.
I did a set of smoke tests and things looked good. The changes also seem logical 👍
There is only one small change that I think we should do before the merge.
There was a problem hiding this comment.
If the block is undefined we will return undefined instead of a boolean. I think we should do !! ( block && block.isValid ) or !! block && block.isValid if we are totally sure isValid is always defined to a boolean.
youknowriad
force-pushed
the
refactor/block-toolbar-perf
branch
from
d264c4e to
aa48d43
Compare
|
|
||
| Block name. | ||
|
|
||
| ### isBlockValid |
There was a problem hiding this comment.
There was some discussion at #10891 (comment) concerning the naming with regards to placement of adjectives. I think it's particularly relevant here only because we already have precedent with blocks, and with block validation specification, i.e. wp.blocks.isValidBlockContent.
There was a problem hiding this comment.
On second thought, there seems to be subtle distinction between what's being validated, where the language here might be more appropriate for a known identity, vs. in the block API case of considering some transient inputs.
¯\_(ツ)_/¯
Extracted from #11811
I'm using
getSelectedBlockClientIdand a newisBlockValidselector to avoid the less performantgetSelectedBlockselector in the BlockToolbar.