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
For larger lists and/or situations, where often a long list of patches results from the diff of two consecutive versions of the lists, it might be a good idea to
batch all patches in a list when diffing
copy the mount-point node
apply all patches to the (invisible) copy
switch original mount-point-node and copy
This should improve rendering performance, avoid flickering when for example sorting a huge table, and make sure that animations on single elements all start at the same time (when the copy is mounted to the dom).
For small lists or lists that only result in very few patches between two versions, this might add some unnecessary overhead, so we would either accept this or find a way to make this behavior controllable over the api.
The text was updated successfully, but these errors were encountered:
As we already have four parameters for renderEach we must be careful to add another one.
Probably it makes more sense to encapsulate this behavior into the function name (renderBatch, renderEachBatched or alike).
We should first consider to try to measure whether we need two behavior variants, or we can stick only to the proposed one. This would be the best solution, as the user must not make any design decisions upfront.
For larger lists and/or situations, where often a long list of patches results from the diff of two consecutive versions of the lists, it might be a good idea to
This should improve rendering performance, avoid flickering when for example sorting a huge table, and make sure that animations on single elements all start at the same time (when the copy is mounted to the dom).
For small lists or lists that only result in very few patches between two versions, this might add some unnecessary overhead, so we would either accept this or find a way to make this behavior controllable over the api.
The text was updated successfully, but these errors were encountered: