Hybrid offset?
See original GitHub issueI was reading the source code of computeOffsetPixels.js
and now understand how it works. I would like to raise an discussion on a possible expansion for the “hybrid offset”, e.g. allowing 100% - 50px
:
I found one use case in my project where I use react-waypoint
as a scrollspy agent. I have a fixed-height <nav>
at the top of the page. And I want to trigger something when the user scroll down to a point where a <div>
is right ‘at flush’ to the bottom of the <nav>
.
Since I want the above behavior when scrolling down, I need to use bottomOffset
, not topOffset
(right?). So basically I need 100% - 50px
-ish value for bottomOffset
, which is not supported. Such functionality will be handy, since _handleScroll()
gets the bound from _getBounds()
fresh, and that takes care of resizing issues.
Issue Analytics
- State:
- Created 6 years ago
- Reactions:2
- Comments:11
Hi @t47io !
You’re right that we don’t currently support a hybrid offset, but you’re in luck, because I think the API that we have supports your use case. In fact, by the sound of it, that’s the exact use case I needed to support when I helped implement the current offset API.
Nope, it’s still
topOffset
. When using Waypoint vertically (which is the default), you can think oftopOffset
as controlling the location of the boundary at the top of the page.bottomOffset
controls the boundary at the bottom of the page. In this case, you’re shifting the location of that top boundary, so, accordingly,topOffset
is the best bet. If you had a fixed footer, for example, then you’d want to usebottomOffset
.To know what value we need to set for
topOffset
, we can reference the documentation:Based on this, it sounds like what you need is a positive pixel value of
topOffset
equal to the height of your nav bar. If your nav bar is 50px, thentopOffset="50px"
should do the trick.Also, for some historical context, we did consider a hybrid API, similar to what you suggested. You can read more about that conversation here: https://github.com/brigade/react-waypoint/issues/77#issuecomment-223705419
Let me know if that helps!
Yes, agreed. This is only a workaround, not any elegant solution. I can imagine my proposed component like:
Handlers are triggered by the internal
<Waypoint/>
# 1,2,3, with same arguments. The caveat is, indeed, it does not address the “awareness of top/bottom” problem. Also, it would be ideal to have a “real-time”onPositionChange
, sort of like the one here https://github.com/gilbox/react-spark-scroll#callback-on-scroll-event