- GSAP (Animation Platform)
- Getting started
- Docs
- Cage match: jQuery | CSS3
Getting Started
Speed Tests
Tips & Tricks
Plugin Explorer
Feature Comparison
Join Club GreenSock
Code Hinting and Strict Data Typing for TweenLite and TweenMax Vars
Having a hard time remembering all the special properties that you can define in your TweenLite or TweenMax “vars” parameters? I don’t blame you, especially with all the nifty plugins available. If you’d like to get the convenience of code hinting and improved debugging with strict data typing, you’ll love the new TweenLiteVars and TweenMaxVars classes. As of version 5.0, they have been completely rewritten to accommodate method chaining which greatly reduces the amount of code necessary (compared to previous versions). Here’s how the standard way of defining vars with a generic Object compares to using a TweenLiteVars instance:
//Without TweenLiteVars
TweenLite.to(mc, 1, {x:300, autoAlpha:0, onComplete:myFunction, onCompleteParams:[mc]});
//With TweenLiteVars
TweenLite.to(mc, 1, new TweenLiteVars().prop("x", 300).autoAlpha(0).onComplete(myFunction, [mc]));
Here’s what the code hinting looks like in Flash Builder:
You can also use a hybrid approach by passing a generic Object into the constructor to define whatever properties you want, like this:
//pass a generic Object to the constructor...
TweenLite.to(mc, 1, new TweenLiteVars({x:300, y:100, scaleX:1.5}).autoAlpha(0).onComplete(myFunction, [mc]));
One other benefit is that it will trace() a warning if you try using a special property without activating the corresponding plugin. For example, if you define an autoAlpha value in a TweenLiteVars instance but you didn’t activate() the plugin, you’ll see a trace() output when you test/compile the file (an Error isn’t thrown because in some very rare circumstances it is acceptable to avoid activating the plugin).
What are the trade offs?
The only significant trade off is file size; TweenLiteVars adds about 5kb to your swf. TweenMaxVars is only slightly heavier. But remember, both are completely optional so only use them if you can afford the extra kb.
FAQ
- I hate chaining – it’s ugly. Why did you change perfectly good classes to use this funky syntax?
I wasn’t a fan of the chaining syntax when I first saw it either. It felt weird. But there are several key advantages that it provides which make it ideal for this particular type of class. First, it is much more concise than the old “standard” way of defining values (like vars.delay = 5) when you have many values to define. Also, it accommodates multiple parameters for a single special property which is quite useful for things like filters (blurX, blurY, quality, etc.). Plus it reduced the file size footprint of the class(es) to less than half of what it was previously! Lastly, it allows the values to be defined inline which is particularly useful in situations where you’re putting many tweens into a TimelineLite/Max. No need to create local variables. Before turning up your nose and declaring this new chaining style beneath you, I’d encourage you to give it a try for a project or two. I’m pretty confident that you’ll quickly see how convenient and functional it is. - Where do I get the classes?
They’re in the com.greensock.data package in the AS3 zip downloads. Click the big “Download AS3″ button at the top right of this page or any of the tweening-related or loading-related pages. - Do I have to use one of these classes in order for TweenLite/Max to work?
Absolutely not. It is completely optional. - Does code hinting work in all code editors?
No, but most modern code editors offer this feature including Flash Builder, FDT, FlashDevelop, and even Flash Professional CS5. - Will these classes work with older versions of TweenLite and TweenMax?
Technically they can, but it is definitely best to update to at least version 11.4 of TweenLite/Max. To make TweenLiteVars and TweenMaxVars compatible with all versions, you must feed the raw “vars” data into the tween, so tack on “.vars” to the end of your method chain like this://Don't forget the ".vars" at the end... TweenLite.to(mc, 1, new TweenLiteVars().prop("x", 100).autoAlpha(0).vars); - If I was using an old version of TweenLiteVars or TweenMaxVars, will I need to rework my code to use the new versions?
Yes, you will. I always try hard to avoid API changes that could affect legacy code like this, but sometimes it is necessary in order to take a big step forward. If you are currently using older versions of TweenLiteVars or TweenMaxVars and don’t want to spend time updating your code, make sure you keep a copy of the legacy versions of the classes. Feel free to send an e-mail request if necessary.
Twitter
Facebook
Digg
StumbleUpon
del.icio.us
Yahoo! Buzz
Google Bookmarks
RSS
LinkedIn
Reddit
Comments (17)
Hi,
Great update and i will definetly use it.
Could you do this:
onComplete(func:Function, … params):
instead of this:
onComplete(func:Function, params:Array = null)
It would be more user friendly and you still would receive an Array.
Actually, Paulo, I don’t think that would be more user friendly – an array makes it simple to group the parameters dynamically and reuse them in multiple tweens plus it maps more cleanly to the onCompleteParams special property that TweenLite and TweenMax look for in the generic vars object.
Inline?
Yuck.
Very disappointed.
Just to clarify, I’m a developer who very happily setup my Tween variables in FlashDevelop the “OLD WAY” (as your newsletter defined it). Code hinting was never a problem… I always instantiated a TweenLiteVars or TweenMaxVars object to populate and pass into to my Tween* function.
Oh well, what GreenSock dictates, we all must follow.
Cheers for the initiative. 
James, as I understand, you can still use this new TweenVars with the old way just the way it was.
Not quite, Ramiro. Since the old properties are now functions, you can’t just do something like vars.delay = 5. You’d do vars.delay(5). But you certainly don’t need to chain things together if you don’t want to. You can do this:
var config:TweenLiteVars = new TweenLiteVars();
config.delay(5);
config.onComplete(myFunction);
Or you can even use the chaining syntax but split each property out onto its own line to make it [arguably] more readable:
new TweenLiteVars()
.delay(5)
.onComplete(myFunction);
Wasn’t a fan of this new syntax when i read the mail, but it’s really starting to make sense to me now. This new format looks good, and i’m looking forward to trying it out in my next project
Hmm, ok. I’ve never used the old version. What I meant was that you can like your first example: declare it and call one method per line.
hmmm.. not digging the new way…
This new syntax is pretty bad for things like blur filters. In the old method, you could do something like
myVars:TweenLiteVars = new TweenLiteVars();
myGlowVars:GlowFilterVars = new GlowFilterVars(1,1,0xffffff);
myGlowVars.addFilter = false;
In the new syntax, You have to do:
myVars:TweenLiteVars = new TweenLiteVars();
myVars.GlowFilter(1,1,0xffffff,1,2,false,false,2,false);
Not only is that not readable at at all, I have to define all those unnecessary variables.
Zachary, it is a bit of a double-edged sword but I’m confident that when you weigh all the pros and cons, they add up pretty decisively on the side of the new syntax. Even with having to define the 5 extra parameters in the example you posted, the new syntax is shorter. And remember that one of the primary purposes of these optional classes is enabling code hinting, so the readability argument loses its strength pretty quickly (put your cursor on any argument and CTRL-SPACE). The old way was practically impossible to do inline, making things much more verbose plus it required more than double the file size. And extra helper classes (like GlowFilterVars) were necessary. Not anymore. The new system even checks to make sure you activated the plugin if necessary. So all in all, it’s a big step forward, but I realize there will be some growing pains for folks who were used to the old way. I apologize for that.
I hate to say it… But I like the new syntax. There are some negatives, but it really is easy to use inline. You win. 
(But I still consider that unreadable. I can’t tell what variable i’m changing, and I can’t – at a glance – tell anything about it at all. But even with that, it’s better this way.)
Inline isnt that bad really – its better for quick coding and user friendlyness
Come on guys inline isn’t so bad
I think TweenLiteVars are awesome (use it alot), but I would like to see these functions added to it:
.move(x:Number, y:Number, relative:Boolean = false)
.scaleX(value:Number, relative:Boolean = false)
.scaleY(value:Number, relative:Boolean = false)
.scale(value:Number, relative:Boolean = false) // does scaleX and scaleY
Your wish is my command, Mark I added those convenience methods (along with a few others) in the latest version.
Thanks, that was fast. I see you’ve added rotation() too, I forgot to mention that one too, had it in my mind too. Awesome! I’m glad I’ve requested it. Have a lovely christmas!
Download zip 
github 
CDN link