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,855 Superhero

About Rodrigo

  • Rank
    Advanced Member

Profile Information

  • Gender
  • Location
    Santiago - Chile

Contact Methods

  • Skype

Recent Profile Visitors

23,717 profile views
  1. But if the event target is a node (which is normally the case) you can use parentNode to get the parent element. parentElement is not supported in IE if the target is an element. On the other hand if you're using react why not create a ref for the title element you want to select and use that to get it's content: // In the component's logic let handleClick = () => { console.log(this.myTitle.innerHTML); } // In the JSX <title ref={title => this.myTitle = title}>Title Text In Here</title> Even if you're dynamically adding DOM elements to the JSX, you can still find ways to create a ref and target them in an event handler. As Blake mentions a reduced live demo in codesanbox or stackblitz would be very helpful to see what you're trying to do. Happy Tweening!!!
  2. Mhhh... so this is like Gatsby but in Vue, right? I was wondering when that would happen For what I can see here: https://gridsome.org/docs/pages/#file-based-pages the structure is the same as in any regular Vue Single File Component, so using the regular syntax in it (like in Gatsby) to create your GSAP instances, using refs and everything else, should work like any other Vue App. As a personal opinion is great to see Vue growing like this, hopefully Aurelia follows as well so at some point in our lifetime we could work with standard web components and not singular-opinionated components, I know @OSUblake would also be a happy camper at that point Happy Tweening!!!
  3. Hi and welcome to the GreenSock forums. Yeah, indeed GSAP clearProps: "all" removes all inline styles, so it is affecting the styles applied in the JSX as well. If possible target only the props affected by a GSAP instance in order to keep the ones present in the JSX: gsap.to(this.box, { duration: 1, delay: 1, rotation: 180, x: 100, y: 100, onComplete: () => { gsap.set(this.box, { clearProps: "rotation, x, y" }); } }); That will only remove Rotation, X and Y while not affecting any other inline styles. Finally if possible, yeah I'd try to keep everything in a CSS file, is far simpler (especially for complex animations) to just remove all inline styles rather than typing all the ones that should be removed, the latter is more prone to errors. Also as a personal preference I don't like adding styles to the JSX unless I have no other choice, the code looks messy, but that is just my opinion. Happy Tweening!!!
  4. 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?
  5. 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!!!
  6. 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!!!
  7. 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!!!
  8. 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!!!
  9. Now it works https://codepen.io/rhernando/pen/ExxGRVJ Thanks Jack!!! ???
  10. 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!!!
  11. 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!!!
  12. 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
  13. 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
  14. 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!!!
  15. 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.