A schema-driven filter bar: the active filters as removable chips, plus an "Add filter" popover that walks field -> operator -> value.

It speaks PetalComponents.DataTable.State, the same struct <.data_table> is driven by, so it drops in next to a table sharing one state - or stands alone above any list, card grid or custom query UI. The operator vocabulary is State.ops/0; this component only ever selects subsets of it, and every mutation goes through State.put_filter/4 or State.handle_op/3.

Two wiring modes, inferred from which attr you pass (passing neither raises, exactly like data_table/1):

• link mode (path) - every change is a patch URL built from State.to_params/1. handle_params plus State.from_params/2 is the whole backend, and the URL is the state store:

  def handle_params(params, _uri, socket) do
    state = State.from_params(params, fields: [:name, :category, :price])
    {rows, state} = Engine.List.run(all_products(), state)
    {:noreply, assign(socket, rows: rows, table: state)}
  end
  
  <.filters id="f" state={@table} path={~p"/products"}>
    <:field field={:name} label="Name" type="text" />
    <:field field={:category} type="select" options={["tools", "toys"]} />
    <:field field={:price} label="Price" type="number_range" />
  </.filters>

• event mode (on_change) - chip removal, apply and clear-all push the op-shaped payloads State.handle_op/3 already parses, so a LiveView already wired for an event-mode data_table gains a filter bar without a single new handler clause:

  def handle_event("table", params, socket) do
    state = State.handle_op(socket.assigns.table, params, fields: [:name, :category])
    {rows, state} = Engine.List.run(all_products(), state)
    {:noreply, assign(socket, rows: rows, table: state)}
  end
  
  <.filters id="f" state={@table} on_change="table">
    <:field field={:name} label="Name" type="text" />
    <:field field={:category} type="select" options={["tools", "toys"]} />
  </.filters>

Sharing one State with a data table

Point both at the same struct and the same event (or the same path) and they compose with no glue: filter from the bar and the table updates, filter from a column header and a chip appears.

<.filters id="products-filters" state={@table} on_change="table">
  <:field field={:category} type="select" options={["tools", "toys"]} />
  <:field field={:in_stock} label="In stock" type="boolean" />
</.filters>

<.data_table id="products" rows={@rows} state={@table} on_change="table">
  <:col :let={p} field={:name} sortable>{p.name}</:col>
  <:col :let={p} field={:category} filterable="select" options={["tools", "toys"]}>
    {p.category}
  </:col>
</.data_table>

Field types

The :field slot is the registry. type picks the operator subset (always a subset of State.ops/0) and the value editor:

Valueless operators (is_empty, is_not_empty) render no value input, per State.valueless_op?/1.