Jump to content
Search Community

scrollSmoother change data-speed in mediaQuery

celli test
Moderator Tag

Recommended Posts

Hi,

 

I have a scrollSmoother page setup and I am using in-line data-speed attributes. I am changing the data-speed at a 768px break-point, because *some* of my content stacks at that break point and I need to change the data-speed at that break-point, which works well.

I want to return my data-speed to their original settings when my browser resizes again to larger than 768px, is there a best way to accomplish this? Obviously I do not have anything in my else statement to change the data-speed to anything specific, but since there will be many elements that will use this technique (and the data-speed numbers would be different for each, depending on what the situation is), I want to see if I can easily return each of the elements to their original data-speed in some way that I might be missing or with smoothScroller ?

 

If you resize my codePen, look at the 2-column images and then resize back to above 768px, you will see what I mean.

 

See the Pen qBpwxxJ by celli (@celli) on CodePen

Link to comment
Share on other sites

25 minutes ago, PointC said:

I think you could probably loop through all the elements with a data-speed attribute and record them. Then loop back though that array on resize to put them back to original values. 

 

Happy tweening.

:)

 

humm, yes that will be the trick :) I will try 

Link to comment
Share on other sites

I am trying to create the loop, record values and then return them back into my elements, which I have not been able to do successfully as you can see in my pen—but now I am wondering can I kill() the existing scrollSmoother in the elements with this class only, and then restart scrollSmoother in my resize function? Or would that not work?

Link to comment
Share on other sites

You can grab all the data-speed attributes like this:

const originalSpeeds = [];
const targets = gsap.utils.toArray("[data-speed]");
targets.forEach((t) => {
  originalSpeeds.push(t.getAttribute("data-speed"));
});

Then you have a set of targets and an array of original speeds. 

Link to comment
Share on other sites

I'd like to set effects to false, but only for elements with a certain class of .smootherReset768, and then set them back to their original, so I really don't want to kill the whole scrollSmoother. When I try to recreate the scrollSmoother in my resize function it doesn't seem to work, so I f figured if I can capture the original values and then re-inject them into the elements when I resize over 768px that would work (also as you suggested), I just wasn't able to get that working. I see your code above so I'll give that a whirl, but it doesn't reference the elements with the class of .smootherReset768, so I'm not sure where I get the originalSpeeds from.

Link to comment
Share on other sites

Okay... I see now. You just want certain elements to have their data speed changed. I thought all of the elements were going back to 1 on small screens. Got it.

 

3 minutes ago, celli said:

but it doesn't reference the elements with the class of .smootherReset768, so I'm not sure where I get the originalSpeeds from.

You can switch the targets

const targets = gsap.utils.toArray(".smootherReset768");

 

Link to comment
Share on other sites

yes, exactly. I tried this with the loop in my else statement, but I must be doing something incorrectly. I just don't see how I am recording my originalSpeeds. If this is beyond GSAP support I totally understand, I will keep trying on my own and appreciate the help.

Link to comment
Share on other sites

hmmm... something seems amiss here to me. I may need to call @OSUblake or @GreenSock into the thread.

 

Here's a fork of your demo. I set the images to change opacity in the listener just to make sure I hit the right targets. It seems to work at first but sizing up and then down again doesn't seem to set the data-speed on the 2nd target.

 

See the Pen ExoJzQE by PointC (@PointC) on CodePen

 

So I did my own test with some simple paragraphs. Sizing this up sets the data speed correctly, but sizing down seems to set the data-speed on the 1st and 3rd targets only. The second target remains at 1.5 and gets really jumpy. It stays jumpy at large screen sizes too. 

 

See the Pen xxpeepR by PointC (@PointC) on CodePen

 

This is my first time setting the data-speed for different screen sizes in a query so maybe I'm not understanding something. Hopefully Blake or Jack can provide some insight.

:)

Link to comment
Share on other sites

I actually notice now that I test my codePen further in live mode, when I resize my browser multiple times, the behavior doesn't seem to stick, the original values seem to remain persistent. I also notice that if I start my browser under 768px wide, the data-speed change doesn't take effect.

Link to comment
Share on other sites

Hi all, I hate to dig this one back up. As I dug deeper into it, I noticed that it seemed to kill all of my scrollSmoothers, not just the ones that I am trying to target. For instance I added two boxes above the images without the class of .smootherReset768 and while those keep their original data-speed attributes (resizing below 768px), the smoothScroller stops working for those elements as well. When I resize the browser to above 768px only the elements with my class .smootherReset768 re-initiate the scrollSmoother behavior.

I tried it several different ways, but I was still not able to get my other elements without the target class of .smootherReset768 to retain the scrollSmoother behavior, without removing the t.kill() function.

Link to comment
Share on other sites

Hey @celli

 

I had the same confusion, but had a conversation with Blake about it. Here's the demo I was using to learn what was happening and his revisions. The important bit is:

 

  smoother.effects().forEach(effect => {
    let trigger = effect.trigger;
    targets.forEach(t => {
      if (t === effect.trigger) {
        effect.kill();
      }
    });
  });

So we're looping through all of the effects and checking if the trigger matches one of our targets (the ones we want to switch). If it matches, we kill() it and make another one. If not, we leave it alone.

 

This should be a guide to get you rolling and scrolling.

See the Pen 1e609824990d2eaa0e8bf02c5422dfb8 by PointC (@PointC) on CodePen

 

Happy tweening.

:)

 

  • Like 3
Link to comment
Share on other sites

7 hours ago, GreenSock said:

I added a blurb in the docs to better explain the whole "effects create ScrollTriggers" thing. 👍

Perfect. Thanks.

 

7 hours ago, GreenSock said:

Nice work, Craig. 

Gotta give @OSUblake most of the credit on this one. He helped me understand the effects a lot better.  The next time I post this answer, I'll take all of the credit. ;)

  • Haha 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...