A different way of manipulating ordering fields and directions, and combining with the configured default ordering.

[linusdm]

I ran into an issue related to ordering. The default ordering manipulation is quite opinionated regarding how ordering should work in the UI. I personally don't like the fact that you push fields to be ordered, because you can't make it clear in the table headers in what order the order fields will be applied (sorry for two levels of ordering here). I more like the behaviour where you set a new order field (and its direction), which overwrites the current order field. The only way to do this is to manipulate the order_by and order_directions fields directly (or use reset_order/1 and depend on the behaviour it exhibits, for example pushing the same field once again to toggle the direction).

The other thing I had to accomplish in an indirect way was prepending to the default order. Let me explain a bit: we have a default order defined for a schema, that uses the inserted_at and id fields to have a deterministic default ordering. When pressing a column header, I'd like to have that column combined with the default order of the two other fields. Right now we do something like this in a LV somewhere:

# 'flop' and 'field' are being passed in
new_order_direction =
  case Flop.current_order(flop, String.to_existing_atom(field)) do
    :asc -> :desc
    :desc -> :asc
    nil -> :asc
  end

  %{flop | page: 1, order_by: [field, :inserted_at, :id], order_directions: [new_order_direction, :desc, :desc]}
end

But this means we are defining the default sort order again in a LV, which might go out of sync with the configured Flop.Schema opts.

The two issues (manipulating the ordering fields and directions more explicitly, and combining with the configured default ordering) made me wonder if there are better ways to do this. Or maybe another API to manipulate ordering configuration. Maybe I'm just suggesting another ordering opinion, which might not be compatible with the existing implementation (which is okay, I'm just thinking out loud).

[woylie]

That sounds like you would like to have some Flop.push_order/3 that takes an additional opts argument.

First, you want to be able to switch between prepending and replacing. This could be done with a mode option (defaulting to :prepend to preserve the current behavior):

iex> flop = %Flop{order_by: [:name], order_directions: [:asc]}
iex> flop = Flop.push_order(flop, :email, mode: :replace)
iex> flop.order_by
[:email]
iex> flop.order_directions
[:asc]
iex> flop = Flop.push_order(flop, :email, mode: :replace)
iex> flop.order_directions
[:desc]

Second, you want to be able to always append one or multiple fields in order to ensure a deterministic order:

iex> flop = %Flop{order_by: [:name], order_directions: [:asc]}
iex> flop = Flop.push_order(flop, :email, mode: :replace, append: [:id])
iex> flop.order_by
[:email, :id]
iex> flop.order_directions
[:asc, :asc]
iex> flop = Flop.push_order(flop, :id, mode: :replace, append: [:id])
iex> flop.order_by
[:id]

Or with multiple fields to append:

iex> flop = %Flop{order_by: [:name], order_directions: [:asc]}
iex> flop = Flop.push_order(flop, :email, mode: :replace, append: [:inserted_at, :id])
iex> flop.order_by
[:email, :inserted_at, :id]
iex> flop.order_directions
[:asc]
iex> flop = Flop.push_order(flop, :id, mode: :replace, append: [:inserted_at, :id])
iex> flop.order_by
[:id, :inserted_at]

So in the last example, if you choose to sort by one of the defaults, it will be moved to the start of the list.

Descending order for a field to be appended could be done with append: [desc: :inserted_at, asc: :id].

I actually prefer the current solution where we only prepend without ever removing a field from the order. That way, the deterministic order is ensured automatically if the combination of the default order fields set in the schema is unique. No need to keep track of that elsewhere. In the example above, the Flop struct doesn't have enough information to find the right schema to find the default order. That could only be done by passing something like append_default_from: MyApp.Pet, but that's not pretty.

One thing that is probably confusing about the current implementation in flop_phoenix is that while the aria-sort attribute is only set on the column header of the first order field, as it should, the visual sort indicator is rendered on every column that is sorted, no matter in which position. I think I'll change that.

[woylie]

I created an issue for the last point: woylie/flop_phoenix#220