AshTable - a sortable paginated LiveView table component for Ash

As part of my experiments in learning Ash, I decided to extract a sortable, paginated table component we use on one of our projects and rework it to use Ash. It turned out to be not too terrible, so I thought I’d [share it with the world. It’s very early, and has almost no styling. But it works, has tests, and if nothing else might serve as a useful example for folks to build on.

As with all my work, feedback and contributions are welcomed :slight_smile:


Awesome :slight_smile:

Some small notes:

Additional action opts

You’ll likely want to accept additional options to the action for things like authorization, multitenancy, etc. A name used for this in some places is action_opts or read_opts.

results =
      query |> apply_sort(sort, columns) |>!(Keyword.merge(assigns[:action_opts] || [], [page: [limit: limit, offset: offset]]))

Multiple pagination strategies

There is keyset and offset pagination available in core, for keyset pagination, you’d replace offset with an after or before key. With that in mind, you might want to accept page_opts (or perhaps use the action_opts vs read_opts suggestion above to encompass the concept)

Recently did some related work, more in the ‘batteries-included’ fashion. Here’s a live demo of a PoC that I prepared for a former client of mine:

It’s note a library (although I did put effort into making the table a reusable component), but maybe some ideas could be an inspiration. E.g. the table auto-configures itself from the Ash resource. Columns can be dragged around and resized, inline editing is supported, etc.


That’s a really nice example. There’s definitely some bits I’d like to borrow and incorporate. I love how it generates the columns for you and does the whole CRUD lifecycle. Nice work, thanks for sharing that!


Thanks Zach, having a read_options as assign you can pass definitely makes sense. Supporting multiple pagination strategies also would be great, just got give it a little more thought in terms of how to support it.

1 Like

Following @zachdaniel 's suggestion, released 0.2.0 which allows read_options to be passed to specify tenant, actor, etc

1 Like


Something you might also consider is allowing a list as the sort_key, and constructing the sort_expr automatically if they don’t provide an apply_sort. Would look something like this:

require Ash.Sort

sort = 
  case sort_key do
    value when is_atom(value) or is_string(value) -> 
      {value, direction}
    value when is_list(value) -> 
      {path, [name]} = Enum.split(value, -1)

    {Ash.Sort.expr_sort(ref(^path, ^name)), direction}

Hmm… that’s really interesting. I wonder if it might be even nicer to lightly parse the sort_key (not married to this name) and if there is a . in it turn it into a path.

that is clever, I’m into it :+1:

now that you point it out though, that is just what ash core should do also perhaps. People are typically pretty annoyed to break out expr_sort just for a to_one related field.

its on the roadmap now: Support related sorts via dot separated identifiers in sort · Issue #1272 · ash-project/ash · GitHub

Didn’t want to let this one slip by, this is also really really cool! Are you thinking of extracting this out to a library at some point? Really love the customizability of it.


Thanks, Zach. I was hoping to turn it into an enterprise-backed open source library, but it didn’t work out in the end. Given how much work goes into open source (I learned the hard way), I won’t be able to take this on. However, I hope that someone could be inspired by this POC.

1 Like