Why we moved away from React Query | Basedash

Статья от команды Basedash про то, как она в течение года использовала React Query, но решила уйти обратно в fetch + redux для загрузки и хранения данных.

Основная проблема, на которую указывают в посте, это изменение данных в кэше React Query. Например, вы загрузили данные о пользователе и пользователь из интерфейса обновил свой логин. Теперь вам надо чтобы во всех местах, где был useQuery с данными пользователя, обновился логин.

Вы можете сбросить кэш и тогда React Query сделает новый запрос, но это лишний сетевой вызов и, возможно, мигание интерфейса.

Вы можете использовать внутреннее API React Query для изменения сохраненных в кэше данных. Но и тут все непросто т.к. надо про это не забыть и правильно все вызвать, чтобы обновилось действительно во всех местах использования данных.

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

Поэтому команда решила использовать загрузку данных через fetch и складывать все в redux. При этом используют мощь redux-toolkit и нормализации данных

https://www.basedash.com/blog/why-we-had-to-move-away-from-react-query

#development #javascript #react #reactQuery

Inside React Query

Пост про то, как реализован внутри react query, в серии постов про react query

Хорошая короткая статья с визуализацией. Рассказывается про работу кеша и как компонент получает данные

https://tkdodo.eu/blog/inside-react-query

#development #react #reactQuery

You Might Not Need React Query

Возможно вам не нужен React Query. Статья является ответом на горячие споры в интернете о том, что серверный компоненты react делают React Query ненужным.

Не смотря на то, что React предоставляет удобный способ делать асинхронную загрузку данных прямо в серверном компоненте, React все еще остается очень гибким решением, которое не форсит какой-то один способ как делать что-то "правильно". Для определенных приложений (например, которые сразу пишутся по определенной архитектуре, в которой серверные компоненты хорошо встроены), React Query действительно может быть не нужен.

Однако для многих приложений придется использовать гибридный подход (и серверный компоненты и React Query) из-за ограничений архитектуры, плавных миграций или каких-то плюшек React Query. Либо же останутся проекты, которые не будут использовать серверные компоненты.

https://tkdodo.eu/blog/you-might-not-need-react-query

#development #react #reactQuery #reactServerComponents

React Query and React Context

Статья про комбинирование React Query и React Context. Сам по себе React Query очень удобен - он позволяет одновременно сделать компонент самодостаточным, но при этом абстрагировать логику запроса и кеширования данных, а также позволяет переиспользовать один кеш для нескольких компонентов. Но в случае с несколькими компонентами возникает проблема неявной зависимости - они могут использовать данные, предполагая, что другой компонент их уже запросил. Для решения этой проблемы автор предлагает использовать React Context

React Context выступает провайдером данных, которые получаются с помощью React Query, это позволяет явно разделить загрузку и получение данных, а также позволяет избежать излишних проверок Typescript.

В статье также разбираются альтернативные паттерны для решения подобной проблемы, например Suspense

https://tkdodo.eu/blog/react-query-and-react-context

#development #react #reactContext #reactQuery

Why react Query

Большая и хорошая статья про то, зачем и почему появился react query. Статья идет от простого к сложному и объясняет, как тяжело в React учесть все нюансы для загрузки данных (понадобится много хуков и много бойлерплейта) и как React Query забирает на себя весь бойлерплейт и улучшает DX, производительность и качество решения.

Как и всегда на ui dev, в стате понятные примеры кода и крутая интерактивная анимация. Рекомендую к прочтению

https://ui.dev/why-react-query

#development #javascript #react #reactQuery #recommended

Удалить полпроекта: как мы переписывали MobX‑сторы на React Query в большом Next.js‑проекте

Статья про оптимизацию ощущаемого перформанса сайта с помощью перехода с mobx на React Query. Если предыдущее предложение показалось вам странным, то вы правы, заменять mobx на react-query очень странно т.к. это смена с реактивного стейт менеджера на либку для менеджмента запросов

Тем не менее, статья и опыт достаточно интересные. В приложении есть SSR и CSR. Вся логика по загрузке данных вшита в mobx-сторы. Эта логика может отличаться для разных компонентов (глобальные и локальные сторы) и для разных флоу (серверный и клиентский). В какой-то момент разработчики поняли что а) получилось сложно б) сайт перезагружает данные там, где не должен. Поэтому решили мигрировать на react-query

Не смотря на то, что есть открытые вопросы про то, как использовался mobx (вероятно можно было все исправить без смены инструмента), сам процесс миграции выполнен хорошо.

Сначала попробовали сменить mobx на react-qeury на главной странице. Собрали часть граблей, значительно ускорили открытие страницы, новый код стал занимать в 2 раза меньше строчек, чем старый. Затем составили план миграции - задокументировали, как делать адаптеры, как переписывать разные куски кода (серверный, клиентский, локальный, глобальный), сделали базовые абстракции для упрощения переписывания. Затем, договорились, что весь новый код надо писать на react-query, а старый переписывать в рамках техдолга.

В итоге переписали часть приложения, стало лучше (цифры и графики не показывают). В комментариях много интересных комментариев про то, как можно было бы сделать лучше - разные паттерны и расширения mobx позволили бы решить проблему не переписывая кучу кода.

https://habr.com/ru/companies/kts/articles/935086/

#development #javascript #mobx #reactQuery #migration

Deriving Client State from Server State

Частый паттерн - использовать useEffect для синхронизации состояния двух стейтов. В рамках статьи обсуждается синхронизация стейта react-query и zustand. Вместо использования useEffect предлагается высчитывать состояние, вместо его синка

Пример проблемы:

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

Пример предлагаемого решения

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

Соглашусь с автором. Если вы можете не использовать 2 стейта, которые надо синхронизировать - не надо их использовать т.к. синхронизация стейтов это а) кривое решение б) хрупкое решение. У меня до сих пор есть въетнамские флешбеки от синхронизации rxjs-like стейта (какой-то самописный стор на обсерваблах) с redux-like стором.

https://tkdodo.eu/blog/deriving-client-state-from-server-state

#development #javascript #react #reactQuery #zustand