V
У меня SPA, зачем мне начальное состояние
данные useQuery передаются на отрисовку в компонент?
Size: a a a
2020 June 20
AP
Где хранить у клиента его координаты, которые надо отправлять на бэк для гео-запросов?
СГ
Vit@LL
данные useQuery передаются на отрисовку в компонент?
это реактХук, он юзается только в компоненте
AP
Да куча всего, где нужен локальный стор
V
Очень рекомендую пройти туториал https://www.apollographql.com/docs/tutorial/introduction/
От начала до конца. У тебя пропадут куча вопросов. И ты влюбишься в Аполло)
От начала до конца. У тебя пропадут куча вопросов. И ты влюбишься в Аполло)
Да я пытался, но с моим англ и переводчиком гугл, много мелочей не понял. Может нужно повнимательнее это все делать, но пока не было времени оценить каждую строчку документации
SФ
Vit@LL
Да я пытался, но с моим англ и переводчиком гугл, много мелочей не понял. Может нужно повнимательнее это все делать, но пока не было времени оценить каждую строчку документации
Тут дело не в мелочах, а в базе
V
это реактХук, он юзается только в компоненте
Я о том, что эти данные передаются в компонент для отрисовки же? Этого достаточно, чтобы при изменении этих данных компонент перерисовывался?
V
Тут дело не в мелочах, а в базе
В базовых мелочах))
AP
Ну как данные получит, так и перерисует
AP
Или возьмет из кэша
СГ
Vit@LL
Я о том, что эти данные передаются в компонент для отрисовки же? Этого достаточно, чтобы при изменении этих данных компонент перерисовывался?
да, этих данных достаточно.
СГ
другое дело, что у меня кеш часто не соответсвует действительности - и это меня бесит конечно, в редасе я всегда был уверен, что если данные пришли - то у меня они будут.
SФ
Есть сервер – это собственно схема и резолверы над ней
Есть клиент – это расширение схемы (typedef) и резолверов над ней (то что работает через @client)
У клиента есть апи – useQuery, useMutation и watchQuery со своими опциями, куда им собствено ходить и как часто. Может в кеш, а после на сервер, или наоборот.
И вот есть кеш – локальное хранилище, как раз через которое и ходят запросы проверяя нет ли там данных уже (если опция выставлена). У кеша также есть свои резолверы которые позволяют добавлять обработку полей на своем уровне.
Есть клиент – это расширение схемы (typedef) и резолверов над ней (то что работает через @client)
У клиента есть апи – useQuery, useMutation и watchQuery со своими опциями, куда им собствено ходить и как часто. Может в кеш, а после на сервер, или наоборот.
И вот есть кеш – локальное хранилище, как раз через которое и ходят запросы проверяя нет ли там данных уже (если опция выставлена). У кеша также есть свои резолверы которые позволяют добавлять обработку полей на своем уровне.
SФ
Vit@LL
В базовых мелочах))
Если бы только в мелочах, то таких бы вопросов не было, и мы тут примеры кода обсуждали бы, а не базу
SФ
Проблема именно реакта в том, что там избегают подписок (watchQuery) и все делается через refetch, который отдает useQuery
AP
+
V
Если бы только в мелочах, то таких бы вопросов не было, и мы тут примеры кода обсуждали бы, а не базу
Так вопросы не в том, как описать клиент и получить запрос - а как это делать правильно. А вот тут были сомнения, потому что в доке в разных местах клиент описывается по разному
SФ
Vit@LL
Так вопросы не в том, как описать клиент и получить запрос - а как это делать правильно. А вот тут были сомнения, потому что в доке в разных местах клиент описывается по разному
Все что правильно в документации
SФ
Там не хватает глубины примеров, это да. Как я писал выше, уже нужно разбирать конкретные примеры
SФ
Ну и если говорить про реакт, то слово "правильно" там размыто, так как все зависит от разработчика, как он воспользуется тем что дают.