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

Accept children #152

Merged
merged 4 commits into from
Feb 13, 2017
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 38 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Collaborator

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, not javascript (I see that this is incorrect elsewhere in this file as well)

Copy link
Collaborator

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.

<Waypoint
onPositionChange={this._handlePositionChange}
>
<div>
Some content here
</div>
</Waypoint>
```


### Example: [JSFiddle Example][jsfiddle-example]

Expand Down Expand Up @@ -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,
Expand Down Expand Up @@ -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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the waypoint's size will be determined by the size of the contained children

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right. I'll add more details.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move forward with React.Children.only, this section of documentation will need to be changed a fair amount (i.e. simplified), so it might be worth waiting to see how that pans out before spending too much time here.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any part of the children is visible in the viewport

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If something is in the viewport, then is it not by definition within the boundaries of both axes?

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

Copy link
Collaborator

@jamesplease jamesplease Jan 29, 2017

Choose a reason for hiding this comment

The 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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should "scrollspy" link somewhere for folks who are unfamiliar with the term?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

Copy link
Collaborator

Choose a reason for hiding this comment

The 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:

  1. I hadn't really heard the term before them
  2. they do a good job at explaining it
  3. so many people use, or have used, Bootstrap

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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
Expand Down Expand Up @@ -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.

Expand Down
Loading