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.
This PR includes some refactoring so it may not be immediately clear what changed - these are the functional changes:
1 and 2 are the bugs that caused issues in prod when it was released last week.
The lastUpdateTime was only being updated on aspect events, which caused the auto-reload to always trigger after the timeout period.
The timeout was being set based on all aspects that matched the perspective filters, which caused problems for perspectives with no filters - it was set to the minimum of all aspects in prod (6s), causing those perspectives to reload every 12s.
3 is a related bug I noticed while working on this. It didn't have an impact in prod last week as far as I know, but it does have the potential to cause issues and it's better not to track extra aspects unnecessarilly.
4 is a decision I made to simplify the code and wrap this up more quickly. I was running into lots of problems getting the updates working with the hierarchy-based approach, and I realized it really isn't worth the extra complexity. Instead, the timeouts will be set solely based on the data that was present on page load. Most of the time this should be exactly the same, and in the rare case that an update happens that would have changed the timeout, worst case is either the page reloads unnecessarily once, or if events stop coming in it doesn't reload as quickly as it possibly could. Not a big deal, and not worth the overly complicated tracking logic required to handle those cases.