Size: a a a

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

2021 July 07

y

yel' in GraphQL — русскоговорящее сообщество
до меня это долго доходит. Хочется сделать “как правильно”, как в гайде аполо, а выходит что я себе в колено стреляю каждый раз
источник

P@

Pavel @nodkz in GraphQL — русскоговорящее сообщество
Ждем пока Илья Климов намучается с @client и writeQuery ))) Он колится и мучается, но пока не готов отказываться.
источник

АС

Алексей Святкин... in GraphQL — русскоговорящее сообщество
Подскажите, пожалуйста, как правильно работать с ошибками в мутациях с Django_graphene?
источник

y

yel' in GraphQL — русскоговорящее сообщество
обнадёживает, что я не один такой) просто столько времени было потрачено
источник

y

yel' in GraphQL — русскоговорящее сообщество
я всё же использую иногда @client, но для каких-то небольших штук. Но был полный провал, когда я использовал @client поле в сообщение, в чате, где стейт каждого сообщения я обновлял по скролу через writeFragment. У меня при пролистывание даже скролл лагал. Переделал через makeVar и всё стало ок.
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
А почему новые сообщения не доставлять сокетами? А при перезагрузке страницы подгружать историю по временному отрезку?)
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
Я так сделал и работает как часы. Почти везде применяю такой подход
источник

y

yel' in GraphQL — русскоговорящее сообщество
всё так и происходит
источник

y

yel' in GraphQL — русскоговорящее сообщество
только про временной отрезок не очень понял. При ините (при перезагрузке) у меня квери на подгрузку последних сообщений просто. N количество прочитанных и N непрочитанных.
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
Ну либо так) у меня просто фишка была в отображении новых непрочитанных. А обычные сообщения в постоянном хранилище. Мобильное приложение   И при сохранении локально, у последнего сообщения время есть
источник

y

yel' in GraphQL — русскоговорящее сообщество
просто мне необходимо было @client поле, которое бы показывало, что сообщение находится во вьюпорте юзера. На основе этого много фишек работает. Ленивая подгрузка сообщений вверх по скролу, вниз по скролу и мутация на прочитывание сообщений.
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
Брр) я такое бы аполло не доверил. Лучше уж useState даже )
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
Тем более приведение данных в client отъедает рендер знатно
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
По сравнению с плоскими данными в каком либо стейт менеджере
источник

y

yel' in GraphQL — русскоговорящее сообщество
ну вот, а я доверил сначала и пожалел люто. Всё переделал на makeVar в итоге. Теперь просто добавляю все сообщения туда при подгрузке и жизнь наладилась.
источник

y

yel' in GraphQL — русскоговорящее сообщество
именно, оно не просто отъедает, в моём кейсе это был абзац просто) Представь что у меня тригерился writeFragment на каждое сообщение во время скрола. Просто на тот момент это было простым решением для меня
источник

y

yel' in GraphQL — русскоговорящее сообщество
оно съедало процентов 30 цп лишних
источник

LR

Leonid Rezvitsky in GraphQL — русскоговорящее сообщество
Привет! Кто использовал apollo-datasource-rest в nestjs?
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
Я и без неста его не использовал. Обычно rest контроллеры легко выступают резолверами
источник

ОЛ

Олег Линьков... in GraphQL — русскоговорящее сообщество
В чем его крутость так и не понял )
источник