Телеграмм чат группы graphql

да, который нигде и ни для чего не используется, кроме как для целей представления - и когда этот курсор используется для того, чтобы выдать следующую страницу, то perPage (у нас его нет, но допустим) будет тот же, а page будет либо +1, либо -1 от текущего.

источник

16:19пожаловаться #9

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество

Капец вы там курнули )

источник

16:19пожаловаться #10

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество

Прям очень круто. Я вообще до этого не допер, когда реализовывал свой коннекшен.

источник

16:20пожаловаться #11

t

toriningen in GraphQL — русскоговорящее сообщество

вам не нужно именно рассчитывать курсор на далекие страницы, в зависимости от того, что вы делаете.

- вы можете получить последнюю запись (и только последнюю?). например, обратить сортировку и сделать limit 1? если да, то у вас уже есть опорный первичный ключ

источник

16:20пожаловаться #12

t

toriningen in GraphQL — русскоговорящее сообщество

просто этот курсор, который указывает на последнюю запись, будет вести не "вперед" (т.е. "все, что ПОСЛЕ этой записи невключительно"), а "назад" (т.е. "включая этот ключ, 10 записей до него")

источник

16:20пожаловаться #13

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество

И даже если у вас будет на странице переключалка кол-ва элементов. То вы просто сбросите клиента в начало списка и пущай листает сначала. Прям годный вариант гибрида коннекшена и пагинации! Прям топчик!

источник

16:21пожаловаться #14

t

toriningen in GraphQL — русскоговорящее сообщество

Pavel @nodkz

И даже если у вас будет на странице переключалка кол-ва элементов. То вы просто сбросите клиента в начало списка и пущай листает сначала. Прям годный вариант гибрида коннекшена и пагинации! Прям топчик!

у нас нет переключалки количества элементов, но если бы была, то можно было бы просто в кверю запихнуть, сколько человек хочет элементов на странице - курсор останется прежний

источник

16:21пожаловаться #15

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество

Но вы не по спеке Релеевской пошли. Вы грубо говоря свою реализацию сделали. У релея для каждой записи курсор формируется. А у вас для всего резалт сета

источник

16:21пожаловаться #16

t

toriningen in GraphQL — русскоговорящее сообщество

т.е. при одинаковом курсоре, если сделать query на 100 элементов и на 20 элементов, то первые 20 элементов из большого запроса будут такими же, как в маленьком

источник

16:22пожаловаться #17

t

toriningen in GraphQL — русскоговорящее сообщество

Pavel @nodkz

Но вы не по спеке Релеевской пошли. Вы грубо говоря свою реализацию сделали. У релея для каждой записи курсор формируется. А у вас для всего резалт сета

да, есть такое. нам показалось избыточным делать возможность мотаться в "середину страницы"

источник

16:23пожаловаться #18

A1

Art 141 in GraphQL — русскоговорящее сообщество

toriningen

вам не нужно именно рассчитывать курсор на далекие страницы, в зависимости от того, что вы делаете.

- вы можете получить последнюю запись (и только последнюю?). например, обратить сортировку и сделать limit 1? если да, то у вас уже есть опорный первичный ключ

А если надо не просто последнюю страницу, а 5 последних, то 5 запросов в бд?

источник

16:23пожаловаться #19

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество

toriningen

у нас нет переключалки количества элементов, но если бы была, то можно было бы просто в кверю запихнуть, сколько человек хочет элементов на странице - курсор останется прежний

курсор не останется прежним, вы просто сгенирууете новый курсор на данных предыдущего (при этом не надо будет ковырять записи в базе)

источник

16:24пожаловаться #20