Add usePageSwitcherPagination hook#44664
Conversation
There was a problem hiding this comment.
Can search contain before and after values with are not valid paginated connection query arguments (e.g., '?before=john&after=doe')? If yes, should we validate these values before using them in query?
There was a problem hiding this comment.
The tokens are opaque so we can't do any form of validation (the backend will do that when we query it, though).
And no, before and after at the same time is not allowed. That's why i made it so there's only a after or a before branch. We never set both arguments at the same time (after takes presedenc but it doesn't really matter)
There was a problem hiding this comment.
@philipp-spiess @taras-yemets this might be super obvious but I just recently noticed that this is a valid URL if you have more than one value of the same query param, for example
var s = new URLSearchParams('?site=x&site=y')
s.getAll('site') // ["x", "y"]
this is of course a corner case but I think Taras may be right here, what if we have another consumer on the page that uses the same query params. Should we add console.warn if we find more than one pagination-like query param?
Super minor, feel free to ignore.
There was a problem hiding this comment.
Should we add console.warn if we find more than one pagination-like query param?
I’m not sure how we could detect this scenario though. When we load the hook and detect pagination-like query params, we currently assume it is from the current pagination (there's nothing to identify it with, unfortunately).
FWIW this behavior has been a part of the existing pagination related abstractions as well (the legacy class component as well as the old useConnection hook).
|
This PR is currently blocked by the backend changes that @thenamankumar is working on because it uses a real GraphQL query in the tests that doesn't have the |
b2a82ac to
b77450c
Compare
There was a problem hiding this comment.
Do we want to have a default page size at backend? Given the args are naturally not null.
There was a problem hiding this comment.
Right now its 100 which is same as the max page size allowed. Shall we have a separate default page size? 20?
There was a problem hiding this comment.
I think at the backend if no first or after is set, we should error. WDYT?
There was a problem hiding this comment.
pushed change to: https://github.com/sourcegraph/sourcegraph/pull/45167/commits
There was a problem hiding this comment.
Love this. Having the url sync part of the connect hook, makes everything so simple and smooth.
|
Not approving because the BE PR is not merged yet. Otherwise LGTM. |
valerybugakov
left a comment
There was a problem hiding this comment.
Great stuff, @philipp-spiess!
There was a problem hiding this comment.
From the Apollo Client documentation, it seems that refetch() calls use each omitted variable's original value. Would it be possible to remove the logic related to initialQueryVariables to simplify the hook?
There was a problem hiding this comment.
Ooh that's nice, ty!
There was a problem hiding this comment.
Do we still need to useMemo initialQueryVariables if we don't use it in the updatePagination function? I thought that it would be nice to remove it if this is possible.
There was a problem hiding this comment.
@valerybugakov I wasn't sure, I need to do more research. I was worried that a new variables object passed on every re-render with the previous pagination values might cause some headache and I only want it to reset when the user-supplied variables change.
There was a problem hiding this comment.
@philipp-spiess I think the last time I checked useQuery hook used this package for deep variable and query options comparing https://github.com/benjamn/wryware/blob/main/packages/equality/src/equality.ts
Feel free to leave this useMemo call here this is more like FYI.
There was a problem hiding this comment.
@vovakulikov Thanks! I removed it for now as I'd rather add it when I know it's necessary.
…lways add back the gql call here)
cad93b8 to
63d39ab
Compare
|
I removed the dependence on a GraphQL schema that implements both forward and backward navigation (stubbed out the types) so we can ship this independently. Will update the types to run against the real schema once we have migrated at least one connection. |
Bundle size report 📦
Look at the Statoscope report for a full comparison between the commits a68593b and daeedc4 or learn more. Open explanation
|

Part of #44706
This PR is part of the strategic readiness effort to improve pagination.
We're adding new primitives to help us build more-robust and proper cursor-based bi-directional pagination. This PR adds a new hook,
usePageSwitcherPaginationwhich is a fork ofuseConnectionwith a few changes:useConnectiondoes).useConnection.refresh/reloadfunction and implement this logic outside of this hook.usePageSwitcherPaginationhook requires you to give up all pagination related props to the hook. You can only manage initial page sizes but every subsequent page change is controller for you. This way we avoid the confusion when users have to passfirst:andafter:manually right now with the existinguseConnectionhook, even though it's thrown away after the first page load (and sometimes not even used at all if e.g. state from the URL is restored).Everything is designed with the new pagination controls in mind which I'll be adding in a new PR:
Notes
Test plan
Added unit tests to test all of the new features. I've also tested it agains the WIP PR #44347
App preview:
Check out the client app preview documentation to learn more.