Block visibility based on screen size: add rules to hide on viewport size #74379
Conversation
This file contains hidden or 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
…if a block is hidden.
ramonjd
commented
Jan 6, 2026
ramonjd
requested review from
aaronrobertshaw,
andrewserong,
talldan and
tellthemachines
|
Size Change: +499 B (+0.02%) Total Size: 3.08 MB
ℹ️ View Unchanged
|
ramonjd
added
[Type] Enhancement
This was referenced Jan 6, 2026
ramonjd
commented
Jan 6, 2026
packages/block-editor/src/components/block-visibility/use-block-visibility.js
Show resolved
Hide resolved
ramonjd
commented
Jan 6, 2026
| }, [ deviceType, isLargerThanMobile, isLargerThanTablet ] ); | ||
|
|
||
| // Determine if block is currently hidden | ||
| const isBlockCurrentlyHidden = useMemo( () => { |
Member
Author
There was a problem hiding this comment.
I did consider adding classnames, but the effect would be the same.
The current method, also in trunk, is that the block isn't rendered to the block tree at all, so I was thinking we just need a flag for now.
There's another conversation on whether we should be rendering/hiding via CSS, and exactly how. It was the motivation behind this experiment:
ramonjd
changed the title
Contributor
|
I just did a quick test on playground and this is working well except that, on resizing the window, the blocks flagged as hidden in the list view don't change: list-view-resize.mp4They only change when using the preview device sizes. |
…n size detection and update changelog with additional Gutenberg PR link.
Member
Author
Thanks for testing!!! Yes, that's expected. This PR is to create the underlying state that will inform the UI. The UI I've separated into another PR That one is getting big too, so there might be several "UI" PRs. Anyway, if this PR gets in, I'll update over there. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
andrewserong
reviewed
Jan 7, 2026
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
This is generally testing well for me, too. The main thing I noticed is that the tablet breakpoint is different in the editor vs on the site frontend. This very well is likely true in trunk, too, as that's what the Tablet dropdown maps to.
For this PR, I reckon we should pick one and make sure the front and backends match.
Other than that, I noticed the test file seems a bit verbose with lots of mocks which made them a little hard to read for me. Not a blocker, but is it worth simplifying / consolidating the tests? The file they're testing is quite small, which is the main reason I mention it, but this is a bit nitpicky. Overall, glad to see good test coverage for these things 👍
Besides the tablet breakpoint mismatch, this looks like a good iterative step to me!
| // When Mobile/Tablet is selected, override with device type | ||
| // All hooks must be called unconditionally | ||
| const isLargerThanMobile = useViewportMatch( 'mobile', '>=' ); // >= 480px | ||
| const isLargerThanTablet = useViewportMatch( 'medium', '>=' ); // >= 782px |
Contributor
There was a problem hiding this comment.
This uses 782px in the editor vs the site frontend which uses 960px. Should this use large instead, or is it intended that we'll move to a narrower tablet breakpoint?
Member
Author
There was a problem hiding this comment.
Oh wow, good spotting. Another boo boo.
The frontend is wrong there. It should follow the medium size for tablet
Member
Author
There was a problem hiding this comment.
I've updated here and on the backport.
I expect we might be revisiting the frontend anyway.
Thanks!
Contributor
There was a problem hiding this comment.
Cheers, I'll take this for another spin this morning 👍
…S and corresponding unit tests.
Member
Author
Thanks for testing @andrewserong! What did you have in mind? The mocking is for the useViewportMatch/useSelect. I think, to make it easier to test we could isolate the logic into utils outside the hook? |
Contributor
Thanks, I was going to propose something but I ran out of time yesterday when Claude got stuck refactoring them 😆 I think isolating the logic into utils outside the hook might be the neatest approach since that's the bit we want to test anyway. I don't really mind verbose tests, the main challenge I have is that when test files are really long I'm prone to not reading them properly when reviewing and just trusting that if they pass they're good. I'm sure this is fine most of the time, but there's a slim chance we might have passing tests that aren't really covering things properly. Again, I'm probably being a bit nitpicky here! 😄 |
Member
Author
Not at all. If the tests are hard to read, in my opinion, that does hide code smell. Personally, I rely on the tests to understand what the code is doing more often than looking at the code itself. I'll try to split out the logic. Thanks! |
Contributor
|
I replied to your comment before I looked at your code change! I reckon e1b23c6 already tidies things up nicely, no need to split things out further if you haven't started on it yet 👍 |
Member
Author
Cheers! I started looking and ended up abstracting things too far and returning to where I started 😄 I'll leave it then for now. |
andrewserong
approved these changes
Jan 8, 2026
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
LGTM! We'll of course continue tweaking all this stuff in follow-ups, but this is looking good to me 👍
ramonjd
added a commit
that referenced
this pull request
Jan 8, 2026
…related components after rebase on #74379
talldan
reviewed
Jan 9, 2026
| // component, and useBlockProps. | ||
| function BlockListBlockProvider( props ) { | ||
| const { clientId, rootClientId } = props; | ||
| const { isBlockCurrentlyHidden } = useBlockVisibility( clientId ); |
Contributor
There was a problem hiding this comment.
I think this line may have caused a performance regression - https://www.codevitals.run/project/gutenberg/inserterHover
Probably because of the extra store subscription that the hook adds. It might be possibly to resolve it by using the existing useSelect.
Member
Author
There was a problem hiding this comment.
Oof! Thanks for catching that. I'll get a PR up. If it doesn't resolve, I'll revert and find another way
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.
Part of:
What?
Adds
useBlockVisibilityhook to determine if blocks should be hidden based on viewport/device settings.Follow up to
Note
This PR just provides the "state" flag of whether a block is hidden or note. The UI based on that will be in #74249
Why?
This harmonizes the editor with the frontend experience.
How?
metadata.blockVisibilityobject wherefalse= hidden{ isBlockCurrentlyHidden, currentViewport }Testing Instructions
Some test HTML
Screenshots or screencast
Kapture.2026-01-06.at.17.20.24.mp4