GraphQL Pagination | Самый первый запрос - PullRequest
Новая
       24

GraphQL Pagination | Самый первый запрос

1 голос
/ 02 июля 2019

В соответствии с моделью на основе соединений для разбивки на страницы с использованием graphQL, я имею следующую упрощенную схему. 

type User {
  id: ID!
  name: String!
}

type UserConnection {
  totalCount: Int
  pageInfo: PageInfo
  edges: [UserEdge]
}

type UserEdge {
  cursor: String
  node: User
}

type PageInfo {
  lastCursor: Int
  hasNextPage: Boolean
}

type Query {
  users(first: Int, after: String): UserConnection
}

Рассмотрим следующий маршрутизатор, включенный в интерфейс SPA:

/users - как только пользователь заходит на эту страницу, я извлекаю первые 10 записей прямо из верхней части списка, и в дальнейшем я могу разбить на страницы, повторно используя курсор, полученный из первого ответа. .

/user/52 - здесь я бы хотел показать 10 записей, которые должны идти прямо с позиции пользователя52.

Проблема Каковы возможные способы получения определенного подмножества записей по самому первому запросу? На данный момент у меня нет курсора для создания чего-то похожего на 

  query GetTenUsersAfter52 {
    users(first: 10, after: "????") { # struggling to pass anything as a cursor...
      edges {
        node {
          name
        }
      }
    }
  }

То, что я уже пробовал (возможное решение) - это то, что я знаю, что на бэкэнде курсора кодируется значение _id записи в БД. Таким образом, находясь на /users/52, я могу сделать индивидуальный запрос для этого конкретного пользователя, получить значение id, затем на внешнем интерфейсе я могу вычислить курсор и передать его на серверную часть в запросе выше.

Но в этом случае лично я обнаружил пару недостатков:

  1. Я раскрываю способ вычисления моего курсора во внешнем интерфейсе, что плохо, так как, если мне нужно изменить эту процедуру, мне нужно изменить его во внешнем и внутреннем ...
  2. Я не хочу создавать другое поле запроса для отдельного пользователя просто потому, что мне нужен его идентификатор для передачи в поле запроса users.
  3. Я также не хочу делать 2 вызова API для этого ...

1 Ответ

1 голос
/ 02 июля 2019

Это хороший пример того, как может быть ограничено разбиение на страницы в стиле реле. Вы столкнетесь с подобным сценарием с созданием мутаций, когда добавление созданного объекта в кеш вручную приведет к тому, что вы испортите нумерацию страниц, потому что у вас не будет курсора для созданного объекта.

Пока вы на самом деле не используете Relay на стороне клиента, одно из решений - просто отказаться от использования курсоров. Вы можете оставить свои поля before и after, но вместо этого просто примите значение id (или _id или любое другое PK) вместо курсора. Это то, чем я занимался в недавнем проекте, и это значительно упростило ситуацию.

...