Jump to content
Search Community

a.boeglin67

Members
  • Posts

    1
  • Joined

  • Last visited

a.boeglin67's Achievements

3

Reputation

  1. About GSAP with React. I don't use create-react-app, I have built my own seed that I use and customize with my needs based on the project, it's setup with gulp and I just use webpack to handle the js build process. But when I need gsap it's about as easy as npm install --save gsap and import {TweenLite} from 'gsap'. For compiling size, there are a few useful options and I usually build a vendor chunk which isn't rebuilt incrementally, so I can have a very small app package without the dependencies, and the dependencies in another one, which usually more or less equals the original package size with uglify and other optimisations ( which WP2 does pretty much out of the box by just specifying production build with webpack -p ). About animation, I usually use the lifecycle methods to check if the previous and next props should trigger an animation. If yes, then I trigger it, you can do the same to cancel it. If a part of the animation should change the state, say on complete you want to tell your app state that your view is visible, then I dispatch an action ( redux, so precisely I would have a property call from my dumb view to its container which is bound to the dispatcher and takes care of that, the view knows nothing about the app state ). So the view gets props, knows it should transition from one to the other, say from visible false to true, and emits the change when finished. So my ui state is more or less the keyframes if you want. So in that case, your view could just declare a property onFaceChange: PropTypes.func, and when you're passed 50% you call this.onFaceChange(faceNumber). Your container on top gets that value and takes care of emitting the action to the store. Whatever state solution you use, it's always good to decouple the state from the ui components, but you must know about all this. In your case though, I believe you don't want to emit that change on every update past 50%, so you should have an internal state that somehow tracks if the change has been emitted already. Say at 51% it should emit it, at 52% it shouldn't, if it goes back to 49% it should emit it again.
×
×
  • Create New...