You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
First of all, I am aware of the fact that this table does not mean to implement any kind of virtualization (yet?), but by using e.g. 10.000 entries of data (in combination with filters or other components which might re-render) it is completely unresponsive and exhausts rendering time.
I actually think this might not be classified as a bug, but maybe you can give me a hint on how to handle this situation.
Given the following scenario:
I got a column filter which is any mantine input. I have to track the value (so control the component) because the requirement is to keep the state cross paged. Now, whenever I change the value, I have to update it in my state, whereas the server request is debounced for a few seconds. Due to the fact that the filter values changes (and therefore the column definitions because I might have to change the filtering property etc.) the whole table (including all 10.000 entries) re-renders on every key-up.
I thought about memoizing the columns, but in the end at some point I must (at least partially) re-render the table, for filter visualization, displaying the loading spinner, and possibly more.
Any recommendation on how to handle this? Manually implement virtualizing? Precisely defining a memo comparator?
Basically out of ideas to fix this ...
EDIT: What do you think about offering some kind of row renderer or row memoization? When I e.g. set a filter and therefore implicitly change the column model I do not necessarily want to rerender any row.
To Reproduce
Steps to reproduce the behavior:
Render thousands of entries and e.g. use a filter input whereas the filter change re-renders the table (header).
Expected behavior
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
OS: macOS Sonoma 14.3
Browser: all
Version: latest
Additional context
The text was updated successfully, but these errors were encountered:
Describe the bug
First of all, I am aware of the fact that this table does not mean to implement any kind of virtualization (yet?), but by using e.g. 10.000 entries of data (in combination with filters or other components which might re-render) it is completely unresponsive and exhausts rendering time.
I actually think this might not be classified as a bug, but maybe you can give me a hint on how to handle this situation.
Given the following scenario:
I got a column filter which is any mantine input. I have to track the value (so control the component) because the requirement is to keep the state cross paged. Now, whenever I change the value, I have to update it in my state, whereas the server request is debounced for a few seconds. Due to the fact that the filter values changes (and therefore the column definitions because I might have to change the
filtering
property etc.) the whole table (including all 10.000 entries) re-renders on every key-up.I thought about memoizing the columns, but in the end at some point I must (at least partially) re-render the table, for filter visualization, displaying the loading spinner, and possibly more.
Any recommendation on how to handle this? Manually implement virtualizing? Precisely defining a memo comparator?
Basically out of ideas to fix this ...
EDIT: What do you think about offering some kind of row renderer or row memoization? When I e.g. set a filter and therefore implicitly change the column model I do not necessarily want to rerender any row.
To Reproduce
Steps to reproduce the behavior:
Render thousands of entries and e.g. use a filter input whereas the filter change re-renders the table (header).
Expected behavior
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Additional context
The text was updated successfully, but these errors were encountered: