Hybrid offset?

I 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.

[jamesplease]

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.

Since I want the above behavior when scrolling down, I need to use bottomOffset, not topOffset (right?).

Nope, it’s still topOffset. When using Waypoint vertically (which is the default), you can think of topOffset 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 use bottomOffset.

To know what value we need to set for topOffset, we can reference the documentation:

The topOffset and bottomOffset properties can adjust the placement of these boundaries. By default, the offset is ‘0px’. If you specify a positive value, then the boundaries will be pushed inward, toward the center of the page. If you specify a negative value for an offset, then the boundary will be pushed outward from the center of the page.

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, then topOffset="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!

[t47io]

Yes, agreed. This is only a workaround, not any elegant solution. I can imagine my proposed component like:

topOffset: shapeOf({
  viewTop: oneOfType([number, string]),
  viewBottom: oneOfType([number, string]),
}),
bottomOffset: shapeOf({
  viewTop: oneOfType([number, string]),
  viewBottom: oneOfType([number, string]),
}),
onTopEnter: func,
onTopLeave: func,
onBottomEnter: func,
onBottomLeave: func,
scrollableAncestor: any,
fireOnRapidScroll: bool,
debug: bool,

top/bottom meaning of the <div> which is intuitive, and viewTop/Bottom for viewport.

As mentioned above, a hacky onMount could be implemented, but so ugly.

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