fix(trees): sync tree conformation with URL cache#8263
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
📝 WalkthroughWalkthroughTreeView now hydrates conformation from the URL on first render, otherwise from cache, and only syncs later changes back to the URL. Cache storage-event handling now updates in-memory state without writing the same value back to localStorage. ChangesConformation sync and cache write suppression
Unassigned formatting/test-only changes
Sequence Diagram(s)sequenceDiagram
participant TabA
participant LocalStorage
participant TabB
TabA->>LocalStorage: setItem(cacheKey, value)
LocalStorage->>TabB: storage event
TabB->>TabB: genericSet(triggerChange=true, skipStorageWrite=true)
TabB->>TabB: update in-memory cache, trigger change event
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Warning One or more dependencies are approaching or past End-of-Life. |
Triggered by d0835b3 on branch refs/heads/issue-8262
lexiclevenger
left a comment
There was a problem hiding this comment.
Testing instructions
- Test in both
mainand in this branch, following the steps to recreate in #8262
Looks good!
Fixes #8262
Note
More DeepSeek suggestions 🤖. This has been quite thoroughly tested and I made adjustments, however they were minor.
The tree viewer was writing its expanded/collapsed state to browser local storage at render-cycle frequency (over 30 times per 500 milliseconds). Each write to
localStorageis synchronous and blocks Chrome's main thread. Since it gets to 60 writes per second + cascading React re-renders memory usage climbs until the browser tab becomes unresponsive. I experienced a kernel panic once and had my system become so unresponsive I couldn't even kill the browser. Theoretically multiple tabs amplified the effect exponentially as each tab echoes state changes to every other tab.Two big issues:
setConformationcall triggered writes to both, and effects from childTreeRowcomponents cascaded multiple writes per user click.storageevent arrived from another tab, the handler wrote the value back tolocalStorage, firing anotherstorageevent in the originating tab, creating a ping-pong echo.Solution
no_more_looping.mp4
Checklist
self-explanatory (or properly documented)
Testing instructions
mainand in this branch, following the steps to recreate in Syncing node selection causes runaway memory usage and browser unresponsiveness #8262Summary by CodeRabbit