GreenSock

Yes, that's exactly what I was saying. Any selector text used in GSAP-related stuff created while the useGSAP() hook function is executing will be locked to that scope. So it's fine if it's in external functions as long as those are called while that useGSAP() hook function is executing. 

Yeah, the "target" is telling it which element's scroll to normalize. Typically that's the document.scrollingElement (body or html). So yeah, if you target a sub-element, it just normalizes that. 
 
Yes, that was intentional because I honestly didn't think anyone would ever need this feature but I baked it in anyway just in case, but I didn't document it because I wanted to see if anyone would ever even need it. If enough time went by and nobody did, we could consider safely removing it. 🙂
 
Glad it's fixed now!

By default, scrubbed animations will render immediately. So in this case, it's getting that animation ready by putting it in its starting state which has the element at full opacity. You can force it to not render immediately by setting immediateRender: false on your ScrollTrigger: 

See the Pen qBwbgRM?editors=0010 by GreenSock (@GreenSock) on CodePen
 
Also, you can greatly simplify a lot of that code. All you need is two tweens each with a ScrollTrigger. And by the way, there are convenience methods directly on timelines to simplify this: 
// long tlOut.add(gsap.fromTo('.elt', { opacity: 1 }, { opacity: 0 })) // shorter tlOut.fromTo('.elt', { opacity: 1 }, { opacity: 0 })  
I hope that helps. 

Yeah, that's because the position is affected only after the playhead isn't at 0. So for example, if you reverse the tween and the playhead goes all the way back to the very beginning and beyond, the element would go back to the original position (before the motionPath tween affected it). 
 
You can easily work around that like this: 

See the Pen ZEZQQpQ?editors=0010 by GreenSock (@GreenSock) on CodePen
 
Just use an onRefresh to force the playhead  to be slightly past the very start if it's at 0. And I set invalidateOnRefresh so that the path gets re-calculated since resizing the window would make the SVG change size.
 
Is that better? 

It seems like it's doing exactly what it should according to the code, but I don't think you need a timeline for that - why not use a recursive function?: 

See the Pen gOyYKro?editors=0010 by GreenSock (@GreenSock) on CodePen

Short answer: Just force the playhead to the end and then back to the beginning like this: 
tl.progress(1).progress(0); That basically pre-renders everything. 
 
The problem was that you're doing a stagger on a from() tween, thus technically the start of the sub-tweens are offset and you're seeing those start in a staggered fashion. GSDevTools employs a trick to force the playhead to the end as an optimization. 

Hi @Ken Flores. Seamless loops are actually a lot more tricky than you might expect logic-wise (unrelated to GSAP). That's why we made a helper function for that:
https://gsap.com/docs/v3/HelperFunctions/helpers/seamlessLoop
 
Here's what I think you were trying to do, but this is much more efficient: 

See the Pen XWQmoMp?editors=0010 by GreenSock (@GreenSock) on CodePen
 
Does that help?
 
Thanks for being a Club GSAP member! 💚

I'm no React expert (maybe @Rodrigo will have some suggestions), but I noticed two minor things: 
 
You're putting a stagger on a tween that's only has one target, so it's pointless:  delay: 0.7 + index * 0.1, stagger: 0.1, // pointless. There's only one target You could simplify that whole thing: 
// BEFORE (long) iconsRef.current.forEach((icon, index) => { const isInProject = projectTechnologies[activeProject]?.includes(index); gsap.fromTo( icon, { opacity: 0, scale: 0.8, }, { opacity: 1, scale: isInProject ? 1.05 : 0.8, delay: 0.7 + index * 0.1, stagger: 0.1, } ); }); // AFTER (short) gsap.fromTo(iconsRef.current, { opacity: 0, scale: 0.8, }, { opacity: 1, scale: i => projectTechnologies[activeProject]?.includes(i) ? 1.05 : 0.8, delay: 0.7, stagger: 0.1 });  
I don't understand why you're animating to the CURRENT scale/filter values in this tween (what's the point?). Plus you could simplify it all into a very simple tween:  // BEFORE iconsRef.current.forEach((icon, index) => { const currentScale = gsap.getProperty(icon, 'scale'); const currentFilter = gsap.getProperty(icon, 'filter'); gsap.to(icon, { scale: currentScale, filter: currentFilter, opacity: 0, delay: 0, onComplete: () => { if (index === iconsRef.current.length - 1) { handleFadeIn(); } }, }); }); // AFTER gsap.to(iconsRef.current, { opacity: 0, onComplete: handleFadeIn });  

Yeah, without a minimal demo we can't do much to help, but I also noticed that you're using class="" instead of className="" in your JSX. I'm pretty sure React/JSX requires className instead of class. 
 
Is this basically what you're trying to do?:
https://stackblitz.com/edit/stackblitz-starters-npxpxa?file=app%2Fpage.tsx
 
Seems to work fine, no? 

Here's an approach you could take that's pretty performant: 

See the Pen dyLozYj by GreenSock (@GreenSock) on CodePen

Yeah, quickTo() doesn't have conveniences like unit conversion, and you're trying to do a percentage-based thing here but you can sorta hack that like this: 

See the Pen RwOPxdb by GreenSock (@GreenSock) on CodePen
 
Internally, a gsap.quickTo() is just a convenient way to access a tween's .resetTo() functionality. So I forced the percent unit into the paused tween. The key is that gsap.quickTo() and tween.resetTo() are ways to feed a raw number directly into the slot inside the already-created tween that's animating that value. Again, it's highly optimized, hence skipping the conveniences like unit conversion, property aliases, etc. 
 
Does that give you what you were looking for? 

Yeah, here's an example that animates the scaleX, scaleY, and opacity: 

See the Pen rNbaXMG?editors=1010 by GreenSock (@GreenSock) on CodePen
 
I hope that helps.

I noticed quite a few problems: 
You were trying to select the elements before the component rendered which means there will be no results: let sections = document.querySelectorAll(".overlaySection"); You need to select stuff inside the useGSAP() hook because that's called after the component renders. This is all just React stuff, unrelated to GSAP. 
There was no reason to even create a timeline or tl variable.  You were referencing window.width and window.height which aren't things. I think you meant window.innerWidth and window.innerHeight You didn't define an "end" for your ScrollTriggers. I think you wanted "max" You were trying to pin an element that's INSIDE of a pinned element which you cannot do. The way you set things up makes it very tricky. The child component actually needs to pin the parent element and since React renders in reverse order (children first), it isn't even available to define as the pin, thus you'll need to find a different way to pass that data up the chain and create the ScrollTrigger when the parent renders. You were creating ScrollTriggers in the wrong order and you didn't set a refreshPriority. It's very important that things get refreshed in the order that they appear on the page because pinned elements further up on the page can push things further down the page, affecting the start/end values of ones below.  You don't need to pin the final element. You didn't have position: relative set, so the browser won't render the final element in front of the others that were translated. This is a CSS thing, unrelated to GSAP.  Much of this stuff is purely about React (and I'm no React expert), but I created a pull request for you with some changes that'll hopefully get you on your way. Normally we don't do this kind of thing (it's a lot of custom logic and fixes), but I wanted to help and I had a little time:
 
https://github.com/Mika-Otter/GSAP-Helper/pull/1

I'm not sure what you mean by "not smooth scroll", but the problem with the snap position in your demo was that you didn't set ease: "none" on your animation, thus there was move movement at the beginning than the end due to "power1.out" being the default ease. And I'd strongly recommend using the useGSAP() hook for React: 
https://stackblitz.com/edit/gsap-react-basic-f48716-e9uf9f?file=src%2FApp.js
 
Hopefully that gets you going in the right direction. 

Welcome to the forums, @Arkaprava101
 
Is this what you're trying to do?:

See the Pen VwNYLXP by GreenSock (@GreenSock) on CodePen

Yeah, that'd only happen if you've got a "style" property on the targets and the properties that you're animating are transform-related (like x, y, etc.). I've made a tweak to the core that should resolve that. You can preview it here: 
https://assets.codepen.io/16327/gsap-latest-beta.min.js (you might need to clear your cache)
 
Better? 

Flip might be very helpful, but you weren't calculating things properly in your demo - here's what I assume you were trying to do(?): 

See the Pen zYXYYKz?editors=0010 by GreenSock (@GreenSock) on CodePen

That's the very old syntax - honestly, the Params stuff is not necessary at all. Your intuition was correct - just do this:
onUpdate() {     syncOpacity(this, ".box2"); }
See the Pen poBzVxO?editors=1010 by GreenSock (@GreenSock) on CodePen
 
There's no practical reason why you'd need to use params - that's more of a relic from the past that'll likely get dropped in a future major release (not anytime soon). 
 
Does that help?

It looks to me like it's working as expected. Why are you setting autoRemoveChildren: true anyway? 
 
Let's say you've got a 1-second tween in a timeline with autoRemoveChildren: true and then you do a setTimeout() so that 1 second later, you add more tweens to that timeline. Well at that point the first tween has completed and been REMOVED, thus the duration of that timeline is 0, so you add new stuff in there but the startTime of that timeline was 1 second ago (meaning the global playhead would be 1 second past the start of that timeline), so when you add a new 1-second tween into that timeline, it'd simply render at its very end because the new timeline's duration expanded out to 1 second, but the global timeline playhead is already at the end of that. Of course you could simply call restart() on that timeline if you want it to adjust its startTime such that its very start is wherever the global timeline's playhead currently is. 

Hi @gaggo Yeah, I apologize but I don't really know what the issue could possibly be with pnpm or how to resolve it. Our private repo expert has said that yarn itself also has some bugs related to private repositories that they haven't fixed in a long time. Unfortunately we don't have control over yarn or pnpm. I really wish I had a great answer for you. 🤷‍♂️ If anyone has suggestions, we're all ears of course. 
 
Thanks for being a Club GSAP member! 💚

Nah, it's very doubtful that having multiple ScrollTriggers would cause an issue. 
 
Are you absolutely positive you're using the latest version of GSAP/ScrollTrigger on the site? 
 
We can't really troubleshoot Lenis-related stuff because that's not a GreenSock product (ours is ScrollSmoother). 
 
I wonder if the jitter is due to some kind of filter effects you're using (some filters are extremely CPU-intensive for rendering which is totally unrelated to GSAP)

You had a typo: 
// bad start: 'bottm bottom' // good start: 'bottom bottom' You also were loading the GSAP/ScrollTrigger/React files from the CDN as UMD files **AND** importing them as ES Modules which you definitely shouldn't do. That's a bunch of redundancies. You also were defining "class" attributes in JSX which is invalid - you've gotta use className. That has nothing to do with GSAP; it's a React thing. 
 
And you can round the values with snap: 

See the Pen abMryMW?editors=0010 by GreenSock (@GreenSock) on CodePen
 
Does that help? 

I noticed several issues: 
You're not doing proper cleanup. Every time you change the text, you're creating an entirely new animation and ScrollTrigger, and all the old ones are sticking around. So you end up with more and more and more that are all trying to operate on the same elements.  It looks like you're using a setTimeout() to work around the fact that React doesn't immediately apply the changes when you setText(). If you're trying to run an animation when that text changes, you should do it the proper way in React which is to set up an effect with that text as a dependency (this is totally unrelated to GSAP, FYI).  You appear to be hard-coding onEnter/EnterBack/onLeaveBack callbacks on your ScrollTrigger to do exactly what you can do more easily with toggleActions.  // old onLeave: () => tl.reverse(), onEnterBack: () => tl.play(), onLeaveBack: () => tl.reverse() // new toggleActions: "none reverse play reverse"  
There seem to be logic issues - I don't really understand what you're expecting to happen. Here's my best guess at what you're trying to do: 
https://stackblitz.com/edit/stackblitz-starters-8ab6xd?description=React TypeScript starter project&file=src%2FApp.tsx&title=React Starter

You had the scroller set incorrectly and I'm not really sure how you wanted the effect to work, but maybe this will get you going in the right direction: 
 

See the Pen KKEYKOj by GreenSock (@GreenSock) on CodePen

The SVG spec itself does not support 3D properties. You can't reliably animate rotateY() across browsers. It's not a GSAP thing, it's a browser/spec thing. You could probably simulate it by animating scaleX instead (which can go negative). 

See the Pen ZEPVqem?editors=0010 by GreenSock (@GreenSock) on CodePen