jeremyckahn
commented
9 years ago Thanks @adrianvoica, these are definitely good ideas. I only have two concerns:
- We need to make sure not to expose a global variable if Shifty is being loaded by a script loader (hence the UMD shim currently in place).
- Unless we export both
TweenableandShifty(which I would prefer not to do), this will break Shifty for all existing users.
This would need to be part of a 2.0 release, which I'm fine with doing at this point so long as we have a substantive list of changes. I've started a wiki page to define what 2.0 might look like — can you take a look and add what things you feel that Shifty could benefit from? This is our chance to make significant, backwards-incompatible changes to Shifty.
After further revisiting and digesting the source code of Shifty, I see a real potential for defining a reusable global utility object ("Shifty" sounds like a good name candidate).
Right now, every time a new Tweenable instance is created, a lot of checks are performed, some redundant stuff is added (I'm thinking of the code of each formula).
Instead, a global object (Shifty?) should be added that will contain: e.g: the name/reference of the current animationFrame function (vendor-based, etc.), desired default frame rate, globally shared pool of data for lookup table optimisations, etc.; it should also contain the shared code for interpolation formulas. Thus, when a new Tweenable instance is created, it first checks if the Shifty object is available, and if not, it creates it. After that, it only uses the global object for common/shared functionality.