expanding/collapsing rows

Hello, Taehong!

Thank you for reaching out to us.

As a first step, we would like to know more details about the case:

1. The approximate data size(e.g. in Mb)
2. The characteristics of the machine where the slow data load is experienced
3. If you are using expandAllData() API call
4. You've mentioned "expanding/collapsing rows in the flat form" - please provide more details about this part
5. If it's possible to provide us with access to the page so we can test it on our side, it would also be very helpful

With this information, we'll be able to advise you better.

Looking forward to hearing from you.

Kind regards,
Solomiia

Hello, Taehong!

Thank you for getting back to us and for providing the details about the case.

As a first step in investigating the case, we recommend disabling expandAll and checking whether the component works without freezing in this case. Another approach is to debug the case using a smaller portion of the dataset, then gradually increase the data size to identify the bottleneck.

The video of the case would still be a great help. Our Customer Service Manager has already sent you an email, so please check your inbox and provide the video and other attachments in response to the letter.

Looking forward to hearing from you.

Kind regards,
Solomiia

Hello, Taehong!

Thank you for providing the video.

Based on the video, we can see that the described slow behavior while expanding is not caused by the client-side rendering. The “Loading data” popup shows that the client is waiting for a server response, and the Network tab confirms that the request stays in “pending” and “loading” status for some time before Flexmonster gets the response from the server and updates the view.

The server may be taking longer to respond, as the /select with expandAll: true for an 8-level hierarchy is quite a complex request.
As a first step in investigating the case, our team recommends looking for bottlenecks on the server by gradually increasing the hierarchy depth from 2 to 8 levels to identify where the slowdown starts.

Hope you will find our answer helpful. Please let us know if you have any further questions.

Kind regards,
Solomiia

Hello, Taehong!

Thank you for your swift response.

Please find our comments on the expanding&collapsing behavior shown on the provided video below:

• First expand at 00:08
  The communication process after the expand is clicked takes 26 seconds - from 00:08 when the expand was clicked, to 00:34 when Flexmonster received the data and immediately renders it. In the Network tab, it is shown that the response time was 2.58s, but in the video, we can see that the request was in pending status for ~ 25 seconds.
  Our team strongly recommends addressing this issue on your side in order to achieve better performance.
• Collapse on the nested node at 00:40
  We have reproduced the behavior shown on collapse at 00:40 of the video on our side. Our team will research possible solutions and get back to you with the research results with ETA September 29th.

We believe that addressing the above two cases will improve the performance. Our team also suggests shortening the nested levels where possible.

Please let us know if you have any further questions.

Kind regards,
Solomiia

Hello, Taehong!

Thank you for getting back to us and for providing additional details about the case.

We think that the provided use cases can be connected, so our Dev team will take a look at both expanding and collapsing behavior within the scope of the discussed research.

The research results will be shared with you by September 29th, as agreed.

Kind regards,
Solomiia

Hello, Taehong!

Hope you are doing well.

Our Dev team has analyzed the reported expanding and collapsing behavior for possible improvements and is back to you with the results of our research.

First, please note that expandAll itself is a quite complex operation, especially when a slice has a lot of nested levels, as 8 in our case. Our current algorithm works by expanding all the nodes and building a visual model before rendering. Each visual change on the grid—such as expand, collapse, or sort—triggers a re-render of the entire visual model. As a result, the collapse, which doesn't require any requests from the server, is equivalent to the expandAll in terms of drawing the changes on the grid.

Therefore, in the current implementation of the visual model, it is not possible to achieve any significant performance improvements. We recognize the drawbacks of the current implementation and aim to improve the architecture and algorithm in a new major update.

Our team understands the challenges the current expanding behavior may create and would like to recommend the following adjustments to improve your experience with Flexmonster:

• Avoid using expandAll by default.
  On big data amounts with many nested levels, this operation is complex on its own. In addition to that, Flexmonster needs to iterate through all the nodes every time we add visual changes and re-render the grid.
• Reduce the number of nested levels.
  You can create separate reports to focus on smaller data slices, move some fields to reportFilters where you can apply a filter to them, etc.
• Prefilter the data before loading it to Flexmonster, so only necessary members are sent to the client.
  For example, add a separate control with a filter by date.

Hope you will find our answer helpful.

Feel free to reach out to us in case of any other questions.

Kind regards,
Solomiia