Jump to content
Search Community

ScrollTrigger, stagger, and infinite scroll

NickWoodward test
Moderator Tag

Recommended Posts

So I've tried to make a codepen that staggers in the first visible items on screen, and then when you get to the bottom of the page it continues to animate in the new elements added to the DOM.

Initially I tried to use ScrollTrigger without the `batch` method, clearing the timeline and replaying it when new elements were added - with a bit of success, but it was janky (I've left the code in for your entertainment 😄). Anyway, it seems to work well using ScrollTrigger.batch, but I just wanted to check that this looks like a sensible approach, and I've not created any memory problems? The separate timeline onload isn't really necessary now I guess, but I've left it so that I can do a different initial animation.

TLDR: I guess I'm just looking for a bit of validation on my animation, as I don't really know what I'm doing!


Thanks!

Nick

 

See the Pen jOLgXqm?editors=0011 by nwoodward (@nwoodward) on CodePen

Link to comment
Share on other sites

Hello there Nick!

 

I haven't played around with scrollTrigger.batch() much so this was fun to look into. There's nothing glaringly wrong at all, but it could maybe be reduced down a little? 

The first thing I noticed is that you were doing calculations yourself to figure out scroll position - isAtBottom() - If you're using scrollTrigger already it makes sense to let scrollTrigger handle that! The initial animation could be handled with batch to avoid writing the same code twice too.

Here's how I'd approach it - using scrollTrigger to detect whether you're at the end of the page and if so create new elements. 

 

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



I'm not certain whether you should be killing previous scrollTriggers or not. Maybe someone else can jump in there?

Hope this helps, it certainly helped me understand batching a bit better ✨

  • Like 2
Link to comment
Share on other sites

8 hours ago, Cassie said:

I'm not certain whether you should be killing previous scrollTriggers or not. Maybe someone else can jump in there?

No need since you've got once: true (that'll kill them automatically once they fire the first time). 

 

I'd recommend setting the initial state with a .set() and then using a .to() in the onEnter in order to avoid the flash that could happen if you scroll quickly and the .from() hasn't rendered its initial state yet. And you could simplify the ScrollTrigger that senses the end of the scroll too: 

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

  • Like 4
Link to comment
Share on other sites

On 11/27/2021 at 10:41 PM, Cassie said:

The first thing I noticed is that you were doing calculations yourself to figure out scroll position - isAtBottom() - If you're using scrollTrigger already it makes sense to let scrollTrigger handle that! The initial animation could be handled with batch to avoid writing the same code twice too.

Ah - a hang over from when I wasn't using ScrollTrigger at all  - But yeah I probably wouldn't have thought to change it, so thanks! Also didn't know I'd have to call `refresh()` - nice to see it in an example of mine, makes it less likely I'll forget it in 30 seconds time!

 

On 11/27/2021 at 10:41 PM, Cassie said:

Hope this helps, it certainly helped me understand batching a bit better

No worries, if it helps I can make more threads 😄
 

On 11/28/2021 at 6:59 AM, GreenSock said:

No need since you've got once: true (that'll kill them automatically once they fire the first time). 

 

I'd recommend setting the initial state with a .set() and then using a .to() in the onEnter in order to avoid the flash that could happen if you scroll quickly and the .from() hasn't rendered its initial state yet. And you could simplify the ScrollTrigger that senses the end of the scroll too: 

Perfect, thanks!

Out of interest, are you able to leave out the trigger option from the scrolltrigger instance because it defaults to `document.body`, or is there some other reason?

Also, if you don't mind, is there a general rule on when it's a good idea to kill animations? I have to admit I don't think I give anywhere near enough thought to it...

Link to comment
Share on other sites

5 minutes ago, NickWoodward said:

Out of interest, are you able to leave out the trigger option from the scrolltrigger instance because it defaults to `document.body`, or is there some other reason?

A trigger isn't really needed - that's only if you're defining "start" or "end" values that are non-numeric. In other words, if they're relative to an element but in our case we have no such thing. 

 

7 minutes ago, NickWoodward said:

is there a general rule on when it's a good idea to kill animations?

GSAP automatically takes care of releasing things for garbage collection internally - you typically don't need to do anything special. Just .kill() an animation if you need to nuke it, like if it's in the middle of animating and you want it to stop doing anything and go away permanently. That's relatively uncommon. 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...