Filter w/ Default Value "Inverts" the Active State Indicator

[caseydwyer]

• Laravel Version: 9.52.0
• Nova Version: 4.22.0
• PHP Version: 8.0.11
• Database Driver & Version: MySQL 8
• Operating System and Version: Windows 10
• Browser type and version: Chrome v110.0.5481.96

Description:

When a filter has a default value, the active state (ie, bg-primary-500 + active-filter count on the filter button) is inverted. That is, it shows an inactive state when the default value is applied, and an active state when the default filter is not applied.

Detailed steps to reproduce the issue on a fresh Nova installation:

1. Create a Filter.
2. Give it a default value.
3. Register it with the Resource.
4. Visit the Resource detail.
5. Witness the litness.

Screencap

Note that it works correctly/as expected, when the default() method is removed from the Filter.

[crynobone]

This is the expected behaviour with Default value

[caseydwyer]

This is the expected behaviour with Default value

@crynobone It is? 🤔

I can kinda see that argument for the initial state (eg, if the default state on a filter is enabled, but we don't consider anything as being "manually activated" so the indicator is off), but it makes less sense if that filter is then cleared out—as in the GIF above.

Because in that case, you now have no filters activated, not even the default, but the indicator is showing that something is enabled.

Does that make sense? Just feels buggy from the average user's perspective.

[crynobone]

See #3119 (comment)

[caseydwyer]

@crynobone thanks for the link, that thread was good context! Also an interesting note from @davidhemphill:

I get where you're coming from, but how far does this logic extend? If the developer adds a where constraint on their indexQuery method, should that show up in the UI as well since it technically does the same thing as providing a default value to the filter?

In my mind, that's actually a key difference between using an indexQuery vs. filters—the former is a quasi-hardcoded detail built by a developer, handled via code and not intended for direct manipulation by a user of the GUI. Filters, on the other hand, are specifically intended for manipulation by an end user, and they expose components with helpful context (ie, filter button with active/inactive indicator).

So TL;DR - Personally, I would agree with David's point that the ___Query methods shouldn't be factored into any front-end indicators...but also would draw a distinction between those and filters, since filters are, by design, intended to be toggled/managed by the end-user—and should really be the sole driver of the active indicator.

I'm also curious to hear thoughts on the back half of this issue. That is, I can get behind the argument that default filters shouldn't result in an active state for the indicator. But it feels extra-jarring to then see the indicator become active, when you explicitly clear out all filters (eg, disable them, as in the GIF above). I think it would make more sense to either...

• Indicate filters as active when a default value is set (ie, the same/standard approach to user-managed filters w/o a default), or
• Entirely exclude any filter w/ a default value, from factoring into the active indicator

I would lean toward option 1, personally, but the second one would maybe be a decent middle-ground, since the current setup just feels exactly backwards of what makes sense and what I would expect (in that scenario where any/all filters-with-a-default are then toggled off via the GUI and the indicator shows as active).

Does that make sense, and if so, any thoughts on that piece of the equation?