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?
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
Yea thanks, this helps, also, is there any option to limit the number of result in flat table ?
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
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