I have a data table with approximately 10 columns. The rows load in a paginated / lazy loading manner, hence, around 15 records are loaded at a time until you paginate or scroll down. Now, I would want to apply column filters on this table using a list of multi select options. Should this list of options in the filter multi-select list contain only values that have already been loaded in the UI or all possible values that the field could have?

For example (using the screenshot as reference), I want to apply filter on the "Team" column. The UI has only loaded data for Team 1 and Team 2, however, there are more values that haven't been loaded yet (Team 3, Team 4, Team 5 etc). So the question is :

  1. Should we only show Team 1 and Team 2 as options in the filter multi-select? This will be filtering values only that have been loaded in the UI.


  2. Should we list all values that the column can have (Team 1, Team 2, Team 3 etc.) and make a server call to fetch records based on the selection?enter image description here

1 Answer 1


If your intent is to have the user filter only the results loaded so far, then I'd expect you would only show terms relevant to those items.

I would expect, however, that if your user wants to filter the table to display only a certain category of result, the results they want to see may well include items that have not been loaded into the UI. Thus I would expect the filter options to be comprehensive across all of the records, not just those currently loaded into the front end.

STANDARD CAVEAT: I don't have nearly enough context of your system or users to say anything definitive, of course, so your best bet would be to run that by your users.

  • Thank you Mattynabib. That makes sense to me too. The options in the filters should include all possible fields. Just to add a bit more context, the table currently works with a 'push' mechanism as there are 'live' data points that are shown in some columns. For instance there is a column called 'time taken' which update every second. In such a scenario, if we go for a pull mechanism from the sever we run the risk of having a 'loader' every other second for the entire table. With this new context, do you think we can maintain the behaviour that you have mentioned earlier?
    – PabloB
    Commented May 8, 2023 at 3:02
  • Hmmm... interesting, but it strikes me as more of a technical challenge than a UX problem. Perhaps the team can only update the fields that have been viewed in the filter or something. But having that live update seems pretty heavy... cool maybe, but is it something your users really need, or could a snapshot at the time the data is pulled be enough?
    – Mattynabib
    Commented May 8, 2023 at 16:16
  • 1
    Well, our assumption is that there are live data points that are being relied on in the table by the viewer. I think this calls for a conversation with customers to verify the scenario of usage before picking a direction?
    – PabloB
    Commented May 12, 2023 at 5:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.