dude

Okay, I figured out the issue... sort of. Because now I don't understand why my react example in the codepen did work lol! To summarize the issue I was facing was that instead of animating between the before and after state, it would wait for a bit (the duration time) and then suddenly it would update the visualization to the new state. In my first attempt to leverage in react, I was doing this: ``` function MyComponent() { const [pos, setPos] = React.useState(true); const handleClick = () => { const state = Flip.getState('.panel'); setPos(!pos); Flip.from(state, { duration: 1, absolute: true}); } return (///) } ``` I was able to get it working by doing this instead: ``` function MyComponent() { const [pos, setPos] = React.useState(true); const state = React.useRef(); const handleClick = () => { state.current = Flip.getState('.panel'); setPos(!pos); } React.useLayoutEffect(() => { if(state.current) { Flip.from(state.current, { duration: 1, absolute: true}); } }, [pos]) return (///) } ```

So unfortunately, I am having the same issue that was showing up in codesandbox in my local env... @ZachSaucier have you had any insights on why the Flip plugin might not work in certain environments?

Ah, nvm this is just an issue with codesandbox apparently.... works fine when i replicate it in codepen.io https://codepen.io/duders/pen/GRQRjjR

Hi I'm trying to animate the grid layout without success. Any suggestions? https://codesandbox.io/s/quirky-jang-5lc4ey?file=/src/styles.css:80-84

What about instead of on each tick, just on each piece of the timeline (each "to", "from", "stagger", etc). Or does that come out to the same thing in terms of how it'll run? In general, yes. But, as stated above, it would be good to do all of these adds before running the tl. There are work arounds for adding to timelines mid animation but it is not recommended. Ok, a quick clarification. And to do so I'm going to make a crappy diagram (below). The verticle line represents a master timeline (tl0), and the horizontal lines represent nested timelines (tl1, tl2, tl3, tl4), which are returned by calling their respective functions (fn1, fn2, fn3, fn4). tl0 | |_____ fn1 -> tl1 |__________ fn2 -> tl2 |________ fn3 -> tl3 | |_______________ fn4 -> tl4 suppose fn2 does some dom manipulation before starting the timeline (tl2) and returning it. If this function were to be executed on its own (not as part of tl0), this should count as doing all the dom stuff before the timeline (tl2) runs, correct? What about once it's nested inside tl0 though? Technically tl2 is a different timeline object than tl0, so would this be allowed (so long as I make sure none of the other timelines need the removed dom elements)? If this is still too confusing and you want me to just put together a code example, let me know. And thanks for taking the time

Yeah I saw that one, great article! I'm glad you pointed it out again, because I was looking for it actually. Definitely want to spend some more time analyzing it. And thanks for the answer. More or less what I figured, but wanted to double check with the experts

Definitely nifty, but doesn't really address my fundamental question. Will keep be keeping in my back pocket though

Hi, I'm working with timelines, and after certain steps, it sometimes makes sense to add / remove elements from the DOM. Something like this: tl.to('.element', 1, { /*params to change*/}) tl.to('.element', .5, { /*params to change*/, onComplete: () => //figure out if i need to add some elements and then add them }) tl.to('.newElements', 1, { /*params to change*/}) I was facing problems for a while where nodes I added ('.newElements' above) wouldn't animate. Eventually I tried adding those elements before the animation started, with an opacity of 0, and then just animating them in at the appropriate time afterwards. This fixed the issue. Is this the appropriate way of doing things, or can I in-fact add elements during onComplete callbacks, mid-timeline, and then animate on those newly added elements? And if I must have elements in the DOM before starting an animation / timeline that will eventually use them, what are the ramifications of this for nested timelines? I've been working on breaking up some of my animations into smaller pieces, that can then be reused and hacked together in different ways (see this post). Some of those discreet actions, inherently require DOM manipulation. So for example if I want to update a chart with new data, I may need to add some elements first. So lets say I have a updateData function that: checks the DOM for what is and isn't there adds new elements if there isn't already an element in the DOM for each of the data points that needs to be represented updates elements that already exist but whose data has changed removes elements that are no longer needed. This function in the end, returns a timeline. Could I then nest this timeline inside another timeline like so..? //tl is a timeline to update all charts at once tl.add(updateChart1()) tl.add(updateChart2()) tl.add(updateChart3()) ...Where each updateChart# returns a timeline that also had code adding and removing elements.

Hi, I'm curious about the performance penalties (if any) of how I'm abstracting out some of my animations into discreet timelines. Consider the following: Fig 1 //timeline setup plus some animations before this part tl.to(['.group1', '.group2', '.group3'], 1, {autoAlpha: 0}) // some animations after this part The above would be a part of a larger timelined animation. I have many animations, triggered under different events, that operate on common constituent elements (ex: group1 elements, group2 elements, group3 elements). Across these animations, many of the things I need to do with these elements and/or groups of elements are repetitive, so I was thinking to abstract out an API of sorts (basically a bunch of organized discreet timeline functions). So for example, my code structure for a given element / group of elements that would need to commonly be operated on might look like this: fig2 Example Folder Structure: -animations ---parts -----group1 //animations group1 has to do alot -------enter //animations for bringing group1 in ---------fadeIn.tsx ---------fadeAndFlyInStaggered.tsx ---------aMoreComplexTimleinedAnimation.tsx -------update ---------wiggle.tsx ---------jiggle.tsx -------exit ---------fadeOut.tsx -----group2 -----group3 The same pattern (enter/update/exit) would be there for each group, and each tsx file exports a function that returns a timeline. The benefit of this being that then I can have a higher level animation timeline that isn't so long, and easier to read. Perhaps something like: fig3 tl.add(parts.group1.enter.fadeIn(...params)); tl.add(parts.group2.enter.fadeInStaggered(...params)); tl.add(parts.group1.update.reflectNewData(...params)); // maybe more stuff depending on complexity This makes my life way easier, prevents repetitive code, makes code more maintainable / readable, and allows me to isolate implementation details from the larger high-level orchestration of the animation. If I was doing purely GSAP stuff it may not have been so bad, but often times I need to set classes, change classes, get positions of things, add remove elements, etc. All that takes up space and makes things harder to read / maintain. So I really like the idea of timeline abstraction. I am however new to it. As I go about working on the abstraction defined above, I started thinking there could be some trade-offs. Consider Fig4 below, against Fig1 above. fig4 tl.add(parts.group1.exit.fadeOut(), 'timeToLeave') //fadeOut transitions to autoAlpha = 0 and removes the element(s) if a flag is set to true tl.add(parts.group2.exit.fadeOut(), 'timeToLeave') tl.add(parts.group3.exit.fadeOut(), 'timeToLeave') Where as before this was a single tl.to ..., now I have three seperate timeline.add(anotherTimeline) lines, that I have to coordinate start times with ('timeToLeave' marker in fig4). My question is: Question: Is there a performance penalty for doing things the fig4 way vs fig1? Or is this something that GSAP optimizes for?

Hi, I'm curious about whether something I'm doing in svg will be possible in PIXI. I'm building complex svg diagrams that animate, but also with aspects of them that I want to be able to animate zoom on, (almost) infinitely (think Mandelbrot set like zoom but data-visualization related). Currently I'm using svg for that infinite scaling capability, but I know that for some of my data sets, svg isn't going to cut it eventually. It'll just become too much weight on the DOM / CPU at some point as there will simply be too many things on the screen to render, forget animate. I could look into things like tiling, but that has a pretty huge performance / usability penalty for my use-case. Also, the complexity and detail of what I need to visualize isn't so great as that of a map either. Also, I'd still need to animate aspects of the visualization, which isn't usually necessary with tiled maps. I'd like to switch to leverage a gpu based solution like PIXI down the line. The only problem is that PIXI doesn't really preserve the scalability aspect of svgs (not at all a PIXI expert, have only built some simple circle animations to test with). I'm pretty confident that minus the zoom functionality, PIXI+GSAP will be a good solution for every other aspect of the rendering / animation, but do you know if there is a way to leverage all the GPU powered goodness of PIXI but still preserve the sharpness of images and text as a user "infinitely" zooms in? (10x, 100x, 1000x scale of original)?