-
Notifications
You must be signed in to change notification settings - Fork 209
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
Accept children #152
Accept children #152
Changes from 2 commits
ec87515
b0d7d3e
be8ad60
52e14c6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -77,6 +77,19 @@ below) has changed. | |
/> | ||
``` | ||
|
||
Waypoints can have children, allowing you to track when a section of content | ||
enters or leaves the viewport. | ||
|
||
```javascript | ||
<Waypoint | ||
onPositionChange={this._handlePositionChange} | ||
> | ||
<div> | ||
Some content here | ||
</div> | ||
</Waypoint> | ||
``` | ||
|
||
|
||
### Example: [JSFiddle Example][jsfiddle-example] | ||
|
||
|
@@ -217,7 +230,7 @@ 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. | ||
|
||
#### Horizontal Scrolling | ||
#### Horizontal Scrolling Offsets and Boundaries | ||
|
||
By default, waypoints listen to vertical scrolling. If you want to switch to | ||
horizontal scrolling instead, use the `horizontal` prop. For simplicity's sake, | ||
|
@@ -248,6 +261,29 @@ the `onLeave` and `onEnter` callback will be called. By using the arguments | |
passed to the callbacks, you can determine whether the waypoint has crossed the | ||
top boundary or the bottom boundary. | ||
|
||
## Children | ||
|
||
If you don't pass children into your Waypoint, then you can think of the | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/children/a child/ |
||
waypoint as a line across the page. Whenever that line crosses a | ||
[boundary](#offsets-and-boundaries), then the `onEnter` or `onLeave` callbacks | ||
will be called. | ||
|
||
When children are passed, then the waypoint's size will be determined by the | ||
size of the contained children. The `onEnter` callback will be called when *any* | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I assume that this isn't strictly true (e.g. if the children are absolutely positioned). Perhaps we should phrase this in a way that makes this clear, or provide a list of known cases where this statement is not true. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You're right. I'll add more details. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we move forward with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍Ill wait to see how things pan out. |
||
part of the children is visible in the viewport. The `onLeave` callback will be | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
This is true, per axis I believe. In other words, if you have a page that scrolls in both directions and you have a waypoint with children that is vertically in the viewport but not horizontally, it will still fire. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, I think I get what you mean, but your example is throwing me off. If something is in the viewport, then is it not by definition within the boundaries of both axes? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes, but (and I could be misunderstanding the implementation here) Waypoint is only checking viewport boundaries on a single axis (either vertical or horizontal). So, Waypoint's definition of "in the viewport" is really "in the viewport on a single axis and ignoring the other axis". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, right. I see what you mean. What's here could be misleading, so I'll update this and attempt to capture this behavior. |
||
called when *all* children have exited the viewport. | ||
|
||
Deciding whether to pass children or not will depend on your use case. One | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should maybe be "a child" here and lower as well? |
||
example of when passing children is useful is for a scrollspy. Imagine if you | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should "scrollspy" link somewhere for folks who are unfamiliar with the term? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not finding a concise explanation with a quick google, and the next sentence does a decent job of explaining the use-case IMO There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. One idea would just be to link to the Boostrap docs. It might seem weird, but:
They version their docs, so we could "lock it down" to a specific version to avoid issues if they remove the scrollspy ever. ...maybe this is a bad idea. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I kinda like that. I'll add it |
||
want to fire a waypoint when a particularly long piece of content is visible | ||
onscreen. When the page loads, it is conceivable that both the top and bottom of | ||
this piece of content could lie outside of the boundaries, because the content | ||
is taller than the viewport. If you didn't pass children, and instead put the | ||
waypoint above or below the content, then you will not receive an `onEnter` | ||
callback (nor any other callback from this library). Instead, passing this long | ||
content as a child of the Waypoint would fire the `onEnter` callback when the | ||
page loads. | ||
|
||
## Containing elements and `scrollableAncestor` | ||
|
||
React Waypoint positions its [boundaries](#offsets-and-boundaries) based on the | ||
|
@@ -277,6 +313,7 @@ This might look something like: | |
``` | ||
|
||
## Troubleshooting | ||
|
||
If your waypoint isn't working the way you expect it to, there are a few ways | ||
you can debug your setup. | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This should be
jsx
, notjavascript
(I see that this is incorrect elsewhere in this file as well)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, i'll update all of these.