TweenMax to GSAP 3: problems with TweenMax.killDelayedCallsTo

[Kaleb242]

I went through the GSAP 3 Migration Guide and GSAP 3 Release Notes, but haven't seen this documented there...

GSAP 2's TweenLite.killDelayedCallsTo(function) and TweenMax.killDelayedCallsTo(function) have been removed, and the GSAP 3 equivalent seems to be gsap.killTweensOf(object)

I have a ton of legacy code written in GSAP 1.x / 2.x, and discovered TweenMax.killDelayedCallsTo in several places in the code base, which throw errors when they are encountered. Removal of it in GSAP 3 has made the migration process a bit rough.

I wish there was some kind of TweenMax legacy adapter plugin that I could import for enhanced backwards compatibility to help legacy GSAP 1.x/2.x syntax projects run seamlessly under GSAP 3 without having to make major rewrites to old syntax on things that have been removed in GSAP 3 that could basically remap references made in old TweenMax syntax to GSAP 3 equivalents (without having to bloat GSAP 3 with internal references on new pages written in GSAP 3 syntax).

I know most of the old syntax of TweenLite and TweenMax tweens still work under GSAP 3 (thanks to internal references), but this particular one was omitted... and throws code breaking errors. Something that could be imported just on legacy pages would be super helpful...

[ZachSaucier]

Hey Kaleb. You should be able to use gsap.killTweensOf(functionReference).

[Kaleb242]

Thanks Zach; as mentioned, I'm aware of the new GSAP 3 equivalent method gsap.killTweensOf()...

 

I was hoping that the GSAP 3 migration guide and release notes could be updated to mention that TweenMax.killDelayedCallsTo() was removed?
(It's definitely a little roadblock in TweenMax backwards compatibility.)

 

https://greensock.com/3-migration/
https://greensock.com/3-release-notes/

It would also be helpful if the GSAP 3 documentation for gsap.delayedCall() could also mention gsap.killTweensOf() -- currently it only mentions gsap.kill()
https://greensock.com/docs/v3/GSAP/gsap.delayedCall()

Do you know if there is a way to "bring back" the TweenMax.killDelayedCallsTo() method and have it pass along to the new gsap.killTweensOf() method for backwards compatibility without rewriting references that were written in the old syntax?

[GreenSock]

12 minutes ago, Kaleb242 said:

I was hoping that the GSAP 3 migration guide and release notes could be updated to mention that TweenMax.killDelayedCallsTo() was removed?

It was already there. It says "killDelayedCallsTo() is now .killTweensOf()"

 

13 minutes ago, Kaleb242 said:

Do you know if there is a way to "bring back" the TweenMax.killDelayedCallsTo() method and have it pass along to the new gsap.killTweensOf() method for backwards compatibility without rewriting references that were written in the old syntax?

Wouldn't this be as simple as one "find and replace" in your editor? One of the big goals with the GSAP 3 complete rewrite was to eliminate redundant things like and reduce file size, so it'd feel pretty weird to add in more code that's just making two methods point to the same thing. See what I mean? 

 

28 minutes ago, Kaleb242 said:

It would also be helpful if the GSAP 3 documentation for gsap.delayedCall() could also mention gsap.killTweensOf()

Sure, that's done now. 

 

Happy tweening!

[Kaleb242]

Thanks Jack! 

@GreenSock It's the GSAP 3 migration guide that has no mention of .killDelayedCallsTo() or .killTweensOf() -- but you are correct, the Release Notes does mention it in the last bullet point under "What old code will definitely break?" 😅

• .killDelayedCallsTo() is now .killTweensOf().

I wish it were as simple as find and replace... we're trying to migrate over 1,071 pages in 25 locales from various versions of greensock 1.x/2.x to the latest GSAP 3.6.0, and phasing out ScrollMagic for the super amazing ScrollTrigger Plugin for all new pages going forward, but permissions on various legacy pages in our  corporate publishing platform prevents me from making direct edits to legacy code in Raw HTML Components on many of the pages... so all I can really do right now is switch the code library that is used site-wide.

Rewriting old syntax to new syntax is currently out of scope, there are too many pages to manually port over from greensock 1.x/2.x to GSAP 3.6.0, but I'm trying hard to get us on the latest version of everything, and not have to switch between old and new versions of GSAP... I'd like to try and keep it evergreen site-wide, globally.

We're trying to roll out a new accessible navigation system site-wide, and I've written everything for that navigation system in the superior GSAP 3 syntax, but several legacy pages are now breaking when I replace TweenMax 1.x/2.x with the latest GSAP 3.6.0 library.

What I really don't want to have to do (but may have no other choice) is to rewrite the navigation system in legacy TweenMax syntax, in order to allow legacy pages to stay on old versions of greensock 1.x/2.x TweenMax, and newer pages to run on the latest version of GSAP 3.x.

[ZachSaucier]

55 minutes ago, GreenSock said:

It was already there. It says "killDelayedCallsTo() is now .killTweensOf()"

I added that after this post was made  

[GreenSock]

@Kaleb242 if you can't update your code, wouldn't it be simple enough for you to do this in the JS code that you load?: 

TweenMax.killDelayedCallsTo = gsap.killTweensOf;

And then it'd all "just work"? 

[iDad5]

Luckily I'm not (right now) in kaleb242's shoes but when I read the thread was sure that in the end there would be a 'simple' solution offered by you - and yes you did once again!

 

I just thought, that you could probably offer a small plugin that takes (in the fashion you just suggested) care of the astonishingly small number of things that can break with the gsap3 migration. 

 

Then aging I remembered the age old discussion about "if bad(old) code would work, everybody would write bad code..."  So I don't want to oben that can of worms.
I just have to marvel once again at the lever of support you offer. 👍

[GreenSock]

Yeah, it's not a terrible idea but as you said, I'm always reluctant to provide too many crutches that make it really comfortable for people to write their code in a dated syntax that'll likely break in a future major update. At some point, we need to draw  a line in the sand and encourage people to modernize their code. We do place a very large priority on backwards compatibility which is why we added so many aliases in place - the VAST majority of old v2 and v1 code "just works" when loading GSAP 3 and that cost some kb. I saw it as worthwhile for the most-used methods/features. I personally hate it when libraries just shift around their API and make breaking changes - I'm like "I was used to the old way...don't make me change all my code!" I get it. But again, it's a balancing act. We can't just support the old syntax forever AND modernize things or else the file size and complexity will grow and grow. 

 

We also have to factor in people who read code and see the "old way" and think it's the "right way", even after GSAP 3 has been out in the wild for years. 

 

But yeah, in this case it really should be as easy as that one line of code that'll resolve all your old code that you can't change.