Looking for some pointers on ScrollTrigger example

[bp-lp]

I have a relatively simple ScrollTrigger Nuxt example here : https://stackblitz.com/edit/nuxt-starter-sjp5s3?file=pages%2Fabout.vue

To view - navigate from home to about and scroll down.  Just a note - this example only fires ScrollTrigger code after a page transition in watch()
 

Ultimately I'm wanting to pin each left and right side in the center of the screen and then show progress of the pinned scroll section on the right.
Very generally this is functional, but I feel there's a lot that is off.   I feel like there's likely some better approaches with css (assets > main.scss) and js here.

Two questions : 
1) left side (it) :  I feel there should be a way to set the end to the bottom of the parent wrapper instead of this +=699 nonsense, I'm just not sure how to accomplish this.  Everything I have tried didn't seem to function.  

   ScrollTrigger.create({
      trigger: '#it',
      scrub: false,
      pin: true,
      start: 'top 25%',
      endTrigger: '#next-section',
      end: '+=699%',
    });

2) On transitioning away from the About page (after scrolling down to the left / right sections  - post things being pinned ) there is a very noticeable jump in the scroll position as the transition is triggered and Im at a loss for why.  I have added some back to home buttons underneath that section to show this.


 

[mvaneijgen]

34 minutes ago, bp-lp said:

To view - navigate from home to about and scroll down.  Just a note - this example only fires ScrollTrigger code after a page transition in watch()

 

This seems not to be the case for me. I've moved the ScrollTrigger code to the onMounted hook and everything seems to work fine. There is a small delay when I refresh the page and I don't know where that is coming from, but try using other Lifecycle hooks. You can also use refs maybe they are already available on created. 

 

Where does the 699% come from? Because I've changed it to 'bottom' and that also seems to work fine. same as end: '+=100%', end: 'bottom' would be the same and is in my option more readable. I also like to be more specific, so doing end: 'bottom top' naming everything is better in my opinion. Also enabling markers: true, really helps when debugging.

 

https://stackblitz.com/edit/nuxt-starter-yways2?file=pages%2Fabout.vue

 

34 minutes ago, bp-lp said:

2) On transitioning away from the About page (after scrolling down to the left / right sections  - post things being pinned ) there is a very noticeable jump in the scroll position as the transition is triggered and Im at a loss for why.  I have added some back to home buttons underneath that section to show this.

I don't get this question. To me everything looks smooth, maybe you can create a screen recording demonstrating the issue?

 

Hope it helps and happy tweening! 

[bp-lp]

Sorry if the original ask wasn't very clear, here's a video outlining the two issues.  
https://www.loom.com/share/0773b7d4fea447ebbc9def07b21101bd?sid=ad606f5e-d6b2-4d1c-9124-4664c5d9b858



 

[mvaneijgen]

Ah I see, I didn't figure out that it was the literal word "it", my bad. 

 

Let's focus on one issue at a time. The order in which ScrollTriggers are created is important. Because ScrollTrigger 4 will need to add some pin spacing, but then the calculations will be off for ScrollTrigger 1, because that one doesn't know everything has shifted. You can fix that by changing the order in code, calling ScrollTrigger.refresh() when everything is done loading or setting a refreshPriority see the docs https://greensock.com/docs/v3/Plugins/ScrollTrigger

 

I've also set the end to be the end value of the last scrollTriggers.end, this way we can be sure it they end at the same time.

 

https://stackblitz.com/edit/nuxt-starter-yways2?file=pages%2Fabout.vue

 

I've not yet looked in to the page transition, but as I said lets tackle one issue at a time.

[bp-lp]

I follow the logic on the ordering and making use of ScrollTrigger.refresh(), makes sense and definitely solves the first issue.

I didn't realize we could do things like this 

 end: last.scrollTrigger.end,

👆that's fantastic.
 

[mvaneijgen]

18 minutes ago, bp-lp said:

I didn't realize we could do things like this

That is the beauty of GSAP everything is possible!

 

Maybe it is even better to do 

end: () => last.scrollTrigger.end,

Now it is a function based values and will recalculate on screen resize. But you can literally do anything calculate really complicated offsets that way. 

 

I'm looking in to the #transition-overlay but StackBlitz is coming up with "Failed to boot WebContainer" and it is not letting me do anything. What I was thinking is that both onEnter and onLeave are animating the same element, maybe it is better to have two elements #transition-overlay-onEnter and #transition-overlay-onLeave, that way GSAP is not animating the same element which is preferred most of the time, so let one element handle the onEnter transition and the other the onLeave and then remove them as soon as they are done. 

[bp-lp]

I haven't made much progress into identifying what is causing the page jump other than it appears to be directly related to something I'm doing with scrollTriggers on the about page.

 

I added a ton of logging and an extra few pages in the stackBlitz example and I'm seeing the following.

Transitions to any combination of pages that are not the about page seem to function fine without a hitch on the scroll when navigating to a new page and firing the page transition (index to long, long to longer, longer to index, etc).   It doesn't seem to be the single #transition-overlay element in the page transition onEnter onLeave events. I made the transition overlay hot pink so it's visibly noticeable.

I'm noticing some interesting numbers when logging the scroll on the about page (attached).

if I comment out the scroll triggers from 63 to 114 on about and run the page,  the transition issue isn't there anymore.


 

[Rodrigo]

Hi,

 

Sorry for the late response. This particular thread triggered something I had in my todo list for quite a bit. It involves two things a working example of ScrollSmoother in Nuxt using layouts and overlay routes transition.

 

Unfortunately I haven't been able to complete it yet (hopefully tomorrow will be ready) in order to see if the issue happens in my example as well and if not suggest you a better way to approach this.

 

Please stand by and thank you for your patience so far, just wanted to let you know that your issue hasn't gone unnoticed! 👀

Happy Tweening!

[bp-lp]

No worries on the timing, I appreciate any and all guidance.   This forum has been a wealth of knowledge and I've found out a ton of great info while working through it.

[bp-lp]

Some minimal progress on my side but I have some questions / observations related to the way I have structured these tweens and scrolltriggers.

I've managed to track it down the issue to the following code
 

     gsap.from('.progress-1', {
          scrollTrigger: {
            trigger: '#sticky-1',
            scrub: true,
            pin: false,
            start: 'top 25%',
            end: 'bottom 25%',
            markers: true,
          },
          scaleX: 0,
          transformOrigin: 'left center',
          ease: 'none',
        });

A few things I am noticing: 
-- If pin is set to true, I see the page jump when navigating to another page, if pin is set to false I do not see the page jump issue.
-- if pin is set to false, I see the animation progress finish when navigating to another page - meaning the tween completes as if the end position was met with the scrollTrigger -- not sure why this is happening, but I expect this may be the cause of my issue.  When the item is pinned and it jumps, it's jumping to where the animation end spot would be as if the tween had been completed.

I assume I am missing something obvious about the way I have this structured.

Here's a video with some detail of what I'm seeing, and the latest StackBlitz example I'm working in.
 

[bp-lp]

@Rodrigo I noticed the same or seemingly similar issue to my issue in one of the the Nuxt starter examples and sorry I didn't realize this before.

To view the issue in the starter example.
1) Click over to the layers page
2) Scroll down at least one pinned section 
3) Navigate away to Boxes or Scroll Trigger pages (You will see the pinned sections jump to the previous section when you navigate away from the page). 

Meaning if you have scrolled down to section two, and you click a nav item, you will immediately see section one on screen before the page transitions. If you are on section three, you will immediately see section two when you click on one of the nav items, etc.

I think the ctx.revert() is getting called before the page transition completes.   I forked the starter with some logging here : https://stackblitz.com/edit/nuxt-starter-xxh6yq?file=helpers%2FtransitionConfig.js

Main question is - is it possible to prevent ctx.revert() from executing until each page transition is completed?  I was under the impression the the page transition was more or less stopping other execution until done() was called during onComplete.    

Secondarily and I feel like this may be a stretch, when there is a scrolltrigger using pinning is there was to force it to pause so on ctx.revert() it doesn't change position on screen.

 

[Rodrigo]

Hi,

 

Sorry for the late response, this was indeed a hunt for a lot of when

 

As you mention this boils down to when each part of the code should be called, when the ScrollSmoother instance should be killed, when created again, when the ScrollTrigger instances on each page should be called (which should happen after the ScrollSmoother instance is ready).

 

I haven't had the time to dig into your code, but my main guess is that the issue in your case lies in the fact that you based it on an example that doesn't use an overlay to cover the pages. That example animates the pages, your approach doesn't need to animate the pages, for this approach it boils down to tell Vue/Nuxt when to unmount the page, which is after the overlay-in animation is completed. After that you have to kill the ScrollSmoother instance. Now here is when (yet another one ) it gets complicated, becase for some reason the page is actually mounted before the animation is completed (if you console the onEnter of the animation config and the onMount of every page, you'll see it ). The challenge becomes when we create the ScrollSmoother instance again and then tell the pages that is OK to create the ScrollTrigger ones.

 

I created this example that seems to work so far:

https://stackblitz.com/edit/nuxt-starter-eswqwb

 

You'll find a Route_Change_Sequence.md file in there with the whole explanation of the sequence and the code is thoroughly commented so it should be easy to follow.

 

Finally I'll explore another option that involves using the onEnter hook of the transition config, in order to see if I can simplify the whole watchers mayhem the example has so far, especially on the layout page.

 

Hopefully this helps.

Happy Tweening!

[bp-lp]

Wow thanks for the super thorough walkthrough here, I definitely appreciate it. 
 

Quote

I created this example that seems to work so far:

https://stackblitz.com/edit/nuxt-starter-eswqwb

I did notice that the scroll trigger hitch I've been so stuck on is still evident in this latest example - video showing this here.  Both of the pinned titles on the contact page exhibit the jumpy behavior I've tried to outline in the previous posts / videos.   

To see it : 
If you navigate to the contact page in the example, scroll down to the first pinned title (CONTACT PAGE SECTION ONE), let it pin but keep it on screen so it's still visible, then navigate away by clicking a different nav item. You will see that the title will jump up on the page.

I'll dig deeper into the example to pick apart the transition logic to see if I can get something going.   

[Rodrigo]

Hi,

 

Yeah the problem is that the onUnmounted hook is running before the overlay animation starts. Maybe add another property to the composable to know when the animation is completed and try to run the revert method in a watcher instead of the unmounted hook.

 

I'll look into this later and come back with an update.

 

Thanks for reporting.

Happy Tweening!

[Rodrigo]

Hi,

 

I had a better look at this and it seems to me that the issue could be related to some odd way Nuxt is handling routing.

 

I tried the watcher approach but watchers don't fire after the unmount hook has been triggered, so the only way I found to make it work is to add a delay to the revert method in the unmount hook that is equal to the overlay in animation:

let ctx; // later this is the GSAP Context instance of this page

onUnmount(() => {
  // The duration of the delayed call is equal to 
  // the duration of the overlay in animation
  gsap.delayedCall(0.6, () => {
    ctx && ctx.revert();
  });
});

This prevents the issue from happening. Is ugly and a hack more than a robust solution and I definitely don't like it but so far is the only thing that seems to be working. Of course in your layout you can export the duration of the overlay animation in order to not hard code it on every page or even further you can export a helper method that reverts the context you pass as an argument and import the duration in that particular file, then on every page import that helper method to run it on the unmount hook. I'll update the example and let you know about it.

 

Finally in order to confirm this, I'll create an example using Vue and Vue Router in order to see if the result is the same or not. That should confirm if this is a Vue issue or Nuxt issue.

 

Please stand by and thanks for your patience.

Happy Tweening!