Asderex

So there's my problem - I'm a dolt!  Thanks Jack. Relieved that my understanding was right but my attention to detail was wrong. Appreciate your response.

Hi,  there is something I am not getting about using flip with getting the starting state of off one element and applying it to another element using FLIP.from.  In the codepen attached I was hoping to see the yellow square animate across from the blue square to the red square.  My understanding was that Flip.getState(startingPosition) saved essential positional properties of the element which could then be applied using Flip.from(savedState, {targets: elementToAnimate, ...}) and GSAP would retrieve the correct saved starting state providing the two elements share the same data-flip-id.

 

I have display:none on the origin element and set it to block just before I save its state.

 

Now, I must be doing something wrong because the tween is instant (not the requested 3 seconds) and the animated element instantly appears. Any suggestions / corrections?

See the Pen WNdENPj by Asderex (@Asderex) on CodePen

3 hours ago, GreenSock said:

Does that clear things up? 

 

As for it not being in the docs, it's frankly quite a tricky balancing act because we want the docs to be rich in information but not overwhelming.

Yes - sure does.  I figured this was probably an edge case given GSAP's user base and the fact I couldn't see anything on it.  Now I know what to look for I wont have the same issue in future.  Understand and agree it probably doesn't warrant addition in the doc's.  Hopefully if (in the unlikely event) someone manages to repeat my mistake googling:

 

Keywords:  added properties delay duration ease overwrite repeat

 

will lead them to this explanation anyway.  Thanks for the reponses everyone.

Hi,

 

This could be an intended behaviour which I hadn't picked up in the documentation so I thought I should post a question.  Is it the intention for GSAP to modify objects passed in as transition properties?

 

In my situation I have a bunch of animation properties for a particular element stored on an object which is used in numerous places.  As per the codepen demo attached you can see the object initialised in row 1 is has been modified by the time it is logged in row 5.   In my programme I map over the same transition object to perform various operations and for the life of me I couldn't figure out where these extra properties were coming from as I assumed GSAP would only modify the DOM element passed in (although the names where a helpful hint).

 

Having located the  bug it was easily fixed with: 

gsap.set(document.querySelector('#TITLE'), {...animationProps})

but I would have thought the original (no spread operator) was a natural way of writing this.

 

Are there any doc's explaining the modification or is this a bug? Thought I might save someone else some pain.... this took an embarrasingly long time for me to diagnose.

 

Thanks

See the Pen rNMOWYE?editors=1111 by Asderex (@Asderex) on CodePen

20 hours ago, GreenSock said:

And then if you've got rotation, skew, etc., it can get mind-bending

.... you're not wrong, scale is more than enough for me .  I've actually found a simpler way off dealing with my specific problem.  I had several nested elements with arbitrary x,y transforms set by the user dragging things around.  I found by rebasing the transforms (so nothing effectively moves on screen but the various transforms are applied to different elements) it makes life alot easier... I even still get to use convertCoordinates.

 

20 hours ago, GreenSock said:

By "janky" do you mean that it animated in a jerky (non-smooth) way or "janky" as in "hacky, non-optimal"? 

I meant "hacky", but the fact that you suggested it as a possible solution made me think it would have been a reasonable approach (I'm a hobbyist at this stuff rather than a professional).  I never actually tried it and it probably would have worked just fine but it felt strange using DOM state as a calculator.

 

Thanks for the responses and for giving us access to these methods - super useful!

Thanks for the reponse Zach and Jack - hmm, it maybe non trivial then as my project requires the current hierarchy of elements.  What I was hoping to do in the example codepen Zach has included was have the boxes rotate and move and the four point shift to their new positions at the same time and not in stages.    

 

It's a very niche requirement and I was thinking about using Jack's suggestion of shifting the parent between screen refreshes and grabbing the transformations before shifting it back for the next screen refresh but it felt a bit janky.

 

The transform I will be applying to the parent elements is scaling so I think it might just be a matter of multiplying the returned transform by the scale factor but I thought I'd check if there was some clever GSAP solution was missing out on.

Hi,  I was wondering if it's possible to factor in an intended transformation of the elements into the getRelativePosition or convertCoordinates methods.

convertCoordinates doc's

 

For example, in the demo video for convertCoordinates the video shows a fromElement and a toElement which transform by a random scale, rotation etc. and then tween the child element into position using the newly transformed parents.  My question is "is it be possible to tween the transformation of both the parents and the child elements at the same time so everything moves synchronously?". (Sorry - I wanted to link to the codepen here but could find the one I was looking for from the video)

 

I can't see how I could do that right now as (as far as I can tell) any elements passed into getRelativePosition or convertCoordinates need to be in a 'final' position i.e. these functions return a transform for where the elements are and not where they are going to be.

 

note: I've seen the 'arm and joint' getRelativePosition demo which uses 'onUpdate' to remap the the arms start position.  This could probably be used but it just seems a bit inefficient to continuously recalculate the necessary transform on ticks of the parents tween when we should be able to calculate the final position at the outset using the current positions and intended transformations.

 

Any thoughts on how this might be achieved? Maybe some clever matrix composition?

Facepalm ........ The correct answer was to use {base: -500, amount: 500}.... of course I thought of this after posting the question.

Hi,  I am trying to use the GSAP distrubute utility function to add negative z axis transforms to a bunch of elements (i.e. project away from the viewer).  I have used the following tween:

 

gsap.to(".staggerBackward", {
                z: gsap.utils.distribute({
                    base: 0.0,
                    amount: -500,
                    from: "end"
                })
            })

This results in GSAP applying positive z axis transforms to all .staggerBackward elements (i.e. toward the viewer).  I tried changing the amount to a positive but this results in more positive transforms but this time in the opposite direction.  Any ideas what I'm getting wrong / not understanding about this one? Thanks in advance

See the Pen jOWNKaN by Asderex (@Asderex) on CodePen

Right you are.  I forked a simple codepen and after updating the GSAP reference I can now see the expected perspective function in the transform.  Thanks for the tip.

47 minutes ago, ZachSaucier said:

Hey Asderex, I think you're looking for the transformPerspective property in GSAP  

Ding Ding Ding! We have a winner! - Thanks Zach, thats exactly what I was after.  I'm not sure how close you are to the development of GSAP but I had a quick play in codePen and noticed that rather than adding a perspective function to the transform it rolls it all up into a matrix3d operation.  Do you know if this done for performance reasons?

Hi,  I have some elements undergoing a z axis transform but I need them to maintain their own perspective (using the perspective function on the transform as opposed to using the perspective property of their parent element).  When I perform a vanilla z axis animation GSAP will add something like the following style tag: style="transform: translate3d(0px, 0px, 200px)"

 

I was thinking maybe there might be something I could do with the modifier plugin but this seems to allow modifying values before they are concatenated into a templated style update.  Does anyone know how I could include a perspective function in the transform. e.g. style="transform: perspective(90px) translate3d(0px, 0px, 200px)"

 

The Mozilla docs use a perspective function in their translate3d reference so it should be valid. I'm just not sure how I can get GSAP to include this modifier.

 

Any thoughts good people of the Greensocks forum?

Thank you @Rodrigo for pointing me in the right direction and @OSUblake for getting me over the line. Looking at the forums and I have to say GSAP has a very helpful community here.

Thank you both for coming back with suggestions!  I looked into forwarding refs (great suggestion).  I was worried about putting behavior/logic related to the children into the parent component so I thought I could create a forwarded ref for the parent component and pass this same ref down to the children to use as the "bounds" property.  Demo.

 

I think that in my original example the Draggables were being created before the DOM was actually rendered.  The elements therefore didn't exist which is why @OSUblake noted he couldn't see the parent element being passed down.  The new solution is showing the correct DOM element in the console but I still seem to be getting the same weird drag result (exactly 4 x the area of the draggable div's centered on screen).

 

I could try your original suggestion @Rodrigo (forward refs from the parent to the children and define the draggable in the parent) but I'm not sure how to handle the case of an arbitrary and dynamic number (and type) of children being added to the draggable area i.e. Could be 4 squares, then 2 Circles could be added, the 3 triangles....it can't be defined at design time.

 

And apologies -  I had it in my head that the second example in my original post was a nested react component but it's not, it's just a single component so I don't think the class / functional debate comes into it.  Thanks again for your suggestions.

 

 

Hi

 

Just discovered GSAP and what a great library it is!  I am having a problem with bounding my draggable components in my React testing.  I have followed the great instructions found here (https://greensock.com/react) to get a reference to the React generated DOM element and haven't had any problems making them draggable. 

 

The draggables sit inside of another React component which should act as the bounding element.  I am again getting a reference to this element as previously described and passing this into the draggable components as props - to be referenced by the draggable childrens draggable.create. This works (in that it doesn't throw any errors and my console logs are showing the correct DOM element being passed in) but the draggable bounds are behaving very oddly.

 

A demo paints a million words so you can see what I mean here (I'm a bit more comfortable in codesandbox.io):

 

The draggable elements appear to be bounded by something (not a DOM element I recognise) that is exactly 4 times their size and not their parent component?

 

I have seen demo's, such as this 

See the Pen dvgePz?editors=0010 by expdev (@expdev) on CodePen

where they are successfully bounding a child react component in its parent.  The only obvious difference to me appears to be the use of a class component over a functional component but, again, I'm not sure why that would make a difference?

 

Note: I'm not adverse to using a class component but would love to understand why this is behaving the way it is. Any tips or suggestions welcome!

See the Pen by s (@s) on CodePen