Dynamically generated columns in flop_table

Lu2cz

Hi,
I am stuck and would appreciate advice.

I have a database of assets. Each asset belongs to a category. Each category has specific set of attributes.

I want to be able to choose a category from a dropwdown menu and that will generate a table of assets only from that category with attributes being the columns. Is it even possible with flop_table?

8 comments

/phoenix #flop

0 472 8

2025-04-28 13:08:52 UTC

Marked As Solved

Show Best Posts
Show All (oldest first)
Show All (newest first)

woylie

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).

Post #2

Also Liked

sodapopcan

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>

Post #1

woylie

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.

Post #5

woylie

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.

Post #7

Last Post!

dimitarvp

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.