же хук useQuery с одними и теми же параметрами в разных компонентах одной и той же страницы - то гарантии того, что на бэк не отправится 2 запроса, нету?
Можно установить приоритеты (fetchPolicy): 'cache-first' | 'network-only' | 'cache-only' | 'no-cache' | 'standby' То есть поставишь fetchPolicy: 'network-only' и всегда будет летать запрос на сервер Но я подмечу, что юзаю Apollo. Уверен есть то же самое и в Relay
у меня был прикол с cache-first что летело 2 запроса, но потом один cancel-ился, и в нетворке он был красным. Не думаю что это бест-практис... (тоже аполло юзаю)
Тут ещё такой момент, что скорее всего тебе не надо оба отправлять на сервер, если один свежее другого, второй просто возьмёт обновлённое из Кеша. Но это мои догадки. Я такой же ещё профан в GraphQL .
угу, в теории всё так. На практике уже есть нюансы
Ещё момент, если это удобно, может есть смысл сделать просто refetch, там где это надо.
Например у меня есть компонент с комментом, где можно его лайкнуть. Лайк у меня всегда летит на бэк. И в лайкХендлере я дергаю refetch коммента, что бы сразу отобразить изменение. То в твоём случае, если у тебя один из запросов дергается позже, то можно перед ним сделать refetch. Хотя мне кажется проще просто второй запросить сразу на бэк.
не совсем понял, зачем тебе refetch, но выглядит так будто ты пытаешься реализовать костылями то что предоставляется функционалом cache.modify - https://www.apollographql.com/docs/react/caching/cache-interaction/#using-cachemodify
Вот я сюда сильно не заныривался ещё. Но как я понимаю это всего лишь модифицирует кеш. То есть лайкнул пост запросом на сервер, а вместо того что бы обновить, меняешь локальное состояние. А если за это время появились другие изменения в БД, то состояние компонента так и останется локальным.
Обсуждают сегодня