UX improvements of DAG tag filtering

[ryanahamilton]

• Instead of requiring the user to select/deselect tags and then submit the form with the "Filter tags" button, the page now updates as the tag is selected/deselected.
• Removes the storage of the tags in the tags_filter cookie. For a filtering pattern such as this, the URL params should always reflect the current result set. Currently, you can have your result set filtered by tags and have no tags= params in your URL. This also required using a &reset_tags=Reset param to clear the values—this will no longer be needed with the URL explicitly reflecting the values. Updated the server-side logic, so that if cookie values exist, the tags= param is added to the URL so it matches the filtered result set. I also made an update to strip the reset_tags=reset from the URL after the cookie value has been cleared.
• Replaces the "Reset" button with an "X" icon button (same pattern used for search filter, added in UX Enhancement: Add button to clear search query from DAG search #11583). This button only appears when tag filters are applied.
• The sum of these updates yields a much simpler UI where we don't need persistent buttons taking up space.
• Updates Docs screenshot

Before	After

CC: @zacharya19 thought you might be interested in these modifications to your feature originally added in #6489.

[ashb]

I think the reason for the tags_filter cookie is so that if you navigate away (say go and view a DAG) and then come back to the home page we want the same filters to apply.

[ryanahamilton]

@ashb yeah, I understand that desire, but I believe it to be anti-pattern for filtering to not have continuity with the URL params. When a user utilizes the back button, their previously applied tag filters will still persist.

[ashb]

From a user POV the existing behaviour is very useful though -- espeically if you have a large Airflow deployment, and you only want to see "your team's" DAGs -- having to re-apply the filter each time you visit the page would be tedious.

[ryanahamilton]

@ash I see that even though "tags" are typically an unspecified feature use, this feature was originally intended for this "team" use-case, which makes more sense to persist the filter. I'll see about refactoring this to keep the cookie in place.

[mik-laj]

I can see the benefits of @ryanahamilton 's solution, but also understand the needs of some users presented by @ashb who wanted selected tags to be remembered at all times. Maybe we can combine these two ideas and let the user keep the currently selected tags as default? I see it this way, that the user can browse DAGs normally according to @ryanahamilton 's suggestion, but if user wants to configure, be able to quickly return to the selected configuration, all users has to do is press the "Save as default" button. It doesn't even have to be on this page, but it could be a configuration option in your user profile settings ("Default selected tags" or something similar). I think this will better address the needs of both user groups.

[ryanahamilton]

@mik-laj I like that idea. It might make sense to save the status (all/active/paused) in the "default" preference as well since we're also cookie-ing that value? That feels like it should be addressed as a feature in a subsequent PR—I think I can offer a refactor to this PR that maintains the current user expectations but still delivers on the UX improvements.

[mik-laj]

@ryanahamilton I have no preference. Each solution works for me. Let me know when your change is ready for review.

[ryanahamilton]

I reverted the removal of the cookie storage, but I've updated it so that if cookie values exist, the tags= param(s) is added to the URL so it always matches the filtered result set.

I also made an update to strip the reset_tags=reset from the URL after the cookie value has been cleared.

[zacharya19]

LGTM, a few nits, but I really like the improvements!

[ashb]

Nice approach