Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should addFillGapSelector check if a selector is already present? #13

Closed
Paul-Hebert opened this issue Mar 10, 2020 · 3 comments · Fixed by #14
Closed

Should addFillGapSelector check if a selector is already present? #13

Paul-Hebert opened this issue Mar 10, 2020 · 3 comments · Fixed by #14

Comments

@Paul-Hebert
Copy link
Contributor

Thanks for the great library! It's a lifesaver and I've used it for multiple projects!

I ran into an issue and was wondering if we could make a change to fix it.

The Problem

I'm building out a complex interface where the small screen and large screen experiences are very different. On large screens an element should have a fill gap selector. On small screens it should not. I had a function that looked roughly like this:

updateScrollLock() {
   if(isLargeScreen) {
      scrollLock.addFillGapSelector('.foo');
   } else {
      scrollLock.removeFillGapSelector('.foo');
   }

   if(lockScrolling) { 
      scrollLock.disableScrolling();
   } else {
      scrollLock.enableScrolling();
   }
}

This function would be called whenever a user opened or closed a menu. This action could happen a number of times. At first the menu opening and closing was snappy, but over time I noticed that the performance degraded on large screen lower-power machines (and in low performing browsers).

I dug into it and realized that every time the menu was toggled the fill gap selector was being re-added so that state.fillGapSelectors looked like this: ['.foo', '.foo', '.foo', ...]. I think this was slowing down performance, since when scroll locking was toggled it had to iterate over all those duplicate selectors and make changes.

A Quick Fix

I was able to work around it by doing something like this:

      scrollLock.addFillGapSelector('.foo');

-->

      scrollLock.removeFillGapSelector('.foo');      
      scrollLock.addFillGapSelector('.foo');

This works fine but it would be nice if it was impossible to get into this situation in the first place.

A Fix in the Library

We could avoid this by doing something like this:

export const addFillGapSelector = (selector) => {
    if (selector) {
        const selectors = argumentAsArray(selector);
        selectors.map((selector) => {
            if(state.fillGapSelectors.indexOf(selector) !== -1) {
                state.fillGapSelectors.push(selector);
                if (!state.scroll) {
                    fillGapSelector(selector);
                }
            }
        });
    }
};

I'd be happy to put up a PR if this makes sense to you.

@FL3NKEY
Copy link
Owner

FL3NKEY commented Mar 12, 2020

Hey. Thanks I am very pleased 😊
Yeah, you can make PR if you want, that would be very helpful.

@Paul-Hebert
Copy link
Contributor Author

Awesome, will do! I'll try to get to this on Monday

@Paul-Hebert
Copy link
Contributor Author

Hey @FL3NKEY ! I hope you and yours are well and healthy. Things are starting to get crazy here in Oregon with COVID. I finally got around to making a PR to fix this issue. Let me know if you'd like any changes 🙂

#14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants