Fork me on GitHub
#graphql
<
2019-05-30
>
pcj00:05:29

@currentoor you can use an introspection query for that https://graphql.org/learn/introspection/

devth17:05:25

is anyone using cursor based pagination with lacinia? https://graphql.org/learn/pagination/

sashton17:05:38

Yes, it works well for some of our use cases.

devth17:05:06

cool. is your schema public/open source? curious how to describe it

sashton17:05:50

It’s not public. But here is basically what it looks like:

:PagedFoo
  {:fields
   {:foo_list {:type (list :Foo)}
    :next_page_cursor {:type String}}}

devth17:05:30

thanks. i was trying to figure out if "Paged" could be a generic type

devth17:05:35

not sure the concept even exists in lacinia

devth17:05:42

so that i could have many different types of Paged things

sashton17:05:01

I see in that link you posted, they chose to put PageInfo in friends, whereas we chose to wrap our data object in the paging.

sashton17:05:49

I haven’t thought deeply about their approach, but one possible problem I see is that now the Friend type has to know about paging. Maybe that makes sense, but for us at least we have paths to get single Foo objects, so paging wouldn’t make sense in that context

devth17:05:09

good point

sashton17:05:36

I think also that ours could be written:

:PagedFoo
  {:fields
   {:foo_list {:type (list :Foo)}
    :page_info {:type PageInfo}}}

sashton17:05:58

And then we’d have the re-usable data container at least. 🤷

devth17:05:16

yep, interesting.

sashton17:05:10

But the details of paging over Foo’s might be different than paging over Bar’s, so it’s possible not much might be shared besides the data type

devth17:05:11

that makes sense. i need to contemplate how this maps to the "connections" concept. e.g.:

{
  hero {
    name
    friendsConnection(first:2 after:"Y3Vyc29yMQ==") {
      totalCount
      edges {
        node {
          name
        }
        cursor
      }
      pageInfo {
        endCursor
        hasNextPage
      }
    }
  }
}

devth17:05:42

i'll probably model it directly without trying to re-use types first

sashton17:05:17

just to complete my example, here’s the query resolver with the cursor arg:

:list_of_foos
  {:type :PagedFoo
   :args {:cursor {:type String}
          :limit {:type Int :default-value 25}}
   :resolve ....}

devth17:05:33

thanks. that's helpful!

sashton17:05:24

And rather than returning hasNextPage, we chose to return a null cursor at the end

4
sashton17:05:46

Now that I look closer, I think friendsConnection might be somewhat like PagedFoo.

devth17:05:51

yep. and maybe i could model Connection as an interface

sashton17:05:12

friendsConnection.edges.node vs our direct foo_list

orestis18:05:04

We lifted Relay pagination and implemented a subset of it.

👍 4