[Discussion] AllFrom, AllTo, AllFromTo syntax redundant?t

[JonDum]

I'm wondering why there is discrepancy in .all() methods and the .to(), .from(), and .fromTo() methods since all of the tweening classes have an emphasis on being light weight.

 

For instance, consider:

 

allTo(targets:Array, duration:Number, vars:Object, stagger:Number = 0, onCompleteAll:Function = null, onCompleteAllParams:Array = null):Array

 

&

 

to(target:Object, duration:Number, vars:Object):TweenMax

 

Since Arrays and Objects are easily cast to one another, couldn't the .to syntax take an array of targets just like .allTo? The stagger, onCompleteAll, and onCompleteAllParams could be included in the vars paramater of the .to() method (the same for .from() and .fromTo() ) I was a little confused why .all() methods had these extra parameters in the first place when they could just be included in the vars object.

 

Just a thought. Interested in hearing other's thoughts on this.

[GreenSock]

I'm wondering why there is discrepancy in .all() methods and the .to(), .from(), and .fromTo() methods since all of the tweening classes have an emphasis on being light weight.

 

Fair question. Actually, there are several reasons for this choice:

 

1) Adding this functionality would in fact increase the file size and reduce the speed slightly on all tweens due to the extra conditional logic internally. Everyone would pay a price for this "feature".

 

2) It would muddy things in terms of overwriting and methods like killTweensOf(), getTweensOf(), etc. In other words, let's say you had a single tween that had multiple targets and you call killTweensOf(object1). Should it kill the whole tween? Should it operate on the tween and pull out just that target? What if you're only trying to kill individual properties of that tween for that object? Now it'd be a mess internally in terms of the logic required to loop through and only affect certain properties for certain targets in that multi-target tween during every render cycle from that point on.

 

3) There's an EndArray plugin that allows you to tween numeric elements in an Array already, so it would make things even more messy/muddy because of the extra logic required to figure out what kind of tween the user is trying to do - a multitarget tween or a regular array tween. Again, it's possible, but messy and it slows things down for all tweens.

 

4) I personally think it's cleaner to get an Array of tweens back instead of a single tween with multiple targets because then I can work with them individually if I want. More flexibility. And if you want to treat it as a whole, it's super easy to do so by dumping them into a TimelineLite or TimelineMax.

 

I put a huge priority on performance, file size, and simplicity. One could argue that your suggestion would make it more simple but on the other hand there are definitely arguments against that. Either way, there's no question that performance would degrade and file size would increase, so while I like the general concept you're proposing, I don't think it's worth the price when you consider the practical application costs.

 

Keep the suggestions coming, though.

[JonDum]

Ah, great points! I'm not entirely familiar with the architecture of the platform yet since I just started using it a few days ago; I didn't know about killTweensOf()!

 

Those are definitely some good points, and I think I can live with it if it means less filesize AND better performance, however unintuitive that is haha! I guess in this case the extra simplicity is detrimental.