different timelines mobile / desktop with gsap matchMedia

[emjay]

Hello GSAP friends,

 

with great pleasure I read the blogpost about GSAP 3.11. I wanted to test the new matchMedia function with a small project.
And this worked great, I was able to implement my small test project.

 

However, I have a problem when I change the viewport in width (scale window) and thus a change from mobile (< 1000px) to desktop (> 1000px) or vice versa takes place. The animations are then directly broken. When I reload the page mobile everything works fine, desktop the same. Only when switching unfortunately not.
 

I think it is related to how I define the timelines. Currently I think it is totally wrong, because with every click a new timeline is created. Of course this doesn't make sense, but when I tried to outsource this, i.e. to create a timeline for mobile and one for desktop, I didn't get a functional result.

Now I hope you can give me a hint how and when to create the timelines. So that everything works seamlessly, even without reloading the browser.

this is how it looks < 1000px:


this is how it looks > 1000px:

 

Due to the different layouts for mobile and desktop, I also needed different timelines to make different animations. But just look at the pen, there you can understand it well.   

 

Thanks for your input.

See the Pen 9c4c7f7ef3d2803ed54833134d37a60a by emjay (@emjay) on CodePen

[Rodrigo]

Hi @emjay,

 

The main problem is that you are not removing the event listeners when the breakpoint is passed. Also, in order to prevent a click event when the animation is running, I normally use a boolean that is toggled when the animation is completed.

 

This seems to work the way you intend:

See the Pen gOzdjJw by GreenSock (@GreenSock) on CodePen

 

Let us know if you have any other questions.

 

Happy Tweening!

[GreenSock]

Actually, in addition to what @Rodrigo pointed out (remove the event listeners), you were creating the animations OUTSIDE the context. It only records the animations that are created while that context function is executed, but you set up functions that create them later based on click events. By that time, the context function has FINISHED executing, thus it won't record those.

 

But don't worry, there's a solution - we've already thought of this

 

There are actually two ways to do it. One is to context.add() a named function that you can call later, as illustrated here: 

context.add("prevImage", (event) => {
  // create your animations in here
});

element.addEventListener("click", context.prevImage);

 

See the Pen 7cff26b41358035a21e1ca2a81668c94?editors=0010 by GreenSock (@GreenSock) on CodePen

 

The other way is to add() things immediately, so do it inside your handler: 

let prevImage = function(event) {
  context.add(() => {
    // create animations in here
  });
};

element.addEventListener("click", prevImage);

Basically you've just gotta make sure you're associating the animations with that context so that they get reverted. 

 

Does that help? 

[emjay]

Hey @Rodrigo @GreenSock,

 

thank you very much for your input this helped a lot, I used the boolean toggle and also dived deeper into the topic of contexts.

 

I also created an autoslide mechanism with setTimeout but have done this outside of the context. 
 

var timerHandle = setTimeout(() => context.nextImage(),3000);

function resetTimer() {
    window.clearTimeout(timerHandle);
    timerHandle = setTimeout(() => context.nextImage(),3000);
}

Unless you have something against it.

Here again is an updated pen, may it help other people who have similar questions:

See the Pen ac6e2b9720ddea33973fa37b61082c68 by emjay (@emjay) on CodePen

[GreenSock]

9 hours ago, emjay said:

I also created an autoslide mechanism with setTimeout but have done this outside of the context. 
 

var timerHandle = setTimeout(() => context.nextImage(),3000);

function resetTimer() {
    window.clearTimeout(timerHandle);
    timerHandle = setTimeout(() => context.nextImage(),3000);
}

Unless you have something against it.

 

That's fine, but I prefer to leverage GSAP so that it's always synchronized with repaints/animations: 

let autoAdvance = gsap.delayedCall(3, () => context.nextImage());

// then instead of resetTimer()...
autoAdvance.restart(true);

That way, you can also pause() it if you need to or whatever. Less code, more flexible, better synchronization. But your setTimeout() is fine if you prefer that. 

[emjay]

Hello @GreenSock,

 

that's really great. Thank you very much for pointing that out.