OBPIH-6742 Performance: Virtualize table on receiving workflow#4935
Merged
awalkowiak merged 2 commits intodevelopfrom Nov 12, 2024
Merged
OBPIH-6742 Performance: Virtualize table on receiving workflow#4935awalkowiak merged 2 commits intodevelopfrom
awalkowiak merged 2 commits intodevelopfrom
Conversation
alannadolny
requested review from
awalkowiak,
drodzewicz,
ewaterman and
kchelstowski
github-actions
bot
added
the
domain: frontend
Member
|
thanks for the in-depth explanation! It definitely makes sense to want to reload rows one at a time instead of the whole table at once. Great job! |
ewaterman
approved these changes
Nov 12, 2024
awalkowiak
approved these changes
Nov 12, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
✨ Description of Change
Link to GitHub issue or Jira ticket: https://pihemr.atlassian.net/browse/OBPIH-6742
Description:
The virtualization in this workflow uses one container as one “row”. This means that if we have more containers the better the performance of this table will be. So, when we have everything under one container all lines will be loaded at once, so there won’t be any performance changes. That implies that in the worst case, there is no improvement, but in the best case there will be rather big improvement. As an additional thing - we should remember that the current implementation of our virtualized components is not ideal, so when we are scrolling a little bit faster we will see empty lines, but it will be loaded in a few milliseconds.
Reminder: performance issues in this workflow are caused by rendering too many DOM elements simultaneously (table renders too many rows). Phases of detecting changes in React look the following:
triggering phase - at this step React detects changes in states, so he knows that there is a probability for changes in displaying content. In our case, it is marking checkboxes, adding comments, etc.
rendering phase - at this step, React calls all of the nested components and checks whether any of the properties were changed, and then React applies them to the virtual DOM.
commit phase - at this step, React applies all of the required changes to the DOM using a minimal amount of operations.
To make the measures more relevant I measured the calculation times a few times and then I calculated the average time of the operations. All of the operations were triggered on a receiving page with 200 items. Everything is split between containers including from 1 item to 11 at max.
To compare the changes in rendering components I created a table: