You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When utilizing the LazyMotion component, there's a scenario where the visualElement might not be immediately available for the animation controls. In the original animationControls code, animations get started without ensuring the presence of any subscribed visualElement, potentially causing missed animations.
Steps to reproduce:
Integrate the LazyMotion component into a project.
Use m-Components.
Call controls.start() before the visualElement has subscribed - in the effect.
Observe that animations may be skipped or missed.
Lazy-Load.ts
export { domAnimation as default } from 'framer-motion';
import { m, LazyMotion, useAnimation, useMotionValue } from 'framer-motion';
import { FC, useEffect } from 'react';
// only way to keep bundle size small
const loadFeaturesAsync = async () =>
await import('./Lazy-Load').then(res => res.default);
// it works when features are loaded synchronously like, but bundle size increases
// import { domAnimation } from 'framer-motion';
// <LazyMotion features={domAnimation}>
export const AnimationTest: FC = () => {
const controls = useAnimation();
const variants = {
foo: { x: 100 }
};
const childVariants = {
foo: { backgroundColor: '#fff' }
};
const x = useMotionValue(0);
const backgroundColor = useMotionValue('#000');
useEffect(() => {
controls.start('foo').then(() => {
console.log('variants result: ', [x.get(), backgroundColor.get()]);
});
}, []);
return (
<LazyMotion features={loadFeaturesAsync}>
<m.div
animate={controls}
variants={variants}
style={{ x }}
onAnimationStart={() => {
console.log('onAnimationStart outer');
}}
onAnimationComplete={() => {
console.log('onAnimationComplete outer');
}}
>
<m.div
variants={childVariants}
style={{ backgroundColor }}
onAnimationStart={() => {
console.log('onAnimationStart inner');
}}
onAnimationComplete={() => {
console.log('onAnimationComplete inner');
}}
>
Hello
</m.div>
</m.div>
</LazyMotion>
);
};
What's changed?
This pull request introduces changes to the animationControls function to handle scenarios where the visualElement might not immediately subscribe, especially in the context of the LazyMotion component.
Introduced Start Queue: An array that temporarily holds animation start calls. This ensures animations are deferred until their respective visual elements have subscribed to the animation controller.
Flush Mechanism: Once a visualElement subscribes, any queued animations are immediately processed and played.
Error Handling: Added robust error handling to cater to potential issues during the animation process. This ensures promises are either resolved upon successful completion or rejected in case of errors.
Benefits:
This change ensures animations are consistently played in scenarios involving delayed visualElement subscriptions, enhancing user experience and ensuring predictable behavior.
How to test:
Integrate the LazyMotion component, described in framer#2292
- Integrate the LazyMotion component into a project.
- Import features dynamically to keep bundle size small.
- Use m-Components.
- Call controls.start() before the visualElement has subscribed - in the effect.
Ensure that animations play consistently, irrespective of when the controls.start() is called in relation to the visualElement subscription.
Because useAnimation is deprecated in favour of useAnimate I'm probably not going to have the time to fix this so closing as wontfix to set expectations
When utilizing the LazyMotion component, there's a scenario where the visualElement might not be immediately available for the animation controls. In the original animationControls code, animations get started without ensuring the presence of any subscribed visualElement, potentially causing missed animations.
Steps to reproduce:
Here is the sandbox https://codesandbox.io/p/sandbox/polished-sunset-pg25zr
Expected Behavior:
Animations should always be played regardless of when the visualElement subscribes.
Actual Behavior:
Animations might be skipped if started before the visualElement subscription.
Suggested Fix:
Improve animationControls to queue animation start calls and processes them once the visual element is available, see referenced PR
The text was updated successfully, but these errors were encountered: