granularclouds

Thank you - I know about ScrollSmoother but between not wishing to tie a feature for a site to a subscription package and also not wishing to work around the position: fixed limitation, for this project in particular I would go with Lenis. I tried a bunch of stuff and the performance is just not ideal, so I think I'll stick with ScrollTrigger and scrub and ditch the smoothing for non-animation things. Thanks!

Hello! I started working on a project in which I'm using both Lenis (ReactLenis) and Scrolltrigger on a different, slower machine and am noticing very poor framerates on scroll (whereas on the beefier machine, the scroll animations were fluid, fast). Commenting out ReactLenis restores performance. My question is: how to make scrolltrigger and lenis play nice in React/Next. This is not really a "help me achieve outcome X" in this sandbox/codepen question, moreso a higher-level, best practices "what is the right/recommended way to do Y" question For example, in the React Lenis docs, they suggest synchronizing Lenis and GSAP like this: function Component() { const lenisRef = useRef() useEffect(() => { function update(time) { lenisRef.current?.lenis?.raf(time * 1000) } gsap.ticker.add(update) return () => { gsap.ticker.remove(update) } }) return ( <ReactLenis ref={lenisRef} autoRaf={false}> { /* content */ } </ReactLenis> ) } While in their Next.js starter, synchronization appears to be spread across two files: this more scrollTrigger specific one; and this more generic GSAP one (in the combined setup featured these two files, there is no wrapping ReactLenis element, also). So, again. Just wondering if any GSAP people have a recommended/best practice approach for doing this. As I keep seeing different patterns. Totally fine if this question is ineligible because this isn't a Lenis Q&A board, but I feel like these two tools are used together enough that someone on here might have some clarity. Thanks!

I'll spin up a demo and post here tomorrow (EST here). I've only tested two browsers (Firefox and Brave) on a 2019 MBP, so nothing conclusive. But viewing the windows side by side, there definitely seems like a difference in frame-rate or smoothness. Not major, just a difference. In production, the element I'm aiming to animate in this manner is small enough that the judder is really not that discernible, also, so I'm happy either way.

(Sorry for the delay and...) thanks for the reply! That definitely works. I'm assuming there's no way to smooth out the animation - it's judders a little, like it's rotating on a step basis and not as smoothly as is the case in vanilla CSS, but all the same. Thanks.

I searched around for how to accomplish something like this, but I couldn't find anything even close, so I'm posting here in an attempt the community has an answer or can refer me to the right methods/techniques to use. Here's a very simple example of what I'm trying to accomplish, here in (S)CSS: https://codesandbox.io/s/condescending-monad-23udg?file=/src/App.js I have an element that's slowly rotating, and on hover of another element (or the parent container of both elements, it doesn't matter), I'd like the rotation to speed up and become quickly. Basically, I want to transition the transition, instead of - as is the case with CSS right now in my sandbox example - jumping from the 30s transition to the 10s transition. Any help would be greatly appreciated, thanks. Also, I've used GSAP plenty with React, so don't worry about fitting any solutions to my React template, I can do that myself - though it would of course be nice!

Thanks Rodrigo, I'll definitely look into Switch Transition. That indeed looks like the component I think I would need for this. Here is a sandbox with a framer motion implementation. Not an ideal demo of either, rather rough in fact, and the GSAP one is still broken - will have to dig into that switch RTG component later today.

Absolutely, would love to help.

Ah, sorry - must have typo'd at the last second before logging off last night. It's still not quite working - animations are happening sequentially. Even if I get rid of one or the other of the delay and duration in the exit function, the exiting and entering components are still on screen at the same time...

Thanks for the reply again! But I don't think that is making a difference - I understand what you are saying and I agree it makes sense, but the exit doesn't seem to be occurring until the enter is all the way complete. And no fade out. I'm pretty sure the code is exactly how you specified.

Sure! It's late so I don't have time to set up a sandbox for you to play around in - can quickly spin one up tomorrow, but below is the code I used: const variants = { enter: { opacity: 1, transition: { staggerChildren: 0.2, delayChildren: 0.1, }, }, exit: { opacity: 0, transition: { staggerChildren: 0.1, staggerDirection: -1, }, }, } ... <AnimatePresence exitBeforeEnter initial={false}> <motion.div variants={variants} initial="exit" animate="enter" exit="exit" className="AboutLinks__cards" key={category.uid} > {category.data.map((item, index) => { return ( <Card key={Object.values(item)[0].uid} prefix={category.uid} data={item} /> ) })} </motion.div> </AnimatePresence> The upside of framer motion is it's pretty much all declarative - everything set with props and objects. It's a pleasure to work with in React, but ultimately it's a lot more limited relative to GSAP, particularly for scroll-based functionality and anything SVG. Not as performant in my experience either. They're still building it though, and AnimateSharedLayout seems really cool - haven't used it for anything meaningful yet.

Thanks for the replies all. And thanks so much @Rodrigo - I was lost for a sec looking at your code because I've never rendered JSX like that - with the {() => {for(let x in y){... return z}}()} approach (interesting pattern to keep in my back pocket for other weird edge cases, thanks) - and while I am definitely curious if there's any possible way to get GSAP to work here using a more conventional map or similar, it definitely does work. Or at least for the enter animation - sandbox. Exit animation doesn't seem to be working. Am I missing something obvious? No sweat if the fix is laborious at all. I'd ideally like to stick with only one animation library going forward but I might have stumbled upon the sole case I've come across so far where framer motion looks like the way to go. Thanks again!

I'm in the process of converting a project from framer-motion to gsap owing to how much more powerful and performant the latter is ?. I'm getting snagged on one area that is giving me a lot more trouble trying to pull off with gsap, though, unless I'm missing something very obvious. Here is a sandbox. What I'm trying to accomplish is to get a proper stagger working, on enter and exit whenever I change selection via the radio buttons. So that - on exit - the first of the two cards fades on, followed by the second, and then - on enter of the newly selected set of cards - the first new card fades in, followed by the second. I haven't found any such example detailing how one might accomplish this stagger-out/stagger-in action. Any help would be super appreciated - thanks!

Interesting, thanks so much @akapowl. Idiosyncrasies and a variety of ways of accomplishing similar things is very often the sign of a potent tool, even if that results in some pitfalls and challenges while getting going (Framer Motion, for example, is significantly easier for me to grasp and utilize without practically any confusion, but it's quite limited, which is largely why I've landed here). Still definitely struggling to understand scrollTrigger. Hope it comes naturally by just messing around with it over time...

Hm. Spoke too soon, or partially. Is there any way of achieving this without explicitly setting the height in CSS? In real world projects - particularly for clients where they have control over the content of pages - how can I proceed with this effect in situations where I can't explicitly say "height: 500vh"?

Thanks for the example, @TomSES! I'm wondering if there is a consensus on whether handling these cases as you did, similar to the approach shown in this sandbox (where it doesn't appear as though the focal element is unmounted upon disappearing - but only made invisible), or if it might be better to mount and unmount, and animate these two actions with... the help of React Transition Group, right? I guess it's not that big of a deal when it's maybe just one element or something not at all computationally intensive. But I'm still trying to wrap my head around best practices in GSAP x React, coming from some of the more React-centric animation libraries like Framer Motion etc, where you would definitely opt to animate mounting and unmounting, not just hiding. And I'm not missing something very obvious, right? If you want to animate mounting and unmounting with GSAP in React you'd have to reach for React Transition Group?