Using onBlur to activate the filter instead of using onFilterChange

I am using server-side filtering, I overrode onFilterChange to activate filter every time the filter list is changed, but the problem is every time the filter list is changed, the backend API will be called to update the table’s data. It makes the layout quite lag and the backend is called too much. I want to filter every time the user leaves the field or maybe we will add the button in TableList called Submit Filter, as soon as the user enters all the field they need to filter then click the button to activate the filter.

Tech	Version
Material-UI	3.9.2
MUI-datatables	2.8.0
React	16.8.5
browser	Chrome
etc

[mbniebergall]

@nmdhulipud this was released in 2.12.0 (see https://github.com/gregnb/mui-datatables/releases/tag/2.12.0). I have already implemented using it on a project and performance is significantly improved. Thanks @gabrielliwerant !

[nbrustein]

Mostly just to summarize what people have already said clearly.

Problem: When using the serverSide option, onFilterChange and onTableChange are often called too much. In responding to them, you end up hammering your API with new requests that aren’t really for what the user wants, since the user is not yet finished filling out their desired filters or typing in the search box.

Solutions

1. Apply button on the filter form and on the search input. These buttons could be attached to a new event (or new events, one for each). A developer could then respond to those events and only trigger an API call when the user indicates they are finished entering their filters. If this solution is implemented, it might also be necessary to make configurable the text on the button on the actual component used for the button, and to do these separately for the search box and the filter form.
2. onBlur events for the filter form and the search input.
3. debounce logic. It is currently possible for the developer to implement this herself, but it would also be possible to either add new events that only get triggered after a debounced delay, or to add configuration that allows for debouncing the existing events. (It might also be possible, rather than making this configuration, to provide a hook that debounces the table state changes.)

Would you be willing to consider PRs for any/all of these things if someone were to submit them?