Jump to content
Search Community

Class for triggering GSAP animations on scroll

jesper.landberg test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi I made this little class, I have had npm/webpack issues with ScrollMagic, and felt it was a bit overkill for my needs, so I made this little class now. Would be nice with some feedback, how it could be improved and so on. Maybe more general JS related than GSAP related, but since I'm only using GSAP and trying to make the class around GSAP it would be nice with ur feedback.

See the Pen GBWqRz?editors=0010 by ReGGae (@ReGGae) on CodePen

Link to comment
Share on other sites

Looks good!

 

You can do this instead of using bind if you're using Babel or TypeScript. I think it's cleaner, and it should technically run faster.

 

class ScrollAnimations {

  constructor() {
    
    // 'this' will work without the use of bind
    this.el.addEventListener('scroll', this.onScroll, false)
    this.rAF = requestAnimationFrame(this.run)
  }
  
  onScroll = () => {
    ...
  }  
  
  run = () => {
    ...
  }
}

 

 

And here's a simple of example of how you can use the scroll position with a timeline.

 

See the Pen a633d0c9e6e2b951496d7f1eb4fd8fb6 by osublake (@osublake) on CodePen

 

 

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Great example as always @OSUblake .

 

I was wondering about one aspect of it, let me know if I'm understanding it correctly.

 

if (!requestId){...} is throttling the animation of the tl's playhead to only execute when the browser is ready to paint a new frame so the scroll event listener doesn't fire the function too frequently?

  • Like 1
Link to comment
Share on other sites

11 hours ago, Visual-Q said:

if (!requestId){...} is throttling the animation of the tl's playhead to only execute when the browser is ready to paint a new frame so the scroll event listener doesn't fire the function too frequently?

 

Correct. The browser calls requestAnimationFrame right before it's about to paint, so responding to the event before that is almost always pointless as it could get called again. I know Chrome tries to optimize events so that they fire right before the animation frame gets called, but that's Chrome. And then you have Safari and Edge which actually call requestAnimationFrame at the wrong time, but that probably won't be an issue as long as you're not manually updating element styles.

 

Edge says it's fixed, but it hasn't shipped.

https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/15469349/

https://bugs.webkit.org/show_bug.cgi?id=177484

 

 

  • Like 5
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...