Try: hide search block label when contained #35688
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vcanales
added
[Block] Search
|
Size Change: +91 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
vcanales
force-pushed
the
try/hide-search-block-label-when-contained
branch
from
1d5aae4
to
7d26884
Compare
vcanales
force-pushed
the
try/hide-search-block-label-when-contained
branch
from
7d26884
to
707a2bb
Compare
vcanales
force-pushed
the
try/hide-search-block-label-when-contained
branch
from
3baea3a
to
8ee78b6
Compare
16 tasks
|
This is really nice: It also seems like block context is the right way to do it. I'd love to also default the search button to be inside, and icon-only, i.e. like this:
If we can get to this point, we'll be in a pretty decent place, actually. One gotcha, though: as of the changes made in #34041, you'll likely be building your menu by first adding a few menu items, then adding a menu item and transforming it to a search block. When transforming, it appears that the block context is not leveraged to set these defaults: Is that something we can tweak, so the transform action also sets these defaults? Note, it's possible we need to fix that separately as part of #34041 and improvements to this transform behavior in general. |
7 tasks
| @@ -62,6 +62,10 @@ | |||
| }, | |||
| "customOverlayTextColor": { | |||
| "type": "string" | |||
| }, | |||
| "searchBlockLabel": { | |||
There was a problem hiding this comment.
It doesn't feel right to have this as an attribute of the Navigation block, because it's not configurable within Navigation. Block attributes should be related to the block itself, usually as settings that affect the block or its children, but in this case we're trying to configure an attribute that only exists in the child block. The parent block shouldn't really need to know about it.
There's a precedent for this type of situation in Page List, where we check for a block parent directly from its edit function. This seems a more appropriate approach for the search label, and has the advantage that we can make it apply to other parent blocks without having to add attributes and context to each individual block (though I'm not sure if in this case we'd want this behaviour when Search is nested in any other block apart from Navigation)
There was a problem hiding this comment.
Update: #31670 changed Page List to extrapolate its parent from context, but that works because Page List already uses context from Navigation, which Search doesn't.
|
|
||
| // Save a ref to this value, as it would become outdated | ||
| // if any other blocks are added. | ||
| const isNewBlockRef = useRef( isNewBlock ); |
There was a problem hiding this comment.
Not sure I understand why we need to use a ref here. Could you elaborate a bit on the problem?
|
Can we limit this to only the navigation block? Group was mentioned, but a visible label should be the first choice, hiding the label when inside one of the most used containers, the group, is negative for accessibility. |
Yes, the search block has good defaults and the change here should only be for when it's inserted in the navigation block. I can't think of a good example off the top of my head, but I do imagine that the mechanism could be useful for inserting other blocks in containers. |
7 tasks
7 tasks
|
Hi, everyone I've created PR with an alternative approach to this enhancement - #36026. |
|
Closed in favor of #36125 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Addressing #31127
Labels are shown by default, as established in block.json. This PR adds the possibility for parent blocks to define if they want a search bar label or not, by adding a
searchBarLabelattribute, and passing it down through using Block Context.The flip is made:
showLabelattribute istrue(current default in block.json).How has this been tested?
Screenshots