Support default values for filters

[sevenseacat]

Description

Allow filters to specify default values that are applied on initial page load. This is useful for common scenarios like showing only active records by default.

Proposed API

<!-- Boolean with default -->
<:col field="active" filter={[type: :boolean, default: true]} />

<!-- Select with default -->
<:col field="status" filter={[type: :select, default: "active", options: [...]]} />

<!-- Multi-select with default -->
<:col field="tags" filter={[type: :multi_select, default: ["featured"], options: [...]]} />

<!-- Number range with default -->
<:col field="price" filter={[type: :number_range, default: %{min: 0, max: 100}]} />

<!-- Date range with default -->
<:col field="created_at" filter={[type: :date_range, default: %{from: ~D[2024-01-01]}]} />

URL Sync Behavior

When URL sync is enabled, defaults need special handling to distinguish "first visit" from "user cleared all filters":

1. First visit (no URL params): Apply defaults internally, keep URL clean
2. User changes any filter: Push full filter state to URL (their change + any defaults still active)
3. User clears all filters: Remove URL params, defaults do NOT reapply
4. Someone visits clean URL: Fresh mount, defaults apply (first visit experience)

Implementation uses a defaults_applied flag to track whether we're past the initial load.

Design Decisions

• "Clear all" clears to empty, not back to defaults (defaults are just initial state)
• Defaults count as active filters in the filter count badge
• Invalid defaults are silently ignored (no validation errors)

[davemcorwin]

Hi @sevenseacat ! Wondering if the behavior as described here is the best approach when taking url sync into account. When we use url sync, we're doing it to achieve consistency between the url and the filters. If the applied filters are different between first render and subsequent renders with the same url, then we lose that consistency.

One approach could be to look at a clean url as equal to the default state which includes any default filters. Any changes to the filters are represented in a change to the url. From this point of view, it may make more sense to have a "restore defaults" action instead of a "clear filters" action. When there are no default filters, the result is the same, but when there are default filters, this distinction will keep the url and the filters consistent. This implies that default filters are NOT pushed to the url.

Alternatively, we could look at a clean url as having NO filters, so when there are defaults, on visit to the clean url, we could push a patch that includes the default filters. This keeps the functionality of "clear filters" action BUT in order to return to the default state, the use must clear the filters and refresh the page. I think this is a bit wonky since fresh navigation to the clean url results in a redirect, but using "clear filters" can get you there, but it does maintain consistency between the url and the filters.

Thoughts?