#заметка дня
Давайте продолжим про 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
Forwarded from Dev News от Максима Соснова
How Google handles JavaScript throughout the indexing process
Интересная статья от Vercel про то, как работает краулер сайтов гугла. Эта тема окружена кучей мифов разной степени зрелости. Когда то говорили, что краулер не умеет запускать JS, затем говорили что научился, но не дольше 5 секунд и на старой версии хрома. Ребята из Vercel решили поэкспериментировать с отдачей контента и выяснили интересные особенности работы гугл краулера
Самое важное, что можно выделить: краулер умеет работать с современным синтаксисом JS, а также отлично индексирует сайты, сделанные с применением серверных компонентов (и соответственно стриминга хтмл контента).
В целом в исследовании также много других интересных пунктов (как например тот факт, что индексируются только страницы с 3хх и 2хх кодами. Т.е. если вам необходимо отрендерить экран с ошибкой - лучше его отрендерить на отдельном урле или с помощью 4хх или 5хх кода хттп).
Рекомендую к прочтению, если вы работаете с SEO
https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process
#development #javascript #SEO
Интересная статья от Vercel про то, как работает краулер сайтов гугла. Эта тема окружена кучей мифов разной степени зрелости. Когда то говорили, что краулер не умеет запускать JS, затем говорили что научился, но не дольше 5 секунд и на старой версии хрома. Ребята из Vercel решили поэкспериментировать с отдачей контента и выяснили интересные особенности работы гугл краулера
Самое важное, что можно выделить: краулер умеет работать с современным синтаксисом JS, а также отлично индексирует сайты, сделанные с применением серверных компонентов (и соответственно стриминга хтмл контента).
В целом в исследовании также много других интересных пунктов (как например тот факт, что индексируются только страницы с 3хх и 2хх кодами. Т.е. если вам необходимо отрендерить экран с ошибкой - лучше его отрендерить на отдельном урле или с помощью 4хх или 5хх кода хттп).
Рекомендую к прочтению, если вы работаете с SEO
https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process
#development #javascript #SEO
Vercel
How Google handles JavaScript throughout the indexing process - Vercel
Over the years, Google's treatment of JavaScript has changed, leaving us with misconceptions of how it's indexed. Here, we debunk the myths.
👍10