Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

Rodrigo last won the day on November 10 2019

Rodrigo had the most liked content!


  • Content Count

  • Joined

  • Last visited

  • Days Won


Rodrigo last won the day on November 10 2019

Rodrigo had the most liked content!

Community Reputation

2,843 Superhero

About Rodrigo

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Santiago - Chile

Contact Methods

  • Skype

Recent Profile Visitors

23,416 profile views
  1. I'm sorry but what exactly is the problem with using classes for some components in a React app, and in general on any JS app?
  2. As Zach points the issue becomes the state update. The ref is not kept for subsequent re-renders by react, since the DOM element has actually changed because is a React component instance (styled component actually). The solution is to add a bit more boilerplate to your code using the useRef hook in order to persist the DOM node reference through re-renders. As you can see is not a lot of code so the overhead should be unnoticeable: https://codesandbox.io/s/draggable-problem-v05-hcq2r Happy Tweening!!!
  3. Since the update is via props from a parent component, so you should be adding that to your test code, the problem is testing the actual rendered output in the child component. See why I'm not really a fan of testing in React? things get really messy in a blink of an eye Lucky for us testing library has a way to try that using the rerender method for that. About the timers, yeah you have fake and real timers in Jest but I've never used them so I can't really help you with that. Like I said I don't test GSAP instances in React components. An alternative I normally use is to add either a custom attribute (not ideal) or an aria attribute. Since there is nothing wrong with adding accessibility to our apps and what you have here is a toggle element you could use a switch role and the aria-checked attribute (true/false) to check the prop update on that attribute as well. Also since you're using version 3 of GSAP, you can use async code, since you can return a promise from a GSAP instance now, that could be a cleaner and simpler way to test: https://greensock.com/docs/v3/GSAP/Tween/then() Happy Tweening!!!
  4. Hi, Welcome to the GreenSock forums and Happy New Year!!! I actually never dealt with something that specific such as checking for a single value in such way. When dealing with TDD I try to keep GSAP instances out of it because is not actually that trivial to do it. Keep in mind that React is basically used to create UI's, hence any TDD using it should consider that there is an effect to any update in the app state that can be checked. In this particular case you're checking an attribute of an SVG element so you can use the toHaveAttribute expectation given by jest-dom, all you have to do is query the target element and check the attribute value. Also in your code you have this for the initial set up: { value = false, onClick, scale = 1, radius = 16, length = 120, borderWidth = 1, borderColor = '#333', knobColor = '#c0c0c0', onBackgroundColor = '#228b22', hasBoldText = false, onTextColor = '#ffffff', offBackgroundColor = '#b22222', offTextColor = '#ffffff', duration = 0.5, style = null, } And this for rendering the text element: <text ref={onTextRef} id="on-text" x={-(length * 0.5)} y={radius * 1.42} fill={onTextColor} fontSize="20" fontWeight={hasBoldText ? 'bold' : 'normal'} stroke={borderColor} strokeWidth={borderWidth / 2} > OPEN </text> So the initial position is -(length * 0.5) and that is -60. Nowhere in your code I see anything that changes the initial position of onTextRef to a positive value. Please try to create a Codesandbox sample since you can include testing there as well, in order to get a live editable code that we can look at. Finally I'm not very fond of TDD everything in React since it forces to add a bunch of extra code and boilerplate in the JSX and sometimes the logic of components that is not really necessary beyond testing that some part of the component is rendered or not due to some data received from a server request or a specific user interaction. Honestly I'd like to think that the fact that you can encapsulate your components (even re-usable ones) should be enough for securing that extending a component doesn't create issues. As a personal opinion I'm not really a big fan of TDD since a code that is well written doesn't need a safety net to work, but is a trend now a days so we're forced to follow it whether we like it or not. Happy Tweening!!!
  5. I'll take a look at it a bit later. Perhaps is something related to the newer versions of React or specific of Gatsby, although I found the latte more improbable, since the warning (I assume that you're getting a warning in the console) should be comming from React. Another chance is to check the conditions with && instead of || since if one of the conditions is falsy but the rest are truthy the entire conditional block returns true: var a, b; // both are undefined at this point b = 1; // a is undefined it returns truthy, b is defined returns falsy // the entire block returns false if (!a || !b) // -> false // the entire block returns true if (!a && !b) // -> true Try that and let us know if there is any difference, I'll check some samples here in my machine and see what comes out of it. Happy Tweening!!!
  6. Now it works https://codepen.io/rhernando/pen/ExxGRVJ Thanks Jack!!! ???
  7. Hi, can you provide a reduced live sample in codepen that illustrates just the issue you're having? So we can take a better look and understand the issue. With the information you're providing right now is really hard (at least for me) to get a good idea of what you're dealing with. Happy Tweening!!!
  8. Hi and welcome to the GreenSock forums. This sample covers using GSAP callbacks to update app or component state: https://stackblitz.com/edit/gsap-update-state?file=update-state.js Now considering that you need to update the state midway through a GSAP timeline it might not be the best approach. What I can recommend is to use a .call() instance in the timeline in order to use the setState() method and you can use the position parameter to define when the state will be updated. Also you can use .add(gsap.delayedCall()) if you want as well, with a specific delay in it. Happy Tweening!!!
  9. Mhhh.... yeah you're right about that, it seems the real issue here is mixing from instances with clearProps in V3 creates a different effect that in V2 From instances with clearProps V2: https://codepen.io/rhernando/pen/oNNJygN?editors=0010 From Instance with clearProps V3: https://codepen.io/rhernando/pen/ExxGRVJ?editors=0010
  10. Actually clearProps is working at the start of the animation and is quite logic if you think about it. You have a DOM element and it's natural initial position is x: 0, then you use a from() instance in order to animate such element from x: 100% to x: 0 (initial position), the element is moved to x: 100% and then animated to 0. Then in the out animation you have a to() instance that moves the element to x: 100%. If for some reason the from instance is started when the value of x is not 0 the animation will end in the value of x it has when it was created, right? clearProps to the rescue!! clearProps removes all inline styles applied by GSAP so the element returns to it's initial natura position, that is x: 0, then the from instance moves it to x: 100% and animates it back to x: 0. The from instance is setting the position of the element, not the clearProps in the config object. But clearProps is the reason why you're seeing that particular jump in this case and why using a set() instance and then a regular to() instance doesn't create such issue. The big question is why this differ from V2? We'll summon our beloved Tween Lama @GreenSock so He can enlight us all and clear this doubts
  11. Rodrigo


    Just remove the position parameter in the drag end callback: onDragEnd: function(e) { $("#drag1").removeClass("invisible"); if (this.hitTest("#target2", "30%")) { tl .to(box, 0.1, { rotation: 15 }) // in this instance no position or repeat delay .to(box, 0.1, { rotation: -15, repeat: 2, yoyo: true }) .to(box, 0.1, { rotation: 0 }, "+=0.1"); TweenLite.to(e.target, 0.2, { x: 0, y: 0, top: 0, left: 0 }).delay(0.5); } if (this.hitTest("#target1", "30%")) { TweenLite.to(this.target, 0.6, { opacity: 0, scale: 0 }); TweenLite.to("#drag1", 0.6, { opacity: 1 }); } else { TweenLite.to(e.target, 0.1, { x: 0, y: 0, top: 0, left: 0 }); } } It seems that the position parameter is messing things up after the first run, also I don't see the need to state a repeat delay of 0 seconds, that is basically the default. Finally you're using the same method on all the drag end callbacks, you can easily create one method and pass it directly to the callback. Take a look at this: https://www.drycode.io/ Happy Tweening!!!
  12. Rodrigo


    From the link you provided I'm seeing this: In the index page appears a picture of a woman but there is nothing draggable there neither. Regardless of the content the codepen sample allow us to take a look at your code, play with it and try to figure and solve any possible issues.
  13. Rodrigo


    Hi, what are we supposed be looking at? Nothing is moving in the sample you provide and nothing can be dragged as well. Please create a reduced sample that points out just the issue you're having in codepen so we can take a better look: Happy Tweening!!!
  14. Not to be stubborn about this, but the sequence of using a from() instance with clearProps in it is somehow close to this: clearProps will remove all inline styles from the DOM element, then GSAP records the initial position of the element, sets a new position to the one pass in the config object and finally tweens the properties to the initially recorded values, so using a set call at the start of the timeline is not very different from that. Just my two cents on the subject. Happy Tweening!!!
  15. Hi, I remember running into a similar issue in a project working with React Transition Group (keep in mind that RTG and Vue transition work in a very similar fashion as both are heavily inspired by earlier versions of angular's ng-animate). The issue is the initial position of the elements when the animation starts, that's why you add clearProps: "all" in your tweens. A good solution is to remove clearProps from the config and add a couple of .set() instances at the start of the timeline in order to give the initial state to the elements being animated, a bit like this: return gsap.timeline({ onComplete: done }) .set(this.$refs.container, { xPercent: 100 }) .set(this.$refs.overlay, { opacity: 0 }) .to(this.$refs.container, { duration: this.enterDuration, xPercent: 0, ease: 'power3', }, 0) .to(this.$refs.overlay, { duration: this.enterDuration, opacity: 0.65, }, 0); The overhead of using this approach should be virtually none, so you shouldn't have any performance issues. I don't have time to create a full working Vue demo, so I made a simple codepen demo instead: https://codepen.io/rhernando/pen/JjjeNQN?editors=0010 Consider the first click of the show sidebar as the moment when the element is mounted, for the purposes of this situation just imagine that the sidebar and overlay are not visible when the code runs for the first time. Happy Tweening!!!