[BUG] - AnimatePresence enter/exit tracking broken inside React.StrictMode

[acd02]

1. Describe the bug
When using AnimatePresence inside React.StrictMode, animations behave non-deterministically in development. Components that persist across a dataset change (i.e. they exist in both the before and after state) may disappear and reappear instead of animating, and their initial values are re-applied as if they are freshly entering. The behavior is inconsistent, it can work on one render and break on the next page refresh.

This appears to be caused by StrictMode's double-mount behavior in development, which confuses AnimatePresence's internal enter/exit tracking.

removing StrictMode fixes the issue ✅

There may be no workaround, and that wouldn't be the end of the world since ⁠StrictMode checks only run in dev, or perhaps my code isn't following best practices?

2. Steps to reproduce

1. Open the CodeSandbox
2. Click Switch dataset (observe the red bar translating on its Y axis)
3. Wait for the transition to complete
4. Click Switch dataset again , observe the red bar: instead of translating on Y, it disappears and reappears in its new position, and its width animates from 0

3. Expected behavior
Components whose key exists in both the previous and new dataset should animate their changed props.Only components whose key is genuinely new should play their enter animation.

4. Video or screenshots*
expected: ✅
Video below is without StrictMode

current: ❌
Video below uses ⁠StrictMode. The issue can be observed when clicking on Switch dataset for the 2nd time.

7. Environment details

• motion: 12.40.0
• react: 19.2.4
• react-dom: 19.2.4

[pupuking723]

I'd like to work on this. I'll first reproduce the StrictMode-specific behavior and check whether AnimatePresence is treating persisted keys as fresh enters during the dev double-mount cycle. If the root cause is narrow enough, I'll come back with a focused fix and regression coverage before opening a PR.

[acd02]

Hey @mattgperry, I noticed you opened a PR fixing this issue a couple of days after I created it.
But it seems to have gone stale since then, is that intentional? Don't want to be pushy or anything, just curious.

[mattgperry]

This is just more to do with putting patches through and reviewing them as separate tasks, either in “fix” brain mode or “review”, also means I can release quicker overall. Nothing instrinsic about that fix just I have a list of other priorities before getting back to reviewing these PRs

…

On Mon, 13 Jul 2026 at 17:14, acd ***@***.***> wrote: *acd02* left a comment (motiondivision/motion#3746) <#3746 (comment)> Hey @mattgperry <https://github.com/mattgperry>, I noticed you opened a PR fixing this issue a couple of days after I created it. But it seems to have gone stale since then, is that intentional? Don't want to be pushy or anything, just curious. — Reply to this email directly, view it on GitHub <#3746?email_source=notifications&email_token=AB34WKRJL4FMHUAOFFCJUR35ET4ENA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVHE2DSNBRGM32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4959494137>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB34WKRW42542TXGB2JLUID5ET4ENAVCNFSNUABFKJSXA33TNF2G64TZHMYTKNZYGQ3DQNZWHNEXG43VMU5TINRRGQ4DMNBQGI4KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AB34WKRSCV4CSNV4RX5F34L5ET4ENA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVHE2DSNBRGM32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AB34WKVBPZTXTB3GD4RVSJ35ET4ENA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJVHE2DSNBRGM32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>