fix: Prevent scaling during component initialization #627
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.
Summary
This PR fixes issue #626 where cropping and zooming sometimes doesn't work when the component is rendered inside animated modals.
Problem
The issue was introduced in PR #623 (v5.5.2) when the
applyCanonicalapproach was replaced with a new scaling mechanism usingpreviousCropSize. The scaling logic inrecomputeCropPositionwould run during component initialization/mount, causing incorrect crop positioning especially when:previousCropSizehasn't been properly initialized yetThis resulted in the crop area being positioned incorrectly, sometimes making interactions non-functional.
Solution
Added an
isInitializedflag that prevents the scaling logic from running until the component is fully initialized viaonMediaLoad. The changes:isInitializedflag - Tracks whether the component has completed initializationonMediaLoad- SetspreviousCropSizeandisInitialized = truewhen media loadsrecomputeCropPosition- Only applies scaling whenisInitialized && previousCropSizeexistThis ensures the scaling logic only runs during legitimate window resize events, not during the initial mount sequence.
Additional Changes
Reverted the unnecessary
windowResizeHandlerwrapper that was introduced in #623, as it's no longer needed.The fix would benefit from validation by @TobiTRy (the original reporter) with their specific use case.
Fixes #626