SФ
а в чем разница?
Второй будет следить за изменением в кеше + refeatch также
Size: a a a
2020 May 04
ДН
Второй будет следить за изменением в кеше + refeatch также
не, у меня кейс не тот
SФ
не, у меня кейс не тот
Да, я понял, я скорее в тему выше
А
Ну и для Optimistic UI используется
https://www.apollographql.com/docs/react/v3.0-beta/performance/optimistic-ui/
optimisticResponse, а не просто update в мутации отдельно
https://www.apollographql.com/docs/react/v3.0-beta/performance/optimistic-ui/
до конца не понял как это делать, в моем примере работает как мне нужно, но я еще поковыряюсь с optimisticResponse
SФ
до конца не понял как это делать, в моем примере работает как мне нужно, но я еще поковыряюсь с optimisticResponse
В твоем примере может не получится, так как у тебя довольно сложный кейс. Но тебе никто не может запретить положить в кеш данные параллельно с запросом (сейчас твой update), но тогда логику отмены этих изменений ты должен реализовать сам (в случае ошибки от сервера)
А
В твоем примере может не получится, так как у тебя довольно сложный кейс. Но тебе никто не может запретить положить в кеш данные параллельно с запросом (сейчас твой update), но тогда логику отмены этих изменений ты должен реализовать сам (в случае ошибки от сервера)
спсибо, насчет отмены у меня ничего не прудусмотрено
SФ
optimisticResponse делает этот мапинг сразу, не дожидаясь ответа от сервера и скорее всего как-то помечает эти данные внутри для отмены.
SФ
Но это мои догадки, я пока сам не крутил эту темы в живых проектах
SФ
У меня есть идея запилить стрим как раз раз по работе с кешем на примере списков и fetchMore-пагинации с подпиской на изменения и вот optimistic-ui может. На этих выходных не вышло, надеюсь на след как раз сделать.
SФ
Ключевая штука в том, чтобы не нужно было делать refetch, а работать только через кеш
А
вот сейчас перепроверил, оказывается, в моем случае изменения происходят не моментально
S
Выглядит как костыль. Использовать средство для построения апи с языком запросов для не связанной с сетью логики это же натягивание совы на глобус
SФ
Выглядит как костыль. Использовать средство для построения апи с языком запросов для не связанной с сетью логики это же натягивание совы на глобус
Что именно костыль? Это работа именно с кешем, как хранилищем. На первом этапе они как раз redux использовали для этого, но понятно, что у него нет никаких инструментов работы с данными, поэтому написали свое-кривое для v2 и уже допиливают до нормального состояния в v3
S
Что именно костыль? Это работа именно с кешем, как хранилищем. На первом этапе они как раз redux использовали для этого, но понятно, что у него нет никаких инструментов работы с данными, поэтому написали свое-кривое для v2 и уже допиливают до нормального состояния в v3
Само представление состояния UI как кэш это наркомания, кэш - это про сеть
S
Оно там хотя бы в local storage хранится?
S
Концепция "отправить запрос самому себе, чтобы показать менюшку" это ли не наркомания?
SФ
Само представление состояния UI как кэш это наркомания, кэш - это про сеть
Причем тут сеть? )
У приложения есть кеш, данные, которые получены с бека для отображения и временно используются, пока не протухнут. На 95% в апках, в их сторах (не только редакс, а вообще), именно кеш который береться с бека. Ну и тогда можно спросить, где же инструменты для работы с этими нормализованными данными у сторов? Ну мы все также на коленке пишем эту логику из раза в раз, делая тот же offline-first
У приложения есть кеш, данные, которые получены с бека для отображения и временно используются, пока не протухнут. На 95% в апках, в их сторах (не только редакс, а вообще), именно кеш который береться с бека. Ну и тогда можно спросить, где же инструменты для работы с этими нормализованными данными у сторов? Ну мы все также на коленке пишем эту логику из раза в раз, делая тот же offline-first
SФ
Само представление состояния UI как кэш это наркомания, кэш - это про сеть
Сделать стор персистентным это не проблема и для этого есть пакеты
SФ
Концепция "отправить запрос самому себе, чтобы показать менюшку" это ли не наркомания?
Разделять данные приложения на локальные и серверные и иметь 2 разных API для работы с ними – это ли не наркомания?
S
Причем тут сеть? )
У приложения есть кеш, данные, которые получены с бека для отображения и временно используются, пока не протухнут. На 95% в апках, в их сторах (не только редакс, а вообще), именно кеш который береться с бека. Ну и тогда можно спросить, где же инструменты для работы с этими нормализованными данными у сторов? Ну мы все также на коленке пишем эту логику из раза в раз, делая тот же offline-first
У приложения есть кеш, данные, которые получены с бека для отображения и временно используются, пока не протухнут. На 95% в апках, в их сторах (не только редакс, а вообще), именно кеш который береться с бека. Ну и тогда можно спросить, где же инструменты для работы с этими нормализованными данными у сторов? Ну мы все также на коленке пишем эту логику из раза в раз, делая тот же offline-first
Я про состояние самого приложения, в отрыве от данных. Триггер модалок, переключение состояния элементов формы, перемещение / скрытие / отображение элементов, etc. Вы уверены что это адекватно делать через запросы посредством query language? И как это можно обзывать "кэшем"?