-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Complex filtering UI #5
Comments
With this commit, Ecto resolver can now understand complex filtering like this: > /admin/users?inserted_at[from]=2020-12-30&inserted_at[to]=2020-12-31 > /admin/users?id=[gte]60 > /admin/users?order_by=[desc]id But this is only the first step, the next step is to build a UI to go along with it. This commit also breaks the current search field, which previously searches across multiple fields as specified by users, whereas the new filtering engine expects search per field. Partially fixes #5
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! |
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 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 |
Would be nice to support a more complex filtering system with a nice UI. For example, given an
index/1
that looks like: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.The text was updated successfully, but these errors were encountered: