Dynamically generated columns in flop_table

Hello and welcome!

Can you share a little more about your data structure? Is category polymorphic or do you mean only some attributes apply to different categories?

More broadly, Flop can’t dynamically generate tables based on different schemas (you would have to make a table for each type and switch them out), but you could conditionally render certain columns based on certain conditions:

<:col :let={record} :if={record.category.type == :some_type}>
  {record.name}
</:col>

If you are able to obtain a list of columns by category, you could use a :for attribute on the :col slot.

def columns(:category_a) do
  [{"Name", :name}]
end

def render(assigns)
  ~H"""
  <Flop.Phoenix.table items={@items} meta={@meta} path={~p"/items"}>
    <:col
      :let={i}
      :for={{label, field} <- columns(@category)}
      label={label}
      field={field}
    >
      {Map.get(i, field)}
    </:col>
  </Flop.Phoenix.table>
  """
end

You could also add a formatter function to the tuple if you need to format columns differently (e.g. to format datetimes).

Oh, that’s a pretty good idea

Thank you both @sodapopcan @woylie for you answers!

Is there a way to generate filter field for each column as well? Because as I read through the docs, I understand it that I need them to be defined in Flop.Schema..

My idea is that each column has its own field so that user can filter.
Each attribute is has defined type of data it receives, so it can be passed to the filters.

You need to define the filterable fields explicitly by design. Making every column filterable automatically can introduce vulnerabilities.

To expand on the answers above, you can retrieve a list of all filterable columns with Flop.Schema.filterable/1 and then get additional information on each field with Flop.Schema.field_info/2.

Huh? Meaning? Example?

If you have a query that returns only some columns to the user, and you allow to filter on columns that are normally hidden from the user, the user can gain insight about the column values just by using filters. For example, you might have a view of users that only shows the age and the city of each user. If the filter API allows you to apply filters on the email column, you can now check whether a user with a certain email address is in the system. Or maybe you already know that a user with a certain email address is in the system - now you can easily find the age and city of that user, even though the UI normally doesn’t give access to this information. Or if you have a numerical field, let’s say a trust_score that is for internal use only, you can easily construct filters with > and < operators to narrow down the exact value for a particular user.

Thanks, very helpful. I see that we should be adding our own authz / need-to-know-only-basis-filters on top of your stuff which is completely fair. I initially thought that you were saying SQL injections are possible.