-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DataViews: add primary filter API #58427
Conversation
Size Change: +54 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
@@ -332,6 +332,7 @@ export default function PagePages() { | |||
enableSorting: false, | |||
filterBy: { | |||
operators: [ OPERATOR_IN ], | |||
isPrimary: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be removed before merging the PR. It's set for demo purposes (simulate a situation where there is primary and secondary, so we can holistically review how the API works).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wasn't removed before merging the PR: #58682
31cf33d
to
5dddf2b
Compare
@@ -325,6 +324,7 @@ export default function DataviewsPatterns() { | |||
elements: SYNC_FILTERS, | |||
filterBy: { | |||
operators: [ OPERATOR_IN ], | |||
isPrimary: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be inside filterBy
? I think it's more of top level filters related prop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did consider having it top-level, and it looked like this:
{
header: 'Sync',
id: 'sync',
isPrimaryFilter: true,
}
It's weird that a field says "I'm a primary filter".
Additionally, fields only have filterBy
prop related to filters. It's also the reason filterBy
is an object, so we can add more props as we evolve the filters API. I prefer to group it together, to be honest. If the filterBy
name is confusing, I'd be open to find alternatives such as filters
, etc. in follow-ups.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's probably rename then in a follow up(? 🤔 ).
@@ -325,6 +324,7 @@ export default function DataviewsPatterns() { | |||
elements: SYNC_FILTERS, | |||
filterBy: { | |||
operators: [ OPERATOR_IN ], | |||
isPrimary: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thought.
I don't think there needs to be any visual distinction in the UI element. When the new filter UX design is implemented there will be a subtle difference in the configuration popover;
This seems fine for now. We may want to allow users to re-order filters, but that's probably something to tackle when we add Custom views. |
So, if the state of this PR seems sensible, we could land it in time for 6.5. The only interaction I'd like to clarify is this whether the reset button should be visible when there is only one primary filter: #58427 (comment) |
I don't think the number of primary filters makes any difference to the logic around whether the Reset button is visible. |
Is there anything else to address here, or are we happy to land this for 6.5? ✅ |
That seems good, and is most aligned with where we'll end up when the new filter design is implemented. Two last details I'm not sure of;
reset.mp4 |
10c3b65
to
b389b42
Compare
Updated it to work as you mentioned. I understand "primary filter" as "primary action": it's not part of the filters/actions list but always visible, but I also don't have strong opinions against doing it differently for filters. Patterns Gravacao.do.ecra.2024-01-31.as.09.38.49.movPages Gravacao.do.ecra.2024-01-31.as.09.37.38.mov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose this menu situations resolves itself when the new filter UX is implemented, but for now I think this works well. Thanks for all the hard work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's get this in. Thanks!
Part of #55083
Alternative to #58367
What?
This PR implements the primary filter API. Primary filters are always visible and not listed in the "Add filter" component unless the layout is the list view.
Patterns: a single primary filter.
Gravacao.do.ecra.2024-01-31.as.09.38.49.mov
Pages: primary and secondary filters (to remove before merging: it's only here to see how it works holistically.):
Gravacao.do.ecra.2024-01-31.as.09.37.38.mov
Why?
This would allow us to have filters that are permanently visible.
How?
isPrimary
tofield.filterBy
API that consumers can use.Testing Instructions
Patterns:
Pages:
Questions
See answers.
How users can tell apart primary and secondary filters when they are visible? Do we need to tell them apart?How primary & secondary filters are sorted when they are visible? This PR keeps the order as it was. It's the consumer who controls the order (first declared, first displayed). They are listed in the same order in the AddComponent and in the summaries.