#статья дня
Одно из самых интересных чтений на свете — это как принимались те или иные решения в уже готовом продукте.
Понятное дело, что новые проекты, т. н. greenfield, писать легко. Перед тобой чистый лист, гуляй не хочу, экспериментируй. Но потом...
Потом у твоего проекта появляются пользователи. И ладно если твои пользователи это просто посетители, а если твой проект — фреймворк или библиотека, а пользователи — разработчики, которые уже использовали твоё детище в своих продуктах?
Как убедить тех, кого убедить сложно, что были приняты поспешные решения, даже если они казались удобными? Как убедить людей в том, что им необходимо переписать свои продукты с учётом новых реалий?
И вот поэтому статьи вроде "Breaking React Query's API on purpose" — это настоящая золотая жила. Кто бы мог подумать, что такие простые вещи как события onSuccess и onError на самом деле могут приводить к проблемам и их придётся объявлять устаревшими?
Рекомендую не только пользователям React Query, если что.
#react #query #js
Одно из самых интересных чтений на свете — это как принимались те или иные решения в уже готовом продукте.
Понятное дело, что новые проекты, т. н. greenfield, писать легко. Перед тобой чистый лист, гуляй не хочу, экспериментируй. Но потом...
Потом у твоего проекта появляются пользователи. И ладно если твои пользователи это просто посетители, а если твой проект — фреймворк или библиотека, а пользователи — разработчики, которые уже использовали твоё детище в своих продуктах?
Как убедить тех, кого убедить сложно, что были приняты поспешные решения, даже если они казались удобными? Как убедить людей в том, что им необходимо переписать свои продукты с учётом новых реалий?
И вот поэтому статьи вроде "Breaking React Query's API on purpose" — это настоящая золотая жила. Кто бы мог подумать, что такие простые вещи как события onSuccess и onError на самом деле могут приводить к проблемам и их придётся объявлять устаревшими?
Рекомендую не только пользователям React Query, если что.
#react #query #js
❤6🔥2
#статья дня
Одно из самых интересных чтений на свете — это как принимались те или иные решения в уже готовом продукте.
Понятное дело, что новые проекты, т. н. greenfield, писать легко. Перед тобой чистый лист, гуляй не хочу, экспериментируй. Но потом...
Потом у твоего проекта появляются пользователи. И ладно если твои пользователи это просто посетители, а если твой проект — фреймворк или библиотека, а пользователи — разработчики, которые уже использовали твоё детище в своих продуктах?
Как убедить тех, кого убедить сложно, что были приняты поспешные решения, даже если они казались удобными? Как убедить людей в том, что им необходимо переписать свои продукты с учётом новых реалий?
И вот поэтому статьи вроде "Breaking React Query's API on purpose" — это настоящая золотая жила. Кто бы мог подумать, что такие простые вещи как события onSuccess и onError на самом деле могут приводить к проблемам и их придётся объявлять устаревшими?
Рекомендую не только пользователям React Query.
#react #query #js #бородач
Одно из самых интересных чтений на свете — это как принимались те или иные решения в уже готовом продукте.
Понятное дело, что новые проекты, т. н. greenfield, писать легко. Перед тобой чистый лист, гуляй не хочу, экспериментируй. Но потом...
Потом у твоего проекта появляются пользователи. И ладно если твои пользователи это просто посетители, а если твой проект — фреймворк или библиотека, а пользователи — разработчики, которые уже использовали твоё детище в своих продуктах?
Как убедить тех, кого убедить сложно, что были приняты поспешные решения, даже если они казались удобными? Как убедить людей в том, что им необходимо переписать свои продукты с учётом новых реалий?
И вот поэтому статьи вроде "Breaking React Query's API on purpose" — это настоящая золотая жила. Кто бы мог подумать, что такие простые вещи как события onSuccess и onError на самом деле могут приводить к проблемам и их придётся объявлять устаревшими?
Рекомендую не только пользователям React Query.
#react #query #js #бородач
🤩5👍2
#фишка дня
Какова цель абсолютного большинства веб-сайтов, виджетов и приложений?
Такова, какова она есть, и больше – никакова.
Если отбросить всю шелуху, это — загрузить данные, отобразить их и обновить (при необходимости).
Неудивительно, что инструменты вроде SWR и react-query aka TanStack Query стали дико популярны и вытесняют не то чтобы даже другие решения для загрузки данных, а целые стейт-менеджеры.
Более того, им не обязательно скармливать HTTP-запросы, понятие query в обоих случаях сводится к любому промису, будь то HTTP-запрос, запрос к базе данных, Firebase или даже к API Google Sheets (ну, мой случай). Это, кстати, позволяет очень легко всё тестировать.
Так вот, хуки для загрузки данных штука мощная, но мне при этом очень нравится именно вторая составляющая: кэш данных и состояния запросов.
Например, хочется показать глобальное состояние загрузки? В TanStack Query есть отдельный хук для этого: useIsFetching... но я не хочу просто показать статус загрузки, я хочу отфильтровать его лишь для некоторых!
И вот тут раскрывается настоящая мощь react-query: средства поиска и фильтрации по кешу и клиенту: useQueryClient и QueryCache.
Передав некий предикат поиска, я могу фильтровать запросы по их ключам, состоянию и ошибкам!
А после — уже отображать в любом месте приложения нужные мне действия. В моём случае это, например, отмена запроса и возврат к предыдущему состоянию.
Давайте таки покажу код: https://codesandbox.io/s/react-query-any-error-9lsjz3?file=/src/hooks/useIsFetchingPosts.ts
Уберите throw new Error из хука usePosts и получите обычную загрузку данных.
Ну а чтобы написать хук глобального состояния ошибки запроса, пришлось немного покопаться в исходниках стандартного хука useIsFetching, но это того стоило.
Задавайте ваши ответы, котаны :)
#swr #react #query
Какова цель абсолютного большинства веб-сайтов, виджетов и приложений?
Такова, какова она есть, и больше – никакова.
Если отбросить всю шелуху, это — загрузить данные, отобразить их и обновить (при необходимости).
Неудивительно, что инструменты вроде SWR и react-query aka TanStack Query стали дико популярны и вытесняют не то чтобы даже другие решения для загрузки данных, а целые стейт-менеджеры.
Более того, им не обязательно скармливать HTTP-запросы, понятие query в обоих случаях сводится к любому промису, будь то HTTP-запрос, запрос к базе данных, Firebase или даже к API Google Sheets (ну, мой случай). Это, кстати, позволяет очень легко всё тестировать.
Так вот, хуки для загрузки данных штука мощная, но мне при этом очень нравится именно вторая составляющая: кэш данных и состояния запросов.
Например, хочется показать глобальное состояние загрузки? В TanStack Query есть отдельный хук для этого: useIsFetching... но я не хочу просто показать статус загрузки, я хочу отфильтровать его лишь для некоторых!
И вот тут раскрывается настоящая мощь react-query: средства поиска и фильтрации по кешу и клиенту: useQueryClient и QueryCache.
Передав некий предикат поиска, я могу фильтровать запросы по их ключам, состоянию и ошибкам!
А после — уже отображать в любом месте приложения нужные мне действия. В моём случае это, например, отмена запроса и возврат к предыдущему состоянию.
Давайте таки покажу код: https://codesandbox.io/s/react-query-any-error-9lsjz3?file=/src/hooks/useIsFetchingPosts.ts
Уберите throw new Error из хука usePosts и получите обычную загрузку данных.
Ну а чтобы написать хук глобального состояния ошибки запроса, пришлось немного покопаться в исходниках стандартного хука useIsFetching, но это того стоило.
Задавайте ваши ответы, котаны :)
#swr #react #query
❤10👍3
This media is not supported in your browser
VIEW IN TELEGRAM
#новость дня
Стоило мне вчера рассказать, как ловить глобальные ошибки и состояние загрузки в react-query aka TanStack Query, как вышла его пятая версия!
Стоит ещё раз отметить, что начиная с 4 версии react-query стал называться TanStack Query и поддерживать не только React, но и Vue, Svelte, Solid.
Из интересного: поддержка Suspense, улучшенные т. н. бесконечные запросы (для пагинации и скроллинга), новые девтулзы. Но изменение, которое вызвало бурю разного рода эмоций это, конечно, исключение onSuccess и onError событий из определения запросов.
Впрочем, они по этому поводу полгода назад разродились большой статьёй: https://tkdodo.eu/blog/breaking-react-querys-api-on-purpose, которую я всем рекомендовал прочитать примерно тогда же.
В общем, обновляемся?
#react #query #tanstack
Стоило мне вчера рассказать, как ловить глобальные ошибки и состояние загрузки в react-query aka TanStack Query, как вышла его пятая версия!
Стоит ещё раз отметить, что начиная с 4 версии react-query стал называться TanStack Query и поддерживать не только React, но и Vue, Svelte, Solid.
Из интересного: поддержка Suspense, улучшенные т. н. бесконечные запросы (для пагинации и скроллинга), новые девтулзы. Но изменение, которое вызвало бурю разного рода эмоций это, конечно, исключение onSuccess и onError событий из определения запросов.
Впрочем, они по этому поводу полгода назад разродились большой статьёй: https://tkdodo.eu/blog/breaking-react-querys-api-on-purpose, которую я всем рекомендовал прочитать примерно тогда же.
В общем, обновляемся?
#react #query #tanstack
👍7
#заметка дня
Давайте продолжим про React Query aka TanStack Query нынче.
В комментариях писали, мол, использовать React Query (возьму старое название) это плохая привычка, современные браузерные API прекрасно справляются, надо всего лишь немного их расширить.
Немного в моём случае это:
1. Состояния isLoading, isSuccess, isError
2. Сообщение об ошибке
3. Отмена запроса через AbortController
4. Глобальное состояние загрузки (на всё приложение)
5. Нормализация данных
6. Инициация повторной загрузки
7. Поллинг
8. Кеширование данных в едином слое и решение об инвалидации.
Веб-приложения они потому и веб, что грузят данные из удалённого источника, необязательно одного. И необязательно сетевые! Об этом ниже.
Уследить за всем непросто, но это полбеды. Тесты писать кто будет на ваши обёртки?
Да, React Query и ему подобные SWR-решения (stale-while-revalidate в клиентских приложениях превратился в целый концепт) не являются вечнозелёными. Термин "вечнозелёный" я принёс сюда из CMS Drupal: там это означало модули, поставляющиеся с ядром системы. Это значит, вероятность их удаления или радикального изменения API крайне мала. В нашем случае вечнозелёными являются браузерные API.
Но вы забываете об одной крайне немаловажной фишке React Query и SWR: они могут работать с любыми промисами. Не только с сетью и fetch!
И вот тут начинается прекрасное. Долгие вычисления? Промис! Забрать картинку с холста? Промис! Обработать загруженный на клиенте файл? Тоже промис! Написать расширение для браузера и обратиться к данным со страницы или результату парсера? Промис! Обратиться к прослойке между Google Sheets и твоим расширением? Промис! То же самое в Excel. То же самое в Figma. Далее вообще везде.
Вы понимаете, к чему я клоню? Хватит думать сетью, начинайте думать операциями!
И вот тут у React Query в моём случае из конкурентов разве что Effector. Но есть одна проблема... его концепты мало того, что сложны, так и обзорных статей не на русском очень мало. Но об этом потом.
Буду закругляться, но напишу ещё кое что о тестировании.
Если React Query принимает на вход любой промис, то что вам нужно для того, чтобы протестировать своё приложение? Поднимать Mock API Server? Вы уверены?
Замокайте вызов промиса! Всё, вы прекрасны. Остальное уже протестировано за вас.
Задавайте ваши ответы, котаны.
#react #query #development
Давайте продолжим про React Query aka TanStack Query нынче.
В комментариях писали, мол, использовать React Query (возьму старое название) это плохая привычка, современные браузерные API прекрасно справляются, надо всего лишь немного их расширить.
Немного в моём случае это:
1. Состояния isLoading, isSuccess, isError
2. Сообщение об ошибке
3. Отмена запроса через AbortController
4. Глобальное состояние загрузки (на всё приложение)
5. Нормализация данных
6. Инициация повторной загрузки
7. Поллинг
8. Кеширование данных в едином слое и решение об инвалидации.
Веб-приложения они потому и веб, что грузят данные из удалённого источника, необязательно одного. И необязательно сетевые! Об этом ниже.
Уследить за всем непросто, но это полбеды. Тесты писать кто будет на ваши обёртки?
Да, React Query и ему подобные SWR-решения (stale-while-revalidate в клиентских приложениях превратился в целый концепт) не являются вечнозелёными. Термин "вечнозелёный" я принёс сюда из CMS Drupal: там это означало модули, поставляющиеся с ядром системы. Это значит, вероятность их удаления или радикального изменения API крайне мала. В нашем случае вечнозелёными являются браузерные API.
Но вы забываете об одной крайне немаловажной фишке React Query и SWR: они могут работать с любыми промисами. Не только с сетью и fetch!
И вот тут начинается прекрасное. Долгие вычисления? Промис! Забрать картинку с холста? Промис! Обработать загруженный на клиенте файл? Тоже промис! Написать расширение для браузера и обратиться к данным со страницы или результату парсера? Промис! Обратиться к прослойке между Google Sheets и твоим расширением? Промис! То же самое в Excel. То же самое в Figma. Далее вообще везде.
Вы понимаете, к чему я клоню? Хватит думать сетью, начинайте думать операциями!
И вот тут у React Query в моём случае из конкурентов разве что Effector. Но есть одна проблема... его концепты мало того, что сложны, так и обзорных статей не на русском очень мало. Но об этом потом.
Буду закругляться, но напишу ещё кое что о тестировании.
Если React Query принимает на вход любой промис, то что вам нужно для того, чтобы протестировать своё приложение? Поднимать Mock API Server? Вы уверены?
Замокайте вызов промиса! Всё, вы прекрасны. Остальное уже протестировано за вас.
Задавайте ваши ответы, котаны.
#react #query #development
Tanstack
TanStack Query
Powerful asynchronous state management, server-state utilities and data fetching. Fetch, cache, update, and wrangle all forms of async data in your TS/JS, React, Vue, Solid, Svelte & Angular applications all without touching any "global state"
👍19❤1👎1
#заметка дня
Итак, ты хочешь использовать Tanstack (React) Query для запроса данных, но хочешь делать это по-запросу, а не декларативно?
Ни слова больше! Используй useMutation, даже если это контр-интуитивно. Мутации — они по своей природе императивные, их нужно вызывать ручками в нужный момент.
Вот только есть один нюанс: мутацию — опять же, по-определению — нельзя отменить. Если требование изменений ушло на сервер — слишком много телодвижений нужно, чтобы перестать это делать. Нет уверенности в том, что изменения ещё не применились.
Да, даже если мутация, на самом деле, ничего не делает.
А мне надо было, стояла задача подключаться к источникам данных, но иметь возможность это подключение (или несколько) прекратить в любой момент без создания, собственно, токена.
А вот запрос — отменить можно. Прямо в документации: или посылая AbortSignal, или вызывая соответствующий метод клиента, cancelQueries, по ключу запроса.
С мутацией сильно больше телодвижений.
Кстати, вы же в курсе, что ключи действуют как wildcard? todo среагирует и на todo-1, и на todo-2 и так далее. Это не самая очевидная вещь.
Ладно, но всё же, как вызвать запрос императивно?
Очень просто: комбинацией из refetch и параметра enabled в конфигурации хука:
И используем как обычно:
Секрет в том, что теперь refetch можно передать куда угодно и дёрнуть.
Естественно, всегда создавайте кастомные хуки для useQuery и useMutation. Не держите логику в компоненте.
Я ещё люблю отключать refetch по фокусу на окне и по потере соединения. Про идиотскую ситуацию с неправильным определением потери соединения я уже писал ранее.
#react #tanstack #query
Итак, ты хочешь использовать Tanstack (React) Query для запроса данных, но хочешь делать это по-запросу, а не декларативно?
Ни слова больше! Используй useMutation, даже если это контр-интуитивно. Мутации — они по своей природе императивные, их нужно вызывать ручками в нужный момент.
Вот только есть один нюанс: мутацию — опять же, по-определению — нельзя отменить. Если требование изменений ушло на сервер — слишком много телодвижений нужно, чтобы перестать это делать. Нет уверенности в том, что изменения ещё не применились.
Да, даже если мутация, на самом деле, ничего не делает.
А мне надо было, стояла задача подключаться к источникам данных, но иметь возможность это подключение (или несколько) прекратить в любой момент без создания, собственно, токена.
А вот запрос — отменить можно. Прямо в документации: или посылая AbortSignal, или вызывая соответствующий метод клиента, cancelQueries, по ключу запроса.
С мутацией сильно больше телодвижений.
Кстати, вы же в курсе, что ключи действуют как wildcard? todo среагирует и на todo-1, и на todo-2 и так далее. Это не самая очевидная вещь.
Ладно, но всё же, как вызвать запрос императивно?
Очень просто: комбинацией из refetch и параметра enabled в конфигурации хука:
useQuery<TokenResponse>({
enabled: false,
retry: false,
refetchOnReconnect: false,
refetchOnWindowFocus: false,
refetchInterval: false,
queryKey: ['connecting', dsId, connectionKey],
queryFn: async ({ signal }) => {
signal?.addEventListener('abort', cancelConnection);
...
}
});
И используем как обычно:
const {
data: profile,
refetch: startConnection,
connectionStatus,
isFetching: isFetchingConnection,
isError,
} = useConnect(dataSource, ...);
Секрет в том, что теперь refetch можно передать куда угодно и дёрнуть.
Естественно, всегда создавайте кастомные хуки для useQuery и useMutation. Не держите логику в компоненте.
Я ещё люблю отключать refetch по фокусу на окне и по потере соединения. Про идиотскую ситуацию с неправильным определением потери соединения я уже писал ранее.
#react #tanstack #query
❤9👍5