Urql: Create Smart List component

[kenwheeler]

For that sweet boy @mxstbr

[mxstbr]

Yes please! 😍

[kitten]

I think this would really pair well with the fragment-level cache idea that I've now finally written (haha) https://github.com/FormidableLabs/urql/issues/85

Edit: @kenwheeler can you outline an RFC or write one, so that anyone could pick up this task? 😛 I'm a little lost on the details here

[kenwheeler]

Sure. Actually, before I take a crack at it, @mxstbr did you have a high level checklist of details you'd like included?

[mxstbr]

Sure! It should basically handle pagination out of the box, based on the Relay connection spec. Right now with Apollo Client I have to do the following:

https://github.com/withspectrum/spectrum/blob/9f51467a7120ff2d01571e6170b27d2b31e14dee/shared/graphql/queries/thread/getThreadMessageConnection.js#L85-L248

All of that code seems entirely unnecessary. There should be a fetchNextPage and fetchPreviousPage out of the box, that load and add items to the end and beginning of a list, respectively, without manual intervention. It could also have specific loading states for these, something like this.props.fetchingNext and this.props.fetchingPrevious or whatever.

I think that could end up looking something like this:

<Connect connectionQuery={query(getThreadMessagesQuery, { id })} {/* other <Connect> options here */}>
  {({
    fetchNextPage,
    fetchPreviousPage,
    fetchingNext,
    fetchingPrevious,
    fetching, // This is only true for the first load probably?
    ...otherConnectParams
  }) => /* ...render list here... */}
</Connect>

The cache should also be smart enough to handle these lists. When a user navigates back to a screen they'd previously seen it automatically fetches from the last cursor in the store and adds any new items returned to the end.
Apollo doesn't do this at all, when you navigate back to a thread they just dispatch the original query and overwrites the entirety of the list, even if you had paginated.

Does that make sense?

[kitten]

Hm, I'm not sure whether it'd make sense to "overload" the render prop's object with so many parameters, but I think this makes a lot of sense otherwise. Maybe we need a flexible description of the fetching logic though. I agree that Relay-style cursors are popular, but sometimes cursors and/or pagination are implemented in subtly different ways, and I'd hate to force a "one true structure" on people. Maybe we can find sth that uses the Relay-style connection cursors by default though?

Regarding the render prop object, maybe we can do:

['nextPage' | 'prevPage']: {
  loading: boolean,
  error?: CombinedError,
  data: T
}

[jpstrikesback]

To that sentiment re strict Relay @kitten, I'd like to try this with an AppSync API without strict Relay connection spec, just your run of the mill after cursors :), and it would be nice to not enforce a specific spec, though a default is nice too. Anyways, there's my toonie's-worth, I don't want to interrupt something actually happening with these thoughts :)

[mxstbr]

The Relay connection spec is convention of where to put cursors and which arguments to pass depending on which direction you want to go, right? It'd be great if it worked out of the box with that since it's pretty widely used. That being said, you can probably make an abstraction that allows users to reduce the first/last item to arguments for the fetchPage methods, if that makes sense?

[jpstrikesback]

Yeah, totally, and fake a PageInfo { hasNext/PreviousPage }?
(Although I'm not quite sure how off the top of my head to fake that in a nice way)

[jpstrikesback]

Anyways, don't want to introduce a blocker, I would love to see this happen for anything and then see where it could go.

[kitten]

Currently there are no plans anymore to implement this as a component. However, there are plans to implement a normalised cache exchange for v1. I'll close this issue for now, but feel free to open new issues with new ideas :+1: I'll leave this with the vague promise: There will be normalised caching 😆