fix(Synchronizer): actually remove event listener on source removal#2772
Conversation
Signed-off-by: Hodossy, Szabolcs <szabolcs.hodossy@clario.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthrough
ChangesSynchronizer event listener lifecycle
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/tools/src/store/SynchronizerManager/Synchronizer.ts`:
- Around line 138-140: The auxiliary event teardown in Synchronizer should
mirror the attach default: addSource treats a missing source as 'element', but
removeSource currently detaches from eventTarget for { name } entries, leaving
listeners behind and causing duplicates. Update the remove logic in Synchronizer
so the same default source resolution is used for both attach and detach,
reusing the existing auxiliary event handling in _auxiliaryEvents and the
addSource/removeSource paths.
In `@packages/tools/test/synchronizer_test.js`:
- Around line 26-30: The afterEach cleanup in synchronizer_test.js is missing
the synchronizer identifier, so the created axialSync instance is not destroyed
and can leak global state between tests. Update each cleanupTestEnvironment call
inside the affected afterEach blocks to pass the same synchronizerId used when
creating the synchronizer, alongside renderingEngineId, and apply the same
change to the other cleanup block mentioned in the test file.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: baa67a06-ed97-41dd-b7e4-2717368f16b9
📒 Files selected for processing (2)
packages/tools/src/store/SynchronizerManager/Synchronizer.tspackages/tools/test/synchronizer_test.js
Signed-off-by: Hodossy, Szabolcs <szabolcs.hodossy@clario.com>
Signed-off-by: Hodossy, Szabolcs <szabolcs.hodossy@clario.com>
Context
Synchronizerimplementation adds the event listener with a.bind()call, effectively creating an anonymus function. When it tries to remove it, it uses a different function, resulting in a stale event listener on the element. We are using theSynchronizerto sync invert state across viewports, and sometimes enable/disable elements in the workflow. When we disable a viewport, we remove it from all synchronizers, and when we enable it, we add it back. This resulted in a state, where after odd number of disable/enable cycles we had an even number of event listeners (with the initial enablement), therefore invert is not working, as target viewports get inverted an even number of times (e.g. after one such cycle on source viewport, target viewport got inverted twice, thus nothing changed).Changes & Results
Synchronizernow has an_eventListenerproperty referencing the event listener to add/removeTesting
You can reset
Synchronizer.tstomain, and run my test to validate that the event listener was actually called twice. Apply my changes again, and see the test pass.Checklist
PR
semantic-release format and guidelines.
Code
etc.)
Public Documentation Updates
additions or removals.
Tested Environment
Summary by CodeRabbit