Refactor the BlockToolbar compoonent to avoid getSelectedBlock #11843
Conversation
| */ | ||
| export function isBlockValid( state, clientId ) { | ||
| const block = state.editor.present.blocks.byClientId[ clientId ]; | ||
| return block && block.isValid; |
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
| @@ -398,6 +398,19 @@ the client ID. | |||
|
|
|||
| 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.