DataViews: add primary filter API - #58427
Conversation
|
Size Change: +54 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
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.
This wasn't removed before merging the PR: #58682
31cf33d to
5dddf2b
Compare
| elements: SYNC_FILTERS, | ||
| filterBy: { | ||
| operators: [ OPERATOR_IN ], | ||
| isPrimary: true, |
There was a problem hiding this comment.
Should this be inside filterBy? I think it's more of top level filters related prop.
There was a problem hiding this comment.
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.
Let's probably rename then in a follow up(? 🤔 ).
| elements: SYNC_FILTERS, | ||
| filterBy: { | ||
| operators: [ OPERATOR_IN ], | ||
| isPrimary: true, |
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 |
jameskoster
left a comment
There was a problem hiding this comment.
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!
ntsekouras
left a comment
There was a problem hiding this comment.
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?
isPrimarytofield.filterByAPI 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.