Make Built-in Filters usable without dedicated Modules

[PJUllrich]

I tried to add filters to my Backpex LiveResources today and really struggled with it unfortunately. I had most problems with Backpex's philosophy of "Create a dedicated module for every filter on every field". Why can't I reuse the built-in filters and configure them from "outside"? I really don't want to create one module per field per schema I want to filter :D

For example, let's say I have a schema with one association and I want to add filters for the schema's id and association id (e.g. pet.id and pet.owner_id). If I read the Backpex docs correctly, I'd need to create an PetIdFilter and a PetOwnerIdFilter but that becomes very boilerplatey very quickly. Instead, I'd rather like to have a built-in filter to filter IDs generally.

The same problem occurs when I want to filter by Enum fields. I can't use the built-in Select filter because I have to hard-code the options inside the filter module. Why can't I pass the options into the built-in Select filter inside my filters/0 callback? That way I could reuse the built-in Select filter for multiple fields without having to create boilerplate filter modules for each field.

---

I actually built a generic IDFilter which can filter by primary keys, association IDs, and even plain text (no ilike though, just simply equality comparison)

defmodule MyAppWeb.Filters.IdFilter do
  @moduledoc """
  Filters a LiveResource by an ID.
  """

  @behaviour Backpex.Filter

  use BackpexWeb, :filter

  # This label will appear in the filters list and I cannot overwrite it from outside :(
  @impl Backpex.Filter
  def label, do: "ID"

  @impl Backpex.Filter
  def can?(_assigns), do: true

  @impl Backpex.Filter

  def render(assigns) do
    ~H"""
    {@label}
    """
  end

  @impl Backpex.Filter
  def render_form(assigns) do
    ~H"""
    <div class="mt-2 flex flex-col space-y-2">
      <input type="text" name={@form[@field].name} class="input" />
    </div>
    """
  end

  @impl Backpex.Filter
  def query(query, field, id, _assigns) do
    id = String.trim(id)
    Ecto.Query.where(query, ^[{field, id}])
  end
end

[PJUllrich]

While writing my own generic filters, the biggest problem was that a filter is unaware of which field it filters. If it could just receive a "field" assign in e.g. the query/4 or options/1 callback of Filter and Filter.Select respectively, I could reuse a filter for many fields because I just need to return the right options or query for the right field. Ideally this would be a key independent of the field name because multiple schemas might have eg a "status" field and I need to return different options for different schemas.

[Flo0807]

Hey!

I truly understand you. Creating a module for each filter does not scale. Ideally, filters would work the same way as fields. This has been on our list for a long time (see #357), but we've never managed to find the time to work on it.

Besides simplifying the API for filters, there are other filter-related issues as well. Currently, filters are not validated, which can cause internal server errors (see #311 and #331).

Ideally

• Filters would be casted through a changeset and there would be a public API for defining additional casting/validation rules to prevent internal server errors (this makes it easier to work with the casted values in Backpex, too)
• Filters can be used like fields without the need to define a dedicated filter module (with some built-in Backpex filters: boolean, select etc)
• You are still able to define a dedicated filter module for advanced or generic filters that can be used across resources (the same like custom fields)

In addition, we should not forget Ash and find a way to abstract filter expressions (other than returning an ecto query).

@PJUllrich