Jump to content
Search Community

Could/should TweenMax handle adding properties to target objects?

ElliotGeno test
Moderator Tag

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

You obviously have a few custom properties mixed in with real properties of elements. Let's say you created a generic way for both TweenMax and your users to register custom properties on a target object before calling a tween. Maybe it would share a little code throughout the user's application and TweenMax library that way. Plus you could create all sorts of custom effects or even enhance functionality of an everyday object or element!

 
I could see the method call to register a new property looking something like this:
TweenMax.addProperty(targetObject,"propertyName",callback,DataType);
 
Internally, TweenMax would track and tween the value if it is a Number. Otherwise the user can use TweenMax.set() to apply changes to the object for other data types. Then it would use a callback to send the value to the user.
 
The callback would look something like this:
function callback(tween, propertyName, value){
     //user stuff
}
 
This way, developers could make sure they create properties in an optimal way for you to handle.
 
Obviously, there is onUpdate(), but this opens new possibilities for updates per property.
Link to comment
Share on other sites

This is exactly what plugins are for. The reason we can't do it the way you described with a simple callback/function is because there are some deeper-level contingencies that need to be addressed in order to work smoothly with the system, like:

  1. Overwriting. For example, think about a special property like "autoAlpha" which affects two other properties ("opacity" and "visibility"). If there's another "opacity" tween happening, the autoAlpha should overwrite that, or visa-versa. 
  2. Special getting/setting. The system needs to allow you to tell it how to get/set the values appropriately. For example, CSS may use element.style["propertyName"], SVG may use element.getAttribute("propertyName"), and autoAlpha might have to check opacity and visibility and combine them using special logic. Same goes for setting the values. 
  3. Priority level. Sometimes certain properties should be set before others, or after them. So if you're tweening {x:100, y:200, motionBlur:true}, the blur should be the final step, after all the positional stuff. 
  4. Rounding. The plugin needs to conform to some protocols for roundProps to work properly with it. 
  5. Relative values ("+=20" or "-=10"). 
  6. When overwriting occurs, sometimes a plugin needs to tell the tween to re-run its instantiation code because it did some fancy-footwork that could affect other properties. For example, in ActionScript the MotionBlur plugin was very complex and it had to create a whole new bitmap, put it in the display list, take the original and put its opacity at 0, etc. So if another motionBlur tween started before the other one ended (on the same target), the original would have to kill the bitmap, swap things in the display list, put the original's opacity back to 1, etc. but if the other tween had already recorded values they may be inaccurate (like opacity:0). Yes, it's an edge case, but it's something that we've built the plugin structure to accommodate. 

Take a look at the TEMPLATE_TweenPlugin.js and you'll see that you can do pretty much exactly what you're looking for (if I understood you correctly) - register your own custom property that the engine will hand off to you. 

 

Perhaps I misunderstood though. Im' curious - why did you have "targetObject" in your addProperty() registration method? Would you have to call that for every potential target object? Like if you have 100 <div> elements, do you have to call that once for each? I assume not - I just wonder why you allocated a parameter for it. And was your "callback" basically a setter function where you'd take the new value and apply it properly? 

  • Like 1
Link to comment
Share on other sites

I figured on keeping the syntax similar to TweenMax.set(); The first object would be either an array, object, or string for finding the selector. The callback was just a setter function and it would work as you described.

 

Maybe I need to take a look at this TEMPLATE_TweenPlugin.js before moving forward. 

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.
×
×
  • Create New...