Closed ZipBrandon closed 2 days ago
Thanks - we'll keep an eye on the situation but we're not going to spend any time on fixing issues in canaries/betas as the bugs are more potentially on their side
I understand. I do want to link https://github.com/radix-ui/primitives/pull/2811 since the ref did come to play over there.
React 19 has a blog post yesterday: react 19 enters beta.
This beta release is for libraries to prepare for React 19.
As React 19 is now officially in RC, framer motion's compatibility would be crucial for beginning the gradual migration to v19.
Many hobby devs rely on Framer Motion, and they're the early adopters who start the migration beginning today, helping smoothen the rough edges. Love framer motion and can't imagine dropping it to use react compiler, please consider giving some love to this issue.
Closed in favour of https://github.com/framer/motion/issues/2668
@avarayr I have started looking into it but at first glance it seems like a serious amount of work. It breaks almost every aspect of this repo. Because of the types situation I'm also fairly sure there's no way of doing it without breaking 18 backwards compatible but we'll see.
Given we're on 18 within Framer and will be for some time, I do have a number of things to do before I can back to this.
1. Read the FAQs 👇
2. Describe the bug
Elements won't animate off their
initial
props since 19.0.0-canary-7a2609eed-20240403.19.0.0-canary-48ec17b86-20240402 does work.
3. IMPORTANT: Provide a CodeSandbox reproduction of the bug
https://github.com/ZipBrandon/framer-motion-initial-bug
4. Steps to reproduce
Steps to reproduce the behavior:
git clone https://github.com/ZipBrandon/framer-motion-initial-bug && cd framer-motion-initial-bug && npm i && npm run dev
5. Expected behavior
Animations to work.