Block visibility based on screen size: basic clientside state #74025
Conversation
- Introduce new hooks and utilities for managing block visibility based on viewport types. - Update existing block list component to utilize the new visibility logic. - Add comprehensive unit tests to validate visibility behavior across different scenarios. - Enhance private selectors to support visibility checks for specific devices. - Refactor related components to ensure consistent handling of block visibility attributes.
ramonjd
changed the title
|
Size Change: +300 B (+0.01%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
ramonjd
added
[Type] Enhancement
|
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. |
ramonjd
changed the title
| renderingMode, | ||
| editMediaEntity, | ||
| wrappedOnNavigateToEntityRecord, | ||
| deviceType, |
There was a problem hiding this comment.
I left out responsive Editing mode for now. Thinking that feature could be its own PR.
There was a problem hiding this comment.
Pull request overview
This PR implements client-side state management for block visibility based on device preview mode. Blocks with visibility restrictions are now hidden in the editor when the active device preview matches their visibility settings.
- Added viewport-aware selectors (
isBlockHidden,isHiddenInAnyDevice,getBlockVisibilitySettings) - Created utility functions for checking and toggling block visibility across viewports
- Implemented
useBlockVisibilityhook for managing visibility state and actions - Passed device type from editor settings to block editor for viewport-aware behavior
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
packages/editor/src/components/provider/use-block-editor-settings.js |
Added deviceType from editor store to block editor settings when experiment is enabled |
packages/block-editor/src/store/private-selectors.js |
Updated isBlockHidden to be viewport-aware; added isHiddenInAnyDevice and getBlockVisibilitySettings selectors |
packages/block-editor/src/hooks/use-block-visibility.js |
New hook providing visibility state and update/toggle actions for blocks |
packages/block-editor/src/hooks/block-visibility-utils.js |
New utility functions for viewport visibility checks and toggling logic |
packages/block-editor/src/components/block-list/block.js |
Moved isBlockHidden selector call to make it available in preview mode |
packages/block-editor/src/hooks/index.js |
Exported useBlockVisibility hook |
packages/block-editor/src/store/test/private-selectors.js |
Added comprehensive tests for new selectors |
packages/block-editor/src/hooks/test/use-block-visibility.js |
Added tests for useBlockVisibility hook |
packages/block-editor/src/hooks/test/block-visibility-utils.js |
Added tests for visibility utility functions |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Flaky tests detected in a635b60. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20289541479
|
|
I'm not sure we should be conditionally rendering blocks depending on the current viewport type. The problem is that, if you have built a page that has certain things hidden on mobile and then you try to edit it from an actual mobile device, you won't get the correct view of it: 
It would be simpler if the "hide on..." just added a classname to the block in the editor and we let the media queries do their work. |
Good point. And it matches the existing show/hide method. That's what I was doing over in #73735. I'll look at that, thanks!
Do you mean if we hide/show according to the viewport size? If so, I think this comment is related: #72502 (comment)
And related follow up: #72502 (comment) Where I wanted to take it was hide/show only based on the dropdown preview value, not the window size. The flaw here is "desktop" since that's the default. There's some chatter about how to represent hidden blocks, e.g., dim them. What's your preference, or is there an alternative? |
And if we extend to theme.json later, we can generate these classnames + rules on the backend and add to global styles CSS. 👍🏻 |
ramonjd
changed the title
- Introduce `deviceTypeKey` to manage device-specific visibility settings. - Update private selectors and hooks to utilize the new device type logic. - Remove deprecated visibility utilities and associated tests. - Adjust block editor settings to ensure consistent device type handling. - Enhance styles for block list components to improve visibility behavior.
| border: none !important; | ||
| padding: 0 !important; | ||
| opacity: 0; | ||
| margin: 0 !important; |
There was a problem hiding this comment.
Prevents a "jump" in some blocks when selecting via list view.
- Add comprehensive unit tests for the BlockOutline component to validate rendering behavior based on block selection and category. - Fix attribute binding in BlockListBlockProvider to ensure `bindableAttributes` is correctly passed. - Update comments in private selectors for clarity on block visibility conditions.
Actually, I've left it for now because of the existing block visibility supports, which doesn't render the block. I think that's on purpose. cc @t-hamano for fact check. On the plus side, I've simplified this PR greatly to do only one thing: apply the I deleted things that can be done later, or are redundant. |
The "View" dropdown will never allow us to preview a viewport bigger than that of the device we're on, and it's not even available at less than 782px. So we can't use it at all on mobile, and on tablet it can only give us a preview of what the screen looks like on tablet or mobile. The "Desktop" view on tablet doesn't reproduce the width of an actual desktop view:
When we choose to show/hide content based on breakpoint, we do so because a layout that works on a big screen doesn't necessarily work on a small one. We can't accurately preview a layout optimised for a big screen on a small one (some mobile browsers have the option to show the "desktop version" but the resulting view is rarely accurate) What I'm getting at is we should ignore the settings of the "view" dropdown altogether, because it's not a reliable indicator of the user's actual screen width. If we simply rely on media queries to show/hide blocks, we'll always get an accurate view, whether we're using the view dropdown or an actual mobile device. If we over-optimise for the unlikely event of someone wanting to edit a desktop layout on a phone, we risk creating a bad mobile editing experience for everyone. Not to mention that some of us still prefer to resize their browser window instead of using the "view" dropdown settings 🙀 |
Thanks for going deeper here. I think our instincts are aligned - I started with viewport in the first place on my POC, eventually combining it with the dropdown values. When I was working on that POC, I realized there is, in fact, is almost zero relationship between WP's standard breakpoints and the width values of the device dropdown. 🙃 The catch is, if a user hides a paragraph in mobile viewport while editing, and the switches to the emulated device width and it doesn't hide (which is exactly what will happen if we just use viewport widths), then that's inconsistent. For that reason, I'm not convinced we should ignore the device dropdown altogether, but you're right that it's not a reliable indicator. You mentioned "editing experience" - it's so true, and I couldn't agree more. I worry that we try to be too clever sometimes or mash new features into existing UI patterns. Thinking about this iteratively though, and guided by the notion that our device previews should accurately reflect their respective breakpoints, then I think @mtias's comment here indicates that, yeah, the viewport should trigger breakpoints, but let's start with device previews and iterate. It's behind an experiment and the viewport connection I've already half-done. Long term, I'm leaning towards better discoverability in relation to which blocks are hidden and which are not. If the sidebars are closed there is simply no way to know where hidden blocks are on the canvas, especially for those hidden in "Desktop" since "Desktop" device is the default setting. Might be just me, but I find that to be an undesirable experience. I don't want to have to look around for or guess where all the hidden blocks are! 😆 Wondering if there other ways to balance this? The most promising ideas so far in my opinion are:
Discussions on this feature are getting pretty fragmented over a few open PRs and issues, sorry for banging on. @jasmussen also has done a bunch of cogitating on this topic too. |
This is a bug! They should be the same. |
My kingdom for a single viewport constant! They're also in My guess is that they're different to accommodate sidebars etc? I suppose there's no harm in making them the same and seeing what explode 😄 |
Also related: |
|
Complex conversation, but thanks for keeping at this, responsive is one of the top items.
It would be grand to improve this space, however we can. Coming to mind, allowing customization of those default breakpoint values, AND tying the view dropdown sizes to those same values. I know that isn't the popular option here, but it still seems the simplest as far as user expectations, and the present direction #73888 goes. I will add, there's some additional ideas in #71210, around letting you resize and perhaps see those breakpoints as they happen. In that vein, it seems useful to catalogue a list of all the shortcomings of this view dropdown, and slowly pick at them to eliminate these inconsistencies and problems. It seems possible, but perhaps I'm naïve? |
ramonjd
requested review from
aaronrobertshaw,
andrewserong,
jasmussen and
talldan
💯 I'm only guessing that the device values are different to make the canvas preview behave in unknown editor environments (1 sidebar, 2 sidebars, distraction-free). I couldn't find much context on the original PR, it was a while back, but maybe @tellthemachines remembers No harm in trying.
Agree, let's start there, even if only to keep the scope manageable. |
|
Just dumping this here for now, will come back to it. Breakpoint comparison
To centralize, at least for common values that relate to devices/viewports, the first thing that comes to mind is a JSON source with a build step to generate a const/scss import. Maybe. |
What?
Related to:
This PR implements simple client-side state management for block visibility that respects the currently selected device preview mode. Blocks are hidden in the editor when they have visibility restrictions for the active device preview via the existing
is-block-hiddenclassname.The base of this branch is currently:
That is optional and only a convenience for testing. Neither PR is dependent on the other for the purposes of merging.
No UI changes yet.
How?
isBlockHiddento be viewport-awaredeviceTypefrom editor store to block editor settings using private keyTesting Instructions
For starters, the JS unit tests should pass 🍏
To test manually, enable the experiment:
Then copy and paste this into your post editor, then toggle the device menu.
Kapture.2025-12-16.at.17.10.57.mp4
Make sure to test with the experiment off as well. The last item should never show with the experiment on and off.