Jump to content


onCompleteAll for staggerTo

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

Here you go:


TweenMax.staggerTo(".tile", 1, { autoAlpha: 0, ease: Power2.easeOut}, 1, allComplete);

function allComplete() {
  console.log('all complete');
  • Like 4
Link to comment
Share on other sites

  • 1 month later...

Ok Carl, thanks. But I found this to be problem too. Why isn't documentation up to date?

That's kind of silly for this great product.

Link to comment
Share on other sites

hello mgalic.. if you look at the staggerTo() method in the API DOCs you will see how each method is documented quite well:






public static function staggerTo(targets:Array, duration:Number, vars:Object, stagger:Number = 0, onCompleteAll:Function = null, onCompleteAllParams:Array = null, onCompleteAllScope:* = null):Array


targets:Array — An array of target objects whose properties should be affected, or selector text that gets passed to TweenLite.selector (for selecting DOM elements). For example, if jQuery (or similar) is loaded and you pass ".myClass", it would act as though you passed in an array of DOM elements that had the "myClass" class applied. The same behavior applies if you pass a jQuery object containing multiple elements (like $(".myClass")).
duration:Number — Duration in seconds (or frames if useFrames:true is defined in the vars parameter)
vars:Object — An object defining the end value for each property that should be tweened as well as any special properties like ease. For example, to tween x to 100 and y to 200 for mc1, mc2, and mc3, staggering their start time by 0.25 seconds and then call myFunction when they last one has finished, do this: TweenMax.staggerTo([mc1, mc2, mc3], 1, {x:100, y:200}, 0.25, myFunction}).
stagger:Number (default = 0) — Amount of time in seconds (or frames for frames-based tweens) to stagger the start time of each tween. For example, you might want to have 5 objects move down 100 pixels while fading out, and stagger the start times by 0.2 seconds - you could do: TweenMax.staggerTo([mc1, mc2, mc3, mc4, mc5], 1, {y:"+=100", opacity:0}, 0.2).
onCompleteAll:Function (default = null) — A function to call as soon as the entire sequence of tweens has completed.
onCompleteAllParams:Array (default = null) — An array of parameters to pass the onCompleteAll method.
onCompleteAllScope:* (default = null) — The scope in which the onCompleteAll callback should be called (basically, what "this" refers to in the function). NOTE: this parameter only pertains to the JavaScript and AS2 versions; it is omitted in AS3. 


  • Like 2
Link to comment
Share on other sites

Hi mgalic,


Can you please let us know how you would like the staggerTo docs to be changed?


Currently we describe what all 7 parameters of the method do and we specifically call attention to the onCompleteAll param, but if you see room for improvement please let us know.


Note that if you define an onComplete (or any callback for that matter) in the vars parameter, it will be called for each tween rather than the whole sequence. This can be very useful, but if you want to call a function after the entire sequence of tweens has completed, use the onCompleteAll parameter (the 5th parameter).




We definitely want people to avoid problems.



Link to comment
Share on other sites

  • 2 years later...

Hello Carl,


I know this is an old topic, but I am in  agreement with mgalic in regards to use and placement of this parameter.


All the on methods (onComplete, onReverse etc ) of GSAP (that I have used) have been within the {} braces for example if we do a simply tween with a call back

TweenMax.to(element, 1, {opacity:0, onComplete:completeHandler, ease:Back.easeOut});

with this in mind it makes it simple to remember placement of the parameter (or any parameter) within this structure so we can add parameters like this:

TweenMax.to(element, 1, {opacity:0, onComplete:completeHandler, onCompleteParams: ["input"],ease:Back.easeOut, useFrames:true});

so if we take the staggerTo method and apply a similar treatment and I will use this case

TweenMax.staggerTo(".tile", 1, { autoAlpha: 0, ease: Power2.easeOut, onComplete: allComplete}, 1);

we know this will work, if may not be the desired effect but using 'onComplete' in this case will mean that we call the function every time each tween as completed.


So with this method a developer may expect to use the same design pattern to call the function when the entire sequence of tweens has completed so I would expect this

TweenMax.staggerTo(".tile", 1, { autoAlpha: 0, ease: Power2.easeOut, onCompleteAll: allComplete}, 1);

but this does not work has you have mentioned you need to do this:

TweenMax.staggerTo(".tile", 1, { autoAlpha: 0, ease: Power2.easeOut }, 1, allComplete);

which causes confusion because it goes against the design pattern of the method, after your curly braces you would expect to see only stagger nums, positions or labels.

Again its just my opinion but being a designer I rely on convention, patterns and logic to execute my work, this method of implementation is not really clear in the docs, neither is it what I would expect.





  • Like 2
Link to comment
Share on other sites

Hi Bromel,


Thanks for the thoughtful suggestion.


Stagger-based methods are very unique in that they literally create multiple tweens for multiple objects. Throughout the entire API the vars object allows you to specify properties for a single tween that is being created.


in stagger-based methods each property in the vars object gets applied to each tween that it generates. Tweens don't have an onCompleteAll callback, which is why onCompleteAll isn't added to that vars object. This is actually the most consistent implementation. 


I do think your suggestion is good and it probably would make things easier for folks.


However, the current API does work, its documented properly and it's pretty rare that we hear anything about it. Changing it now would either require us to break existing code in projects or bloat the API and impact performance by trying to implement it both ways.


Perhaps if we ever do a major version update where we can properly warn folks of changes that would impact legacy projects we can put this under serious review. 

 Thanks again for taking the time to chime in.

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