Does anyone know of the best way to paginate a list that is the property of another object/list? https://www.prisma.io/forum/t/adding-pagination-to-lists-on-objects/4354

Hi there ! I think you could do the following: Schema:

type User {
  posts: PaginatedPosts
}

type Post {
  id: ID! @unique
  title: String!
}

type PaginatedPosts {
  nodes: [Post!]!
  meta: PaginationMeta!
}

type PaginationMeta {
  nodeCount: Int!
  pageCount: Int!
  pageCurrent: Int!
  nodesPerPage: Int!
}

type Query {
  user(id: ID!): User!
}

Resolvers:

{
  Query: {
    users: async (_, args, ctx, info) => ctx.prisma.query.user({where: {id: $id}},info)
  },
  PaginatedPosts: {
    posts: (parent, args, ctx, info) => ctx.prisma.query.posts(args, info),
    meta: async (parent, {first, skip}, ctx, info) => {
      const connection = await ctx.prisma.query.postsConnection(args, '{ aggregate { count } }')
      const count = connection.aggregate.count

      return {
        nodeCount: count,
        pageCount: Math.ceil(count/first),
        pageCurrent: skip/first + 1,
        nodesPerPage: first
      }
    }
  }
}

I did something like this (but not exactly) in one of my project. Let me know if this works ! (Also posted this on the forum!)

i think that the simplest is to use the $first and $skip variables in the query on the client side. something like is working well for us:

query fetchClients(
    $where: ClientWhereInput
    $orderBy: ClientOrderByInput
    $first: Int
    $skip: Int
  ) {
    clients(where: $where, orderBy: $orderBy, first: $first, skip: $skip) {
      id
      name
      email

    }
    clientsConnection(where: $where, orderBy: $orderBy, first: $first, skip: $skip) {
      aggregate {
        count
      }
    }
  }

we then manage the pagination buttons in the front-end using ant.design.

@Jared - Sure, but on that example

clients

is not nested under another object, i.e.

{company { clients } }

you can use the $first and $skip variables on the nested items as well. but i agree it might get weird. I'm a fan of keeping the schema and resolvers as pure as possible and let the client do all the acrobatics.

It’s a fine line in GraphQL I think 🙂 Sure, the client should be empowered, but the backend should still dictate terms - and this is a case of the latter IMO