Jump to content
Search Community

GSAP.set modifies objects passed in as a transition definition?

Asderex test
Moderator Tag

Go to solution Solved by GreenSock,

Recommended Posts

Hi,

 

This could be an intended behaviour which I hadn't picked up in the documentation so I thought I should post a question.  Is it the intention for GSAP to modify objects passed in as transition properties?

 

In my situation I have a bunch of animation properties for a particular element stored on an object which is used in numerous places.  As per the codepen demo attached you can see the object initialised in row 1 is has been modified by the time it is logged in row 5.   In my programme I map over the same transition object to perform various operations and for the life of me I couldn't figure out where these extra properties were coming from as I assumed GSAP would only modify the DOM element passed in (although the names where a helpful hint).

 

Having located the  bug it was easily fixed with: 

gsap.set(document.querySelector('#TITLE'), {...animationProps})

but I would have thought the original (no spread operator) was a natural way of writing this.

 

Are there any doc's explaining the modification or is this a bug? Thought I might save someone else some pain.... this took an embarrasingly long time for me to diagnose.

 

Thanks

See the Pen rNMOWYE?editors=1111 by Asderex (@Asderex) on CodePen

Link to comment
Share on other sites

Hi,

 

I wouldn't consider it a bug. Keep in mind that a zero duration tween is not a distinctive GSAP instance on it's own, just a regular GSAP instance with duration zero. The .set() method is just a shortand/convenience in order to make it easier on developers to write, read and maintain code, because once you get used to the API it's simpler to understand this: gsap.set(element, {config}) than this: gsap.to(element, {duration: 0, config}), if another developer in a team looks at the second example the first thing is: Why this animation has a duration of 0 seconds? If the set() method is confusing the dev can come to the API docs, check it and realize that it creates a zero seconds tween.

 

With that in mind and not knowing all the ins and outs of the codebase, perhaps that this happens in one of this places in the code:

https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L307-L352

https://github.com/greensock/GSAP/blob/master/src/gsap-core.js#L1115-L1130

 

Or somewhere else :D... Now I have used several times the approach you're using of creating a re-usable config object, but I never took the time to inspect it after GSAP used it, because it never led to any unexpected behaviour. Keep in mind that most commonly objects are passed by reference so given the parts of the code I linked above is quite expected that the original object would be modified. Is this modification leading to some issue in your code? I'd expect that if you overwrite any of the properties added by GSAP the one that you add would take precedence over the ones added by GSAP since those are there just as defaults.

 

Finally I believe that either @GreenSock or @ZachSaucier are in a better position to give you a more "official" answer.

 

Happy Tweening!!!

  • Like 1
Link to comment
Share on other sites

Jack can correct me if I'm wrong here, but as far as I understand this behavior is the intended behavior. If GSAP needed to create a new object based on the object passed in (instead of just using the one passed in) then there would one more thing to do every time that a tween is initialized. Given it's extremely rare that it matters if the object passed in is affected or not it's nice to not have to do that processing for every tween. If it is necessary, as you show, you can just do that processing before passing the object to GSAP.

  • Like 2
Link to comment
Share on other sites

  • Solution

Yeah, sorry about any confusion there. Like Zach said, that was an intentional decision. It's extremely rare that people reuse the same vars object for various animations, and even less so where it would make any difference. We're obsessed with performance, so it seemed quite wasteful to force every tween for all users to create a new object and loop through to copy all the properties over. Especially since it's so easy to implement externally for anyone who needs that functionality. 

 

Does that clear things up? 

 

As for it not being in the docs, it's frankly quite a tricky balancing act because we want the docs to be rich in information but not overwhelming. We must be strategic about crafting the content there and deciding which things justify being included. Again, sorry if that led to lost time on your part. 

  • Like 3
Link to comment
Share on other sites

3 hours ago, GreenSock said:

Does that clear things up? 

 

As for it not being in the docs, it's frankly quite a tricky balancing act because we want the docs to be rich in information but not overwhelming.

Yes - sure does.  I figured this was probably an edge case given GSAP's user base and the fact I couldn't see anything on it.  Now I know what to look for I wont have the same issue in future.  Understand and agree it probably doesn't warrant addition in the doc's.  Hopefully if (in the unlikely event) someone manages to repeat my mistake googling:

 

Keywords:  added properties delay duration ease overwrite repeat

 

will lead them to this explanation anyway.  Thanks for the reponses everyone.

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