edisonywh / backoffice

Admin tool built with the PETAL stack
MIT License
217 stars 15 forks source link

Complex filtering UI #5

Open edisonywh opened 3 years ago

edisonywh commented 3 years ago

Would be nice to support a more complex filtering system with a nice UI. For example, given an index/1 that looks like:

index do
  field :name, :string, search: true
  field :age, :integer, search: true
  field :verified, :boolean, search: true
end

We know the type of the field, so we should be able to render the corresponding form fields for them (text_input for :string, number_input for :age, checkbox for :boolean). Then on field submission we can package it into a nice query params and have UserLive.Index (Backoffice.Resources) handle the query params, before passing it off to Resolvers.

e.g:

`?name=search&age=>18&verified=true&page=1" then perhaps convert it to something more structured for resolvers to work with?

Then the resolvers receives them in page_otps and can decide what to do with these fields.

edisonywh commented 3 years ago

I have a draft for the filtering engine behind the scene, but I'm pretty clueless about what the UI should be, so if anyone has any example of a good filtering UI, feel free to share them!

edisonywh commented 3 years ago

image

Right now I have a UI that looks like this.

I like the way the filters are displayed (and deleteable), but the form field for adding filters needs some work. Right now we rely on user knowing filter API like status=[not]active or that you can filter between date with something like inserted_at[from]=2020-01-20&inserted_at[to]=2020-01-22, but ideally this should be all presented in the UI.

One idea is that we can maybe derive the type from the new DSL at some point, so for example:

index do
  field :age, :integer
  field :verified, :boolean
end

Then we know to render number_input for age, checkbox for verified etc.

P.S: credit where credit is due, the idea for the UI was inspired by this Dribbble post