Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Andell

stagger not working insde a forEach loop

Recommended Posts

Without the forEach loop, the blue and red boxes with the same class are staggered correctly.


However I have the use case where I have multiple box wrappers on a page containing images with the same classes: Therefore I need to put them into an array using gsap.utils.toArray and doing a forEach on them. However inside this forEach, the stagger does not work, and both boxes are translated along the y axis simultaneously.
See second code pen

See the Pen poNjvNq by Andell (@Andell) on CodePen



Can anyone please shed some light on this?

See the Pen JjbYodo by Andell (@Andell) on CodePen

Link to post
Share on other sites

If you put a `forEach` around them you break them a part and then only have one item to stagger and because both boxes start at the same place they animate at the same time.

 

You are telling that you have multiple [red][blue] boxes on a page? This doesn't show in your demo. But what I would do than is add a container around these boxes and add the trigger on the container [.container [red][blue] ] and then stagger the `.image__box-200` whiten your animation 

  • Like 3
Link to post
Share on other sites

Hello mvaneigen
First of all, thank you for your reply. It is making think of new solutions.


Sorry if my explanation was not thorough enough here is a bit more explanation.
So this code pen is a simplified version of the real problem of course. Think of the [red][blue] squares with a class of `.image__box-200` as one component, in which the red and blue squares should be staggered.

We then have a CMS, which allows the user to add as many of these [red][blue] square components as they wish.

I adapted the forEach codepen example above to add a second instance of [red][blue] squares contained in a box-wrapper. Hopefully this explains and illustrates the problem at hand a little clearer.

Are you saying I should set the trigger inside scrollTrigger to be the box-wrapper ?

Link to post
Share on other sites

See the Pen vYyNNBw?editors=1010 by mvaneijgen (@mvaneijgen) on CodePen

 

You have to think about it like this, on which elements would you like to add a scroll trigger, for you this would be the wrapper, so it becomes `wrapper.forEach`. Than within the forEach you like to animate some stuff, in your case you want to animate multiple elements in a staggered fashion, so you give your animation ALL the elements (in your case boxes).

 

As a side note I would scope your boxes to the wrapper, but it seems to work fine.

See the Pen OJbyyVV?editors=1010 by mvaneijgen (@mvaneijgen) on CodePen

  • Like 4
Link to post
Share on other sites

Hello mvaneigen

This second solution is excellent, I implemented it in the real life scenario and it works. Thank you for being a life saver.
I hope this would help someone in a similar situation.


By bringing the boxes array inside the forEach and querySelectorAll to find them instead of gsap.utils.toArray fixed the jumpiness you see in the first solution. I do not know why, but I am thankful for it.

Thank you for your time man.

Link to post
Share on other sites

@Andell good to know.

 

I almost never use `gsap.utils.toArray`, I don't know why but `querySelectorAll` almost always works for me and you can also call the item directly within GSAP `gsap.to('.myclass')` which also gets all the elements with a class of `myclass`.

 

But glad it helped you!

  • Like 2
Link to post
Share on other sites
33 minutes ago, Andell said:

By bringing the boxes array inside the forEach and querySelectorAll to find them instead of gsap.utils.toArray fixed the jumpiness you see in the first solution. I do not know why, but I am thankful for it.

 

I would say this is not just a sidenote, as @mvaneijgen said, but rather neccessary logic for it to properly work.

 

In that first pen, he is creating an array of all boxes on the page, so every time a ScrollTrigger would be triggered, it would animate all boxes on the page, which would create logic-issues/conflicting tweens with the next time all boxes would be animated when hitting the next trigger.

 

In the second pen he chose to only address the boxes inside the specific wrap, so only those will be animated on trigger.

Since the triggers are set on each wrap there will be no conflicts because the boxes will not be triggered to be animated anywhere else.

 

Thus this is sort of key for that solution to work.

  • Like 5
Link to post
Share on other sites
3 hours ago, mvaneijgen said:

I almost never use `gsap.utils.toArray`, I don't know why but `querySelectorAll` almost always works for me

The main reason to use .toArray() instead of .querySelectorAll() is for IE - .forEach() doesn't work on nodeLists in IE (which is what .querySelectorAll() returns) but it does work on arrays. So using .toArray() is better if you're wanting to use .forEach() and have to support IE. 

 

There might be other situations where an array is preferable to a nodeList as well.

  • Like 3
Link to post
Share on other sites
8 hours ago, Andell said:

By bringing the boxes array inside the forEach and querySelectorAll to find them instead of gsap.utils.toArray fixed the jumpiness you see in the first solution. I do not know why, but I am thankful for it.

Are you saying that you get different behavior by swapping in document.querySelectorAll() for gsap.utils.toArray()?? I'm super curious to see a minimal demo - can you share one please? I cannot fathom why you'd see any difference. Like Zach said, gsap.utils.toArray() is almost always better because it returns a true Array which consistently has more methods that work across browsers. 

Link to post
Share on other sites

Hello Jack.
you are right, no need to panic lol.
The difference was not because of the document.querySelectorAll in place of the gsap.utils.toArray

The major thing that cleared up stuff was the declaration of the boxes array inside the forEach instead of outside it.

At the point of this morning I did not know why it worked, but as you can see Zach already cleared up both points, and now its clearer.

  • Thanks 1
Link to post
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.

×