Scenario:
There is a yeti-table with several pages of results that uses the loadData property to populate with async data and repopulate when filters or sorting on the table is changed. The table has the header to facilitate this as well, allowing each column to be filtered in different ways.
Issue:
When a user turns to page 4 (or some later page) and then modifies the filters, the loadData task is fired with the new table pagination, sort, and filter data. The pagination data is not set back to page 1. If the filters applied yield results that are less than the page the user is currently on, the user experiences what seems like no results until they realize they are still on page 4.
Current workaround:
Initially this was being handled in app with observers, then later by checking manually if filters had changed between the previous loadData task being called and the current loadData task being called. However, I believe that this behavior should be handled inherently inside the addon to provide a more appropriate expected user experience.
Suggested resolution:
I believe this behavior should be handled inside the yeti-table addon itself. I cannot think of a scenario where the user would apply a filter while not on page 1 and still want to be on that page. I can only see a scenario where the user enters new filter criteria and is taken back to page 1 of the results.
I'm open to hearing the other side of the argument, if there is one. If not, I'm happy to work on the changes necessary to implement this in the addon.
Scenario: There is a yeti-table with several pages of results that uses the
loadDataproperty to populate with async data and repopulate when filters or sorting on the table is changed. The table has the header to facilitate this as well, allowing each column to be filtered in different ways.Issue: When a user turns to page 4 (or some later page) and then modifies the filters, the
loadDatatask is fired with the new table pagination, sort, and filter data. The pagination data is not set back to page 1. If the filters applied yield results that are less than the page the user is currently on, the user experiences what seems like no results until they realize they are still on page 4.Current workaround: Initially this was being handled in app with observers, then later by checking manually if filters had changed between the previous
loadDatatask being called and the currentloadDatatask being called. However, I believe that this behavior should be handled inherently inside the addon to provide a more appropriate expected user experience.Suggested resolution: I believe this behavior should be handled inside the yeti-table addon itself. I cannot think of a scenario where the user would apply a filter while not on page 1 and still want to be on that page. I can only see a scenario where the user enters new filter criteria and is taken back to page 1 of the results.
I'm open to hearing the other side of the argument, if there is one. If not, I'm happy to work on the changes necessary to implement this in the addon.