Best way to model a filter with parameterized operations

[thiagomajesk]

Hi! What would be the best way to model this kind of filter?

Currently, I have to search for values scattered across the flop and form data structures to build this. Is there an easier way to access both the field values and the operation values? Any recommendations?

BTW, the examples for hidden_inputs_for_filter on the docs didn't work for me, so I'm not sure what that should generate.

PS.: It seems that there are some inconsistencies with the values available as i.field. The field value is not always populated correctly from what is present in the URL, so I have to resort to searching the flop :filters key to get the actual field value and the operation value - code is kinda ugly, but works.

[woylie]

Can you post some of your code, maybe? Then I can better understand what you are trying to do.

Some things to look out for:

• The form data implementation rejects fields that are not marked as filterable in the schema.
• There is a bug at the moment that can lead to wrongly associated form fields if you include fields that are not filterable in your field configuration (filters not associated correctly if filters are added for fields that are not filterable #204).
• Form fields are matched by field and operator.

[helderbarboza]

We have the <.filters> component that will render all of our filters. Inside of it, we call the <.filterset>, that will render essentially 3 things: field label, filter operation input, filter value input. Like this one:

  attr :meta, Flop.Meta, required: true
  attr :id, :string, default: nil
  attr :on_change, :string, default: "update-filter"
  attr :on_reset, :string, default: "reset-filter"
  attr :target, :string, default: nil
  attr :fields, :list
  attr :fields_filter_operators, :map # example: `%{inserted_at_date: [{gettext("is after"), :>=}]}`

  def filters(assigns) do
    assigns = assign(assigns, :form, Phoenix.Component.to_form(assigns.meta))

    ~H"""
    <.form
      for={@form}
      id={@id}
      phx-target={@target}
      phx-change={@on_change}
      phx-submit={@on_change}
      class="inline-flex flex-wrap items-center"
    >
      <.filter_fields :let={i} form={@form} fields={@fields} dynamic={false}>
        <MyApp.filterset
          label={i.label}
          operators={@fields_filter_operators[i.field.form.data.field]}
          key={i.field.form.data.field}
          field={i.field}
          type={i.type}
          {i.rest}
        />
      </.filter_fields>
    </.form>
    """
  end

In <.Flop.Phoenix.filter_fields>, I am passing this to the fields attribute:

[
  name: [
    label: gettext("Name")
  ],
  status: [
    label: gettext("Status"),
    type: "select",
    prompt: "",
    options: [
      {gettext("Enabled"), :enabled},
      {gettext("Disabled"), :disabled}
    ]
  ],
  inserted_at_date: [
    label: gettext("Created at"),
    type: "select",
    prompt: "",
    op: :>=,
    options: [
      {gettext("%{days} days ago", days: 15), "15"},
      {gettext("%{days} days ago", days: 30), "30"},
      {gettext("%{days} days ago", days: 60), "60"},
      {gettext("%{days} days ago", days: 90), "90"}
    ]
  ]
]

<.filterset> definition:

  attr :key, :atom, required: true
  attr :operators, :list
  attr :field, :any
  attr :type, :any
  attr :label, :string
  attr :rest, :global

  def filterset(assigns) do
    assigns =
      assign_new(assigns, :filter_params, fn %{field: field, key: key} ->
        Enum.find_value(field.form.source.flop.filters, fn %Flop.Filter{} = filter ->
          if filter.field == key, do: %{value: filter.value, op: filter.op}
        end)
      end)

    ~H"""
    <fieldset class="mr-2 inline-flex flex-row items-center gap-1 rounded bg-blue-100 px-2 py-1.5 text-blue-800">
      <label class="mr-1 block text-xs" for=""><%= @label %></label>
      <.input
        class="block appearance-none rounded border-none bg-blue-50 bg-none px-2 py-0.5 text-xs select:background-image focus:bg-white focus:outline-blue-500"
        name={"filters[#{@field.form.index}][op]"}
        value={@filter_params[:op]}
        type="select"
        options={@operators}
      />
      <.input
        class="block appearance-none rounded border-none bg-blue-50 bg-none px-2 py-0.5 text-xs select:background-image focus:bg-white focus:outline-blue-500"
        name={@field.name}
        value={@field.value || @filter_params[:value]}
        type={@type} 
        {@rest}
      />
    </fieldset>
    """
  end

Notice that I had to assign @filter_params, then I conditionally use it as parameter on the second <.input>, because sometimes @field.value can be empty.

`pry()` output:

pry(1)> assigns.field
%Phoenix.HTML.FormField{
  id: "flop_filters_0_value",
  name: "filters[0][value]",
  errors: [],
  field: :value,
  form: %Phoenix.HTML.Form{
    source: %Flop.Meta{
      current_offset: 0,
      current_page: 1,
      page_size: 50,
      schema: MyApp.Schema.Product,
      total_count: 0,
      total_pages: 0,
      errors: [],
      flop: %Flop{
        limit: 50,
        filters: [
          %Flop.Filter{field: :name, op: :ilike, value: "hello"},
          %Flop.Filter{field: :status, op: :==, value: "enabled"},
          %Flop.Filter{field: :inserted_at_date, op: :>=, value: "30"}
        ],
        ...
      },
      has_next_page?: false,
      has_previous_page?: false,
      opts: [for: MyApp.Schema.Product],
      params: %{},
      ...
    },
    impl: Phoenix.HTML.FormData.Flop.Meta,
    id: "flop_filters_0",
    name: "filters[0]",
    data: %Flop.Filter{field: :name, op: :==, value: nil},
    hidden: [field: :name],
    params: %{},
    errors: [],
    options: [],
    index: 0,
    action: nil
  },
  value: nil
}

[woylie]

I see, so you want to be able to dynamically select the operator in the form. I haven't implemented a form like that so far. I'll have to look into that in detail when I find some time. For now, just some notes that come to mind.

Getting filters

You're using Enum.find to get a filter value and operator from a list of filters. The Flop.Filter module has a couple of useful functions for dealing with lists of filters, including get/2 and fetch/2.

Getting the operator in a form

hidden_inputs_for_filter/1 is used twice by the filter_fields: Once for the main form to render things pagination and sorting parameters, and then once for each filter to render hidden inputs for the field name and the operator value (code).

In your case, you don't want want render the hidden input for the operator. The Phoenix.HTML.FormData implementation for Flop.Meta has a skip_hidden_op option, but the filter_fields component currently doesn't allow to set it. So in your implementation, you will always get a hidden op input before the op select.

But that also means that you can read the operator from the form struct. Instead of passing the operators attribute, you should be able to pass operator={Keyword.fetch!(i.field.form.hidden, :op)}.

Value not being populated

This happens because currently, the field options are matched to the filters in the Flop struct on both the field and the operator. If you don't explicitly set an operator, == is used as a default. This is done to support filter forms with multiple inputs on the same field, but with different operators.

So if you pass a field configuration like this:

status: [
    label: gettext("Status"),
    type: "select",
    prompt: "",
    options: [
      {gettext("Enabled"), :enabled},
      {gettext("Disabled"), :disabled}
    ]
  ]

The filter_fields component will look for a filter with the field status and the operator ==. If the operator is now changed in the form to !=, the component will not be able to find a value for the field/operator. In this case, you would have to set the operator dynamically in the field config:

status: [
    label: gettext("Status"),
    type: "select",
    prompt: "",
    options: [
      {gettext("Enabled"), :enabled},
      {gettext("Disabled"), :disabled}
    ],
    op: Map.get(Flop.Filter.get(@meta.flop.filters, :status) || %{}, :op, :==)
  ]

Conclusion

The ergonomics could probably be better. I opened an issue for this: #216.