DataViews: always include filter container styles with free composition#75021
Open
DataViews: always include filter container styles with free composition#75021
Conversation
Always include filter container styles via `dataviews-filters__container` selector when using free composition with `DataViews.Filters` and `DataViews.FiltersToggled` components.
|
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. |
3 tasks
|
Size Change: -12 B (0%) Total Size: 2.98 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 8047d39. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21441286029
|
ntsekouras
reviewed
Jan 28, 2026
Contributor
ntsekouras
left a comment
There was a problem hiding this comment.
Thanks for the PR! I get the point for wanting a way to apply the default filter styles easily, but I'm not sure about this specific change.
It feels like that for free composition we should have the least opinionated styles possible and the dataviews-filters__container has a few, like the padding prop.
You can already see the visual difference in storybook here and by checking the same story locally with your PR.
Are there other similar cases for the other components like DataViews.Pagination etc? If there are, should we consider a different approach with a flag to some components or the main one (DataViews)?
I'd lean on leaving things as are for free composition and let consumers just copy some styles (not actually copy the dataviews-filters__container classname). --cc @oandregal @jameskoster
Member
|
Just by reading the OP I was about to ask for some testing instructions (ideally always add some clear testing instructions on how you tested, so we can see what you were having in your mind; leaving that simplistic testing instructions leaves too much space for imagination), but then I read the @ntsekouras comment, and I got it clearer, so I went through to see: Before 
After 
As @ntsekouras suggests this is affecting So raising the props won't leave things the same. You get that extra unnecessary space when |
Member
Author
|
Good points! I agree that semantically a component shouldn't add empty space around it (especially asymmetrically), as it makes flexible reuse harder. On the flip side, the free composition example in Storybook could also use override styles for its custom spacing. The gist is that the styles provided by the selector include much more than just spacing: gutenberg/packages/dataviews/src/dataviews/style.scss Lines 20 to 32 in 694d039 gutenberg/packages/dataviews/src/dataviews/style.scss Lines 51 to 56 in 694d039 At least Overall, I would expect that one can easily replicate a regular DataViews looking view with sub-components without maintaining their own styles, and then, for example, implement a totally custom footer section. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Always include filter container styles via
dataviews-filters__containerselector when using free composition withDataViews.FiltersandDataViews.FiltersToggledcomponents.FYI, FiltersToggled was added in #71907
Currently, to get these styles applied to the filter row, the consumer has to apply the class manually (syntax simplified):
This is fragile since CSS selectors like these shouldn't be considered as a stable API.
I'd expect simply this being enough to have a full set of DataViews styles applying to all components, which I can then override if needed:
This came up when using DataViews in a plugin and was likely picked from Gutenberg codebase examples by an AI.
Since there were only two usages of
<DataViews.FiltersToggled />in the package, and both were already includingdataviews-filters__container, it seemed fairly safe to simply move the selector to the component itself. DataViews also aren't externalised, so consumers fully control updating the package.That said, consumers might already be using the FiltersToggled with their own styles, so this is a breaking change.
Note also how FiltersToggle comes up with its container CSS selector:
gutenberg/packages/dataviews/src/components/dataviews-filters/toggle.tsx
Line 69 in fe47a06
What?
Closes
Adds
dataviews-filters__containalways come with<DataViews.FiltersToggled />and<DataViews.Filters />components.Why?
For easier consumption of free composition components in DataViews.
How?
Testing Instructions
Test different usages of DataViews around Gutenberg and in the storybook.
Testing Instructions for Keyboard
Screenshots or screencast