In this tutorial, I will explain how to make a navbar that is hidden or displayed when we scroll on the page. This is a version for React.js that u...
For further actions, you may consider blocking this person and/or reporting abuse
Hi there! Isn't it easier and a lot more "React" to use the top position as a state key instead of having to query by element on each scroll event? If we talk about performance, document.getElement... is not the best option. And if we want to reuse the same component, that ID will be a problem later. Hope it helps. Kudos for the article!
Storing the top as a state key is probably better, but to use React.createRef() is also an alternative to
getElementById
.Thank you both! I've made some changes on the
nav id
and how I manage the CSS too.About the top as a state key, If you could provide me with some way to test the efficiency I'll be thankful. I'll try it by myself also 😊
Hello Guim,
In Chrome Developer Tools under "Performance" tab you can record a new session. This will display your frame rate in idle state and animation/scroll action. But it will be really hard to see any difference with a fresh project. It will become obvious when you have a long list of DOM nodes, then document.getElement on each ~10ms event spawn (the duration between each scroll event execution, when the scrollHandler is executed) really effects the user experience and sometimes with some animations on top, the page becomes unusable.
About your code update, you can remove the "ref" since it is not used. And as a note that can help you some time in future, "refs" can't be used in componentDidMount/componentWillMount or any function triggered before rendering in the component lifecycle.
Also, please update your CSS. You should have two different classes. One that keeps your base component aspect, and one that will be used depending on component state to update your base style.
Have a nice day!
Great contribution! Thanks. I updated the CSS and removed the ref too.
Perfect! As a final step, you could also change a bit the setState. Instead of having to write 3 times setState, you could do:
It would be better to check if scroll direction (-Y or Y+) is the same with previous scroll direction. If it is the same, you don't have to update the state, because the component has the same position. By this I mean, if you already have the component hidden, and you keep scrolling down, you don't need to update its state.
And to be fair, I would add a debounce function wrapper to avoid calling this handler too many times (for performance reasons). Look into debounce method of "underscore" node modules. It's pretty easy to implement, and saves a lot of memory.
As always, simple problems have complex solutions. :)
Done! Thanks for your good advice 🌟
Awesome write up! I just wrote about doing this same thing using hooks and RxJS if you’re interested in taking a look at a different approach: faircloth.xyz/auto-hiding-sticky-h...
I'll take a look! :)
This is great! One tiny improvement, to get rid of the
classnames
dependency, you could use string formatting, e.g.Related but separate question: I have this implemented and it's working great, but the top of the main content is chopped off by the navbar when scrolled to the top of the page. The main content needs to be bumped down by the height of the navbar. Is there a good way to do this?
This works great for me on desktop, however on mobile it's a bit jumpy - does anyone have a solution for this? I was reading this blog: remysharp.com/2012/05/24/issues-wi... which suggests an issue with using 'position: fixed;' inside the scroll element, but the solutions there don't seem to work either.
On mobile, if I scroll too quickly to the top or bottom of the page it seems that pageYOffset picks up some bad values and makes my menu disappear even if I'm scrolling back to the top of the page.
bro let's make this a package , I also gave a tutorial on something like this
Hi,
Nice solution!
Do you have how it's possible to unit test this component - test the window dependency?
Thanks