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

startCursor and endCursor should never be null #46

Open
huw opened this issue Nov 9, 2020 · 3 comments
Open

startCursor and endCursor should never be null #46

huw opened this issue Nov 9, 2020 · 3 comments

Comments

@huw
Copy link

huw commented Nov 9, 2020

According to the Relay spec:

PageInfo must contain fields hasPreviousPage and hasNextPage, both of which return non‐null booleans. It must also contain fields startCursor and endCursor, both of which return non‐null opaque strings.

But in

const endCursor = edges[edges.length - 1] && edges[edges.length - 1].cursor;
, we don't return an appropriate fallback if the cursor is null (which happens when the query returns no results). This may (?) cause issues when integrating with Relay, but more importantly, isn't spec-compliant.

I think the appropriate fix (and I might take this on myself with a little more time) is to fall back to the cursor provided in the arguments (i.e. first or last)—these could be re-used by a client to request the theoretical 'next' page, should one become available between requests.

@dmerrill6
Copy link
Contributor

Hey @huw, thanks for pointing that out!

I was taking a quick stab at it, and I think I can squeeze it in a new release today. However, the specs are not very clear on how to handle this "no results" scenario. Using before and after makes sense (I guess you meant that instead of first and last which are item counts instead of cursors). But the problem with that those are optional args, so we need to decide what to return if those are not supplied. Maybe just returning "" in those cases?

Let me know!

@huw
Copy link
Author

huw commented Nov 25, 2020

Cheers—thanks for your patience!

Yep, I meant before and after. I think you make a good point about the spec, though—there’s no guidance on what to do if there’s absolutely no data. I had a hunt around, and found this open PR on the spec—so I think we can watch that issue, and update this when there’s a solution in the spec.

@dmerrill6
Copy link
Contributor

Sounds good!

I will keep this open to keep track of that discussion.

Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants