GSAP + ScrollTrigger dynamic sized sections offsetWidth inconsistency

[Banbeucmas]

Hi, I am back trying to make a horizontal layout using GSAP though it doesn't seem to work properly, here is my codesandbox.

https://codesandbox.io/p/sandbox/cranky-leaf-nop4s3

 

The two problem here is 

1. It doesn't seem to respect height: 100% on #page element, I think it's probably due to pin spacer but I am not sure myself. Relevant thread I checked doesn't seem to give me a concise solution

2.  Resize inconsistency. What I expected between resizing is that the scroll should go to the last end of the last section. As it can be seen, the translate() function stops at -2675px while the total calculated maxWidth is 2710px. From App.tsx, I am currently using invalidateOnRefresh for this purpose.

You can see that this becomes slightly more erratic the more you try to resize

 

 

3. This is a probably bit related to 2 but I have no confidence in being able to fully replicate this here. ReactJS seem to act a bit funny with gsap where the xOffset value tends to be inaccurate on first load (Similar demonstration as 2), but once initiating a hot-swap, the values line up.
(Though there are case where one of the element reportedly shows the wrong size on both function until hot swap as well, again, similar demonstration as 2 though this usually happens at the 3rd section for me)

 

I am current at my wit end here, my apologies the code looks a bit messy. And thanks for helping.

[GreenSock]

2 hours ago, Banbeucmas said:

1. It doesn't seem to respect height: 100% on #page element, I think it's probably due to pin spacer but I am not sure myself. Relevant thread I checked doesn't seem to give me a concise solution

I don't see any #page element (no elements with that ID). What am I missing? And the relevant content appears to be 100vh, so I must be missing something. Obviously if you're pinning something, it adds pinSpacing to prevent things from collapsing/overlapping and to stretch out the scrollable area, but you're welcome to set pinSpacing: false if you prefer that effect.

 

2 hours ago, Banbeucmas said:

2.  Resize inconsistency. What I expected between resizing is that the scroll should go to the last end of the last section. As it can be seen, the translate() function stops at -2675px while the total calculated maxWidth is 2710px. From App.tsx, I am currently using invalidateOnRefresh for this purpose.

I read that a few times and I'm still pretty lost. "between resizing" - like between the time you start resizing and stop resizing? And why do you expect it to "got to the last end of the last section" (and could you explain what that means)? 

 

It looks like you're setting the maxWidth variable from within an onRefresh...which runs AFTER all the refreshing is done, but you're plugging that value into the animation's function-based "x". So that value will always be stale. In other words, you've got an order of execution problem there (if I understand your goal correctly). I assume you intended to do something like: 

// old
x: () => `-${maxWidth}`

// new 
x: () => getMaxWidth(sections) * -1

 

2 hours ago, Banbeucmas said:

3. This is a probably bit related to 2 but I have no confidence in being able to fully replicate this here. ReactJS seem to act a bit funny with gsap where the xOffset value tends to be inaccurate on first load (Similar demonstration as 2), but once initiating a hot-swap, the values line up.

What's "xOffset"? I don't see any such value. And what's "hot-swap"? If you're talking about hot module replacement, that's probably a bad idea to rely on that doesn't mimic browser behavior and it's not a "real" way to run things. It's totally unrelated to GSAP/ScrollTrigger - it's a build system thing. 

[Banbeucmas]

53 minutes ago, GreenSock said:

I don't see any #page element (no elements with that ID). What am I missing? And the relevant content appears to be 100vh, so I must be missing something. Obviously if you're pinning something, it adds pinSpacing to prevent things from collapsing/overlapping and to stretch out the scrollable area, but you're welcome to set pinSpacing: false if you prefer that effect.

 

I read that a few times and I'm still pretty lost. "between resizing" - like between the time you start resizing and stop resizing? And why do you expect it to "got to the last end of the last section" (and could you explain what that means)? 

 

It looks like you're setting the maxWidth variable from within an onRefresh...which runs AFTER all the refreshing is done, but you're plugging that value into the animation's function-based "x". So that value will always be stale. In other words, you've got an order of execution problem there (if I understand your goal correctly). I assume you intended to do something like: 

// old
x: () => `-${maxWidth}`

// new 
x: () => getMaxWidth(sections) * -1

 

What's "xOffset"? I don't see any such value. And what's "hot-swap"? If you're talking about hot module replacement, that's probably a bad idea to rely on that doesn't mimic browser behavior and it's not a "real" way to run things. It's totally unrelated to GSAP/ScrollTrigger - it's a build system thing. 

My apologies, typing at 3AM seems to mess this post up a lot. I will try to clarify

 

Quote

I don't see any #page element (no elements with that ID). What am I missing? And the relevant content appears to be 100vh, so I must be missing something. Obviously if you're pinning something, it adds pinSpacing to prevent things from collapsing/overlapping and to stretch out the scrollable area, but you're welcome to set pinSpacing: false if you prefer that effect.

I have updated the pen, the template I used use #root but I used #page over my codebase. I overlooked this part when I was trying to clean up this from my code base

 

Quote

I read that a few times and I'm still pretty lost. "between resizing" - like between the time you start resizing and stop resizing? And why do you expect it to "got to the last end of the last section" (and could you explain what that means)? 

 

It looks like you're setting the maxWidth variable from within an onRefresh...which runs AFTER all the refreshing is done, but you're plugging that value into the animation's function-based "x". So that value will always be stale. In other words, you've got an order of execution problem there (if I understand your goal correctly). I assume you intended to do something like: 

Your solution seem to solved the current issue I have with resizing. I was trying to have the scroll bar to covers all of  the .sections. The ending effect should look like how this pen horizontal scroll works but with variable width (Pardon  me for using the Snapping example here, I only care for the horizontal section)

 

 

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

 

Quote

What's "xOffset"? I don't see any such value. And what's "hot-swap"? If you're talking about hot module replacement, that's probably a bad idea to rely on that doesn't mimic browser behavior and it's not a "real" way to run things. It's totally unrelated to GSAP/ScrollTrigger - it's a build system thing. 

Let me reword what I said.

 

Quote

3. This is a probably bit related to 2 but I have no confidence in being able to fully replicate this here. ReactJS seem to act a bit funny with gsap where the translateX() value when the scrollbar reached the end tends to be inaccurate on first load, but once React initiates a rerenders due to code change, the intended behavior was achieved.

I reworded this based on the solution you proposed but seems like the issue still persists. Though replicating this through a simplified pen isn't easy , I will try to provide some image though

 

This is the browser when the scrollbar reached the end, I am using Chrome Dev Tool (Layer Tool) and highlighting the scrollbar for easier visualization. As you can see, this is on first load of the page. With the current fix above you can see how some of the last section is still being left out (Those are to the right of the highlighted section)

 

Now, when ReactJS re renders (Due to code change). My scrolling position resets to 0, yet

 

Now all of the elements are correctly calculated. And scrolling seems to covers all of the section

 

I am willing to provide more details in private but sadly I haven't found a way to replicate this on a pen

 

 

[GreenSock]

1 hour ago, Banbeucmas said:

Now, when ReactJS re renders (Due to code change). My scrolling position resets to 0, yet

A few questions...

1. Are you using GSAP 3.11.5? If not, please update and confirm that the issue persists.
2. If you don't rely on hot reloading in your dev environment, does everything work fine? Again, I kinda suspect the problem is actually your dev environment with hot reloading. 
3. Is the only remaining issue that things aren't moving horizontally quite enough? Is the distance that's "hiding" exactly the width of the scrollbar? 

It's super difficult to troubleshoot blind. Here's a Stackblitz starter template that you can fork.

[Banbeucmas]

2 minutes ago, GreenSock said:

A few questions...

1. Are you using GSAP 3.11.5? If not, please update and confirm that the issue persists.
2. If you don't rely on hot reloading in your dev environment, does everything work fine? Again, I kinda suspect the problem is actually your dev environment with hot reloading. 
3. Is the only remaining issue that things aren't moving horizontally quite enough? Is the distance that's "hiding" exactly the width of the scrollbar? 

It's super difficult to troubleshoot blind. Here's a Stackblitz starter template that you can fork.

Seem like it is due to the dev environment on hot reload. You are on point with that. Guess I can consider this a ReactJS issue then

[GreenSock]

16 minutes ago, Banbeucmas said:

Seem like it is due to the dev environment on hot reload. You are on point with that. Guess I can consider this a ReactJS issue then

Yeah, I think you're right about that. It's the nature of the beast (hot reloading). And obviously that's only an issue that'll show in your dev environment, not a live site. Doing a normal refresh should resolve it I'd guess. 

[Banbeucmas]

5 minutes ago, GreenSock said:

Yeah, I think you're right about that. It's the nature of the beast (hot reloading). And obviously that's only an issue that'll show in your dev environment, not a live site. Doing a normal refresh should resolve it I'd guess. 

It's interesting that it's actually another way around. A normal refresh would cause the issue, hot reloading is where the expected behavior works.

 

Anyway, thanks for the help. Cheers