.to function duration argument

[maximus8891]

Is there a specific reason why duration is an argument but not a config object param? I'd really like to put duration of a tween into object as well.

 

Instead of

TweenLite.to(elm, 1, {delay: 10});

it could be

TweenLite.to(elm, {duration: 1, delay: 10});

so I could do this

var tween = {
 duration: 1,
 delay: 10
};

TweenLite.to(elm, tween);

instead of

var tween = {
 duration: 1,
 delay: 10
};

TweenLite.to(elm, tween['duration'], tween);

[GreenSock]

Yep, that was intentional. 

1. It decouples duration from tween state so that you could, for example, create one config object and feed it to multiple tweens that have different durations. Basically, it's more flexible.
2. It allowed for strict data typing which is not only faster, but also aids in debugging. This is less of an issue in JavaScript for now, but it certainly helped in ActionScript and there's a good chance that at some point, JavaScript will also benefit from strict data typing. 
3. Unlike "delay" and pretty much every other property, duration is essential for any tween, thus it made sense to make it a required parameter. 
4. It kept the code more concise. Less typing

[maximus8891]

Thank you for the response.

 

Should it be a huge change to implement an alternative consistent approach:

TweenLite.to(elm, {duration: 1});

leaving alone the traditional one. This will make code more concise too in certain cases.

[GreenSock]

After building and working with APIs for years, I've learned that doing things like that can cause all sorts of problems. Sure, it might be convenient for you in your particular scenario, but if we make that change to the API, it has the following consequences (just to name a few off the top of my head):

 

- What happens when someone provides a duration in BOTH places? Which one wins? Some people may be so accustomed to seeing it the "normal" way that if they come across a tween that uses your proposed syntax, they may think it's a mistake and add in a normal duration without realizing they should remove the property from the vars object.

- It creates some confusion in the API. Some users may not even know that option exists and scratch their head when they see it. I know that I've gotten pretty confused when I came across jQuery functions that used this "loosy-goosy" way of dealing with parameters.

- The new syntax would break if used with older versions of GSAP

- It nullifies the benefits of strict data typing

- It forces us to add additional logic in the core to sense when a duration isn't provided, and use a default.

- How would this affect other parts of the API, like the TimelineLite.to() method, and from(), etc. - would those suddenly treat the 2nd parameter as optional and allow people to shift everything over by one slot? If so, there's a bunch of extra conditional logic that'd have to analyze each value and react accordingly. Extra conditional logic means more kb and less performance. I loathe that idea

 

Sorry, it just isn't worth all those tradeoffs and risks. I think you're actually the first person to ask for this in all the years we've had GSAP out there which doesn't mean it's a bad idea, but only that it's not a feature that's in high-demand.

[maximus8891]

I see that most issues are related to backwards compatibility and not confusing users.

 

But I don't quite understand what you mean by the benefits of strict data typing.

 

I look at the code in TweenLite.js:

var Animation = _class("core.Animation", function(duration, vars) {
 				this.vars = vars = vars || {};
 				this._duration = this._totalDuration = duration || 0;
 				this._delay = Number(vars.delay) || 0;

Type conversion is done for delay, but not for duration. I think there is as many reasons to do type conversion for duration as for vars.delay. Correct me if I'm wrong, but you can run

TweenLite.to(elm, '3.545') 

and it will run totally fine, hurting performance. This may pass unnoticed in cases when duration is deducted from dom attributes, which are strings.

 

I think the major problem about this param is that if a user likes to make a config and apply it he has to do it like this:

var tween = {
 duration: 1,
 vars: {
  ease: ease
 }
};

....


TweenLite.to(elm, tween.duration, tween.vars);

// Instead of much cleaner

TweenLite.to(elm, tween);

I think I end up making a wrapper like

function TweenLiteV2(config) {
 return TweenLite.to(config.elm, config.duration, config.tween);
}

[GreenSock]

Actually, no, I only mentioned backward compatibility once - there are a bunch of other reasons I cited that are even more significant.

 

As for what I mean by strict data typing, in most programming languages you must (or at least can) declare the data type of each parameter, like number, array, string, integer, etc. This not only allows the compiler to optimize things (sometimes to a significant degree), but it also aids in debugging because the compiler will throw an error if you try passing in a parameter of the wrong type. Unfortunately JavaScript doesn't offer that quite yet, but I bet it will happen in the future, thus I prefer to keep the API as-is.