asked on September 23, 2025
Hello,
Flexmonster offers several filtering options (by value, by selection, and report filters), but these filters are applied after the dataset is loaded into the pivot. In our case, we need to apply custom filters beforehand, at the data loading stage. To achieve this, we need to integrate our own UI for defining filtering conditions, which will pre-filter the data before it reaches the table.
The challenge is that our collections are dynamic, and fields are not guaranteed. In order to display the custom filter UI, we need to fetch fields along with their distinct values. This operation is quite expensive. To optimize, one approach I’m considering is to fetch all fields for the collection and then call the distinct values only when a field is selected. This way, it fetches distinct values only for the clicked or selected fields.
However, I believe that once this is applied, Flexmonster might still fetch the members for the same fields again, right? Additonally Are there any known methods to achieve this pre-filtering in a more efficient way than this?
⋅ September 24, 2025
Hello,
Thank you for your question.
Your understanding of how Flexmonster would work with custom filters is correct. Assuming that you would need all members to populate your custom filter UI, doing so would require making separate requests. Without additional measures taken, Flexmonster would resend these requests when loading the data into the component itself.
If you want to optimize the load /members once, both for the custom filter and Flexmonster, this is possible by adding a cache for /members requests: https://jsfiddle.net/flexmonster/ys0r63va/
In this example, the custom API endpoint is a function that forwards requests to the server and saves /members responses. When the request is called to populate the "Category" selection filter, the response is cached. The second request is not sent to the server when the "Category" field is added to the slice, since the response was already saved.
However, while your concern is valid, it should not result in significant overhead in practice. The /select request is the heavier operation, since it performs aggregations and loads the actual dataset. Importantly, /select is always filtered based on the filters defined in the report. By predefining these filters in the initial report, as in the code snippet below, you are already optimizing the heaviest part of the workflow.
{
uniqueName: "Category",
filter:{
members: ["Bikes", "Cars"]
},
}
In comparison, /members requests are lightweight. They only return the unique values for a single column, without performing aggregations. Because of this, optimizing /members does not provide much additional value.
Please let us know if our answer helped you.
Best regards,
Maksym
⋅ September 26, 2025
Yea thanks, this helps, also, is there any option to limit the number of result in flat table ?
⋅ September 26, 2025
Hello,
Thank you for your question.
To limit the amount of data returned from the flat table, we recommend using the same prefiltering mechanism as for the pivot table. While this approach will still reduce the dataset to some extent, it can be more meaningful from a user perspective to filter the data based on relevant conditions rather than simply cutting off the dataset by a fixed limit.
Please let us know if this would work for you.
Best regards,
Maksym
⋅ October 8, 2025
Hello,
Hope you are doing well.
We wonder if you have tried implementing the suggested prefiltering approach for the flat view.
Please let us know if it worked for you.
Best regards,
Maskym
