Jump to content
Search Community

Search the Community

Showing results for tags 'require'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Twitter


CodePen


Company Website


Location


Interests

Found 3 results

  1. Hi, I'm currently bundling up my client up using requires and browserify. I installed gsap using npm install, and it seems to only expose TweenMax. I managed to bundle Draggable using './node_modules/gsap/src/uncompressed/utils/Draggable.js', but hte resulting require('./node_modules/gsap/src/uncompressed/utils/Draggable.js') looks pretty ugly. Furthermore it sees that TimeLineLite is not exposed either, even though it's contained. How can I access the various components using the npm module? Thanks, Sven
  2. Just something to think about... The module issue is not going to go away until the source code is split up into actual modules. I've seen a lot of suggestions on GitHub, but I don't think any of them take into account the future. The JavaScript landscape changes too rapidly to depend on one type of technology. Just look at the decline of Grunt and Bower. Instead of creating modules for a specific loader (AMD, CommonJS, UMD, global), just create ES6 modules and let the user decide on the loader. This is the best way to design for future since it's going to be part of the language itself. To show how this would work, I split the TweenLite file up different modules including: Animation, SimpleTimeline, TweenPlugin, Easings, Ticker, and EventDispatcher. The only changes I really made were to the easings, to allow exporting eases individually because I didn't include the current GSAP way of defining classes. I also added an object called "gs" that get's passed around to the different modules as a work around to all the variables that get reused in the original file. So things like the ticker and rootTimeline instance are on that object. This was a quick proof of concept, and I really didn't do any testing so I might have missed something, but I am able to request GSAP modules in the browser using an ES6 module loader polyfill. This will also work with NodeJS. So now I can request stuff like this... (although I didn't actually do the CSSPlugin) // Get individual components import { TweenLite, CSSPlugin, Power4 } from "greensock"; TweenLite.to(myElement, 1, { x: 400, ease: Power4.easeInOut }); Of course this is only for users that want to use modules. For users that like using source files the traditional way, you could create a "dist" folder with these files already built, similar to current file structure of the src folder.
  3. Can Greensock TweenLite/TweenMax globals be obtained when using the library as CommonJS module? E.g. easing functions that are available as window.com.greensock.easing, like let Power4 = require('./TweenMax')... I feel myself 10 years younger when I look at all these globals. I look at the source code and see that the only export is TweenMax constructor. Can it be done somehow without resorting to globals at all?
×
×
  • Create New...