Consolidate Dag list search and filters

[shivaam]

This PR implements Option B — compact search with a filter disclosure and editable active-filter chips for the Dag list.

dag-option-b-reviewer.mp4

The existing search and filter row becomes increasingly crowded as new filters are added. This design keeps the primary Dag search stable while moving secondary criteria into a responsive Filters panel. Applied filters remain visible as chips; selecting a chip reopens and focuses its corresponding control for quick editing.

The implementation also introduces a composable SearchAndFilter shell that owns the shared interaction behavior:

• Search and Filters layout
• Active-filter count and clear affordances
• A compact filter panel on desktop and a full-screen filter panel on mobile.
• Keyboard navigation, focus restoration, and accessible labels

Dag-specific behavior remains outside the shared shell, including filter controls, URL serialization, API queries, permissions, suggestions, and result fetching. This PR applies the shell only to the Dag list; migrating other pages is intentionally out of scope and will follow as separate PRs.

The Dag implementation preserves shareable URL state, browser Back/Forward navigation, pagination reset, existing tag behavior, timetable multi-selection, and loading, error, and empty states.

Owner filters applied from Dag cards are now shown in the filter panel and included in the active-filter count. Because the API does not provide owner suggestions, users can enter owner names directly.

Interaction details

• Opening an active chip scrolls to and focuses its corresponding control.
• Closing the panel restores focus to the originating chip or Filters button.
• Tag and timetable suggestions retain loading, error, pagination, and retry states.
• Unknown URL parameters are preserved while known filters are normalized.
• Changing a filter creates one history entry and resets pagination; Back restores the exact prior URL.

The filter hooks keep the URL, displayed filters, and fetched results synchronized. Invalid or duplicate parameters are cleaned without adding unnecessary browser-history entries, while saved tag preferences are added to the URL on initial load so the filtered view remains shareable.

Validation

• corepack pnpm lint
• corepack pnpm vitest run src/components/SearchAndFilter src/components/SearchBar.test.tsx src/components/ui/ButtonGroupToggle.test.tsx src/pages/DagsList/DagsFilters src/pages/DagsList/useTagFilter.test.tsx src/pages/DagsList/DagsList.test.tsx — 13 files / 70 tests passed
• corepack pnpm build
• Real Breeze UI checks at desktop, 375×720, and 320px widths
• Exercised deep links, multiple filters, clear/remove/edit, keyboard focus, Back/Forward, pagination reset, long chips, and narrow-screen overflow

Design exploration: Options A, B, and C

Three working concepts were tested in the real Airflow UI. Option B was selected because its search field and Filters trigger remain spatially stable as filters are added or removed.

Option A — Query composer

Explored but not included in the production implementation.

variant-a-query-composer-demo.mp4

Option B — Filter disclosure and active chips

Selected and implemented in this PR.

variant-b-filter-hub-demo.mp4

Option C — Inline filter pills

Explored but not included in the production implementation.

variant-c-filter-pills-demo.mp4

This remains a draft while CI and final review are completed.

related: #69728

---

Was generative AI tooling used to co-author this PR?

• Yes — OpenAI Codex

Generated-by: OpenAI Codex following the project guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.

[bbovenzi]

Thanks!

First, I think we can reduce the width of the search bar. It doesn't need to be full screen width

Option A, the dropdown is moving all the content below so I don't see the benefit of integrating the filters into the search bar component. I think the version of Option A that I was thinking wad the github issue search UX. Although its much more "power user" and less accessible.

Option B is very interesting! Could you show a screenshot of the full menu? I am curious how big it is and if it would also become unwieldy.

Option C is most consistent with our other views so it would be easiest to implement. But if we decide on something better then let's apply it across the whole UI.

[shivaam]

Thanks, Brent! Here’s the complete Option B desktop menu at 1440×900. The popover is currently 680px wide and grouped into Run status, Availability and action, Schedule, Ownership, and Personal. This capture uses a name search plus two timetable types, leaving 12 matching Dags.

I agree the search can be narrower on desktop while staying full width on smaller screens. Seeing the full menu, would you lean toward B or C? If B, I’ll treat the responsive hub/chip shell as a reusable list-filter pattern rather than a Dag-only one.

[bbovenzi]

Let's continue with B

[shivaam]

Let's continue with B

Done. I think this is going to make the UI look simpler and easier on eyes. Let me know if you will have any comments. Once this PR is approved/merged I will add this to other pages as well.

[ryanahamilton]

All of the other pages, including the sibling tabs (Dag Run, Task Instances) have a chip filter pattern already implemented. I would suggest that pattern get adopted on the Dags list as well instead of introducing a new/different pattern for this view.

[shivaam]

All of the other pages, including the sibling tabs (Dag Run, Task Instances) have a chip filter pattern already implemented. I would suggest that pattern get adopted on the Dags list as well instead of introducing a new/different pattern for this view.

I agree that consistency across Dags, Dag Runs, and Task Instances is important. However, I think we should first evaluate which interaction works better, and then decide whether the UX improvement justifies changing the shared pattern and also the use experience.
My concern with the current inline pattern is that the filter row can become crowded and reflow as filters are added or edited, causing controls to move. Option B preserves visible, removable, and editable active-filter chips while keeping search and the Filters button in a predictable location. Filter selection is grouped in one panel instead of expanding inline.
The underlying component is reusable, so if we agree this is the better direction, I’m happy to migrate the sibling pages as well. If the preference after comparing them is still to retain the current FilterBar pattern, I’m happy to align with that decision.

[shivaam]

All of the other pages, including the sibling tabs (Dag Run, Task Instances) have a chip filter pattern already implemented. I would suggest that pattern get adopted on the Dags list as well instead of introducing a new/different pattern for this view.

I agree that consistency across Dags, Dag Runs, and Task Instances is important. However, I think we should first evaluate which interaction works better, and then decide whether the UX improvement justifies changing the shared pattern and also the use experience. My concern with the current inline pattern is that the filter row can become crowded and reflow as filters are added or edited, causing controls to move. Option B preserves visible, removable, and editable active-filter chips while keeping search and the Filters button in a predictable location. Filter selection is grouped in one panel instead of expanding inline. The underlying component is reusable, so if we agree this is the better direction, I’m happy to migrate the sibling pages as well. If the preference after comparing them is still to retain the current FilterBar pattern, I’m happy to align with that decision.

here is how it looks like with option c
https://github.com/user-attachments/assets/9d5b4efc-953c-4393-b164-5722e5da2a8a