Flop - Filtering, sorting and pagination for Ecto

Flop is an Elixir library that applies filtering, ordering and pagination parameters to your Ecto queries.

  • offset-based pagination with offset/limit or page/page_size
  • cursor-based pagination
  • sorting
  • filtering
  • parameter validation
  • configurable filterable and sortable fields
  • join fields
  • compound fields
  • query and meta data helpers
  • Relay connection formatter (edges, nodes and page info)
  • UI helpers and URL builders through Flop Phoenix.
14 Likes

I found Flip and Flop_Phoenix a few days ago on GitHub and since then I’ve waited for this thread :wink:

Will definetly use it, very nice work :slight_smile:

Is there a small demo project available? As a beginner this is the best way for me to learn how to use a library.

1 Like

There is no demo project at the moment, but there are step-by-step instructions in the readmes. If something is unclear, let me know, so that I can improve the documentation :slight_smile:

1 Like

Nice work! Can it join+preload associations and filter using fields from associations? This seems to be what’s missing from many of the similar libs.

It can not add join expressions or preload data for you. Flop does not try to be an alternate query DSL - it just adds WHERE, ORDER BY and LIMIT clauses derived from user-generated parameters to existing Ecto queries.

However, you can define join fields, which are basically a mapping from a field alias to a field name on a named binding (see join fields). You will have to ensure that the necessary named bindings are added to the Ecto query you pass to the Flop functions. This approach means that you can filter and sort by anything that Ecto allows to join on: not only associations, but also the results of subqueries. To avoid unnecessary joins, you can retrieve a list of necessary bindings for a given parameter map before building the query (see Flop.bindings/3).

Hi, just trying out your package, thanks for making it. :grinning:

Is it possible (for me as a package user) to add a way to find out if there is more records, in cursor-based pagination?

Ideally I would like actually to know if there are records before the first and after the last entities (“page”) currently fetched.

That means running min/max postgres functions on the query, without LIMIT and sorting on it.

Any ideas are welcome, and it does not have to be super-optimized.

Thanks!

If you run a cursor-paginated query, Flop will make the query with the given limit + 1 (first, last, or default_limit). The *run functions will remove the extra row from the result set. The returned Flop.Meta struct has has_next_page? or has_previous_page? fields, where the value of one of the fields depends on the existence of the extra row, and the other one depends on the presence of a after or before parameter.

1 Like

Thanks. Is it possible to do a range/between filtering on the same field with this library? For example records between two dates.

Yes, filters are passed as a list, you can combine as many as you want, including ones on the same field. All filters are combined with a logical AND. One thing that isn’t possible at the moment is combining multiple filters with a logical OR. (If you want to filter a single string field, there are ilike_or and like_or operators`, though.)

1 Like

Have you given any thought to including this approach for performance in a future release?

Otherwise, looks great!

That is already implemented! You can choose between offset-based and cursor-based pagination. See also:

Flop.Phoenix has two different UI components for offset-based and cursor-based pagination.

2 Likes