-
Notifications
You must be signed in to change notification settings - Fork 31
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
Column-based filter widgets #1
Comments
I think that it would be great to extend this widget to support all kind of inputs, f.e.: data picker, time picker, select, etc. |
I am quite curious about testing the data table once I have the time opportunity for it... I would just like to point, please be particularly mindful of any CSS choice taken that is not used for technical purposes, such as color choices, fixed sizes, icons etc...... so that it may be as easy as possible to integrate the data table, plugging in different color styles or icon styles, if that is possible. Otherwise, it will be one more component, that everybody else in order to integrate it into a page with its own strict styling convetions (e.g more on grey side, more on the light colors, bigger buttons / smaller buttons, etc..), will have to take over and customize to be able to integrate without looking a component coming from out of space. |
One further suggestion, The only case where t might be useful to have filter on column is when you want to have a date type column offer a date picker UI to set in a filter... The text field per column to do a search to me, just feels like an outdated UI. |
The idea of column filters is, to give the user a way of filtering the grid for specific data, per column.
It would allow the user to enter a value for that the column's content is filtered for.
If a filter widget is set for a column, it could be rendered e.g. inside of the column's header (below the title) or e.g. in a row right below a header / sub-header. The size of the widgets would be 100% of the columns width (also resizing when the column width changes); the height would be the organic height of the filters widget.
The filter values could be read on filter widget change (ValueChangeEvent) and set on the data provider instance. The data provider then reloads the current page. Those filter values could also be persistent and remembered on pagination, sorting etc. events (depending on the impl. of the data provider).
To allow a first attempt of an implementation, it would be already sufficient, if we could put widgets in column headers (to be rendered below the header's title, like the image above shows) , because then, all the custom column filter logic could be implemented in user-land code (or as a plugin for the MaterialTable).
For a most simple implementation (leaving a lot to be impl. in user-land) it would be sufficient if the API of
MaterialDataTable
would support:Thanks and best,
Aron
The text was updated successfully, but these errors were encountered: