Development

Статья про типовые проблемы в проектах на React. Статья весьма субъективная, но вполне злободневная и со многим хочется согласиться. Основная проблема React - это сообщество. В статье на этот счет есть забавная цитата: Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way. Какие советы дает атвор: - Не пишите на React (да и вообще на другом фреймоврке) если вам это не нужно. Простой JS код проще поддеррживать, тестировать и воспринимать. В целом совет звучит очень радикально, но, мне кажется, тут смылс в том, чтобы не завязываться на фреймворк там, где это не нужно. - Избегать встроенных инструментов для управления стейтом - Не складывать логику в кастомный хуки. Это сложно читать, сложно дебажить и сложно тестировать. - Избегайте хайповых игрушек типа Suspense. Используйте скучные, проверенные инструменты. И опять хорошая шутка от автора: You know the joke about the Suspense? You know why is it called Suspense? It takes 4 years to release it. - Избегайте культа иммутабельности. Полностью согласен с этим пунктом - иммутабельный код хорош только в языках, которые спроектированы под имутабельность. В нашем контексте код только усложняется, зачастую не принося большой пользы. - Игнорируйте тех, кто разрабатывает фреймворки. Их советы хороши лишь в теоретических рассуждениях, но этим люди не умеют поддерживать большие реальные приложения и их советы зачастую вредны. - Храните логику на бекенде. Используйте BFF. Это хорошо работает и это легко тестировтаь и дебажить. Повторюсь, что статья очень субъективна. Но я в целом с ней согласен. В своих проектах я стараюсь форсить политику использования React только для рендера. Любую логику (запросы, логика приложения, подготовки данных) стараюсь выносить из компонентов в другие сущности.

Команда Wix применила worker threads в своём nodejs приложении и уменьшила потребление ресурсов этим приложении в своем kubernetes кластере на 70%. Статья достаточно короткая. В рамках неё разбирается что же такое worker threads (механизм в nodejs для вынесения сложных вычислений в треды из основного потока) и какие есть готовые решения для использования этой технологии. Перевод приложения на треды нетривиален (треды требуют чтобы между процессом и тредом летали "чистые" данные, что может потребовать значительного рефакторинга кода), но для Wix он определенно стоил того. В конце статьи раскрываются изменения различных показателей сервиса. Например, теперь требуется на 70% меньше подов, улучшились метрики по скорости ответа, в 10 раз уменьшился рейт ошибок. Эти цифры и есть самое важное в статье. Если у вас есть сложные вычисления на nodeJS, то вы можете также расчитывтаь на значительноее улучшение перформанса при переводе вычислений в треды.

Статья в блоге Мартина Фаулера про противостояние продуктовой и инженерной команды. Это противостоняие является дисфункцей и негативно сказывается на развитии продукта. Данный блог пост является частью серии постов про проблемы при масштабировании стартапа. Основные проблемы, когда разработка продукта разделена на продуктовую команду и инженерную команду: - Инженеры не обладают продуктовым контекстом - Перекидывание задачи через забор в зону отвественности другой команду - Игнорирование технического долга - Команды общаются, но не занимаются совместной работой Из основных решений: - Выделить правильные stream-aligned команды. Эти команды должны быть кросс-функциональны и сфокусированы не вокруг своей области работы, а вокруг метрик продукта - Совмещать продуктовые и инженерные нужны продукта Статья на самом деле достаточно большая и я очень сильно утрировал её смысл. Если вам интересна эта тема - рекомендую к прочтению

В react сообществе столько разговоров было о новом useEvent и оптимизациях рендера, а теперь команда react решила, что текущий rfc недостаточно хорош. Текущее предложение объединяет в себе и новую семантику для функций и оптимизацию рендера. Вместо этого команда разделит текущий RFC на несколько и учтет пожелания сообщества. Поэтому ожидаем нового хука, но с другим (возможно) именем и другими рекомендациями к использованию

Интересный инструмент для линтинга текстовых файлов и markdown, который поддерживает кастомные плагины.

Огромный гайд по написанию авто-тестов c Cypress. Рассматривается, почему нужно брать именно Cypress, какие основные примитивы там есть, как мокировать запросы и дебажить поломанные тесты. Если вам интересен cypress - рекомендую к прочтению

Анонсировали typescript 4.9 Beta и там, наконец-то, появилась фича, которой мне давно не хватало. Иногда, хочется написать объект, который бы соответствовал определенным ограничениям, но при этом работал бы автоматический вывод типов для более точного автокомплита. В текущем TS нужно либо смириться с тем, что на объект нельзя удобно навесить ограничение, либо что придется описывать тип "руками" Например, я хочу описать конфиг, в котором ключи - в общем-то любые строки, но значения - либо тип A, либо тип B. Но при этом конкретный ключ - он всегда определенного типа Я могу описать это так ``` const config = { first: makeA(), second: makeB() } ``` Тогда у меня будет хорошо работать автокомплит, но при добавлении новых свойств в конфиг разработчик может ошибиться и никто его не остановит Либо я могу описать так ``` const config: Record'first' | 'second', A | B = { first: makeA(), second: makeB() } ``` Но тогда при каждом доступе к ключу first или second мне придется доказывать, какого они типа. Эту проблему решает новый оператор `satisfies`. Он позволяет как бы написать проверку на то, что объявленная переменная совместима с указанным типом, но при этом этот тип не "приклеивается" к переменной ``` const config = { first: makeA(), second: makeB() } satisfies Recordstring, A | B ``` Теперь у меня одновременно и будет корректный автокомплит и TS сообщит, если кто-то закинет в конфиг что-то "неправильное"

Объявлены победители js13kgames 2022. js13kGames это сореврование, в котором участники должны написать игру на Javascript, которая занимает не более 13КБ. Рекомендую к просмотру. Некоторые игры достаточно занятные

Вы, наверное, слышали о том, что KPI неэффективен в области разработки т.к. люди хакают эти KPI и, в итоге, можно наблюдать занятный эффект - по метрикам все хорошо, но в реальности все плохо. Этот феномен также был описан в книге "Цель" Голдрата. Но с KPI всё понятно, но как далеко этот опыт можно экстраполировать? На этот вопрос отвечают закон Гудхарта, "критика" Лукаса и закон Кэмпбелла, волна Де Брюйна. Давайте вкратце рассмотрим каждый из них Закон Гудхарта гласит, что если государство регулирует какую-то конкретную экономическую переменную, то участники системы будут улучшать значение этой переменной, не совершествуя работу самой системы. "Критика" Лукаса описывает, что если предсказывать эффект от изменений в экономике, основываясь только на данных и фактах, то это будет неэффективно т.к. всегда есть ряд параметров, которые невозможно учесть в рамках статистики Закон Гудхарта и "критика" Лукаса рассматривают макро-экономику. Чуть ближе к обычным людям этот же феномен описал Кэмпбелл. Согласно закону Кэмпбелла, введение каких-либо критериев оценки функционирования **социальных** и бюрократических институтов неизбежно приводит к тому, что искажаются как сами индикаторы оценки, так и процессы, которые эти индикаторы оценивают. Социальные институты - это уже ближе к повседневной реальности. Однако Де Брюйн адаптировал закон Гудхарта для организаций. Де Брюйн построил параболическую кривую, которая отражает следующую закономерность: чем больше руководство компании стремится оценивать эффективность своих сотрудников по количественным показателям, тем меньшую производительность деятельности и ее эффективность В общем, о чем это я. Если вы занимаетесь поcтановкой целей и хотите измерять достижение цели с помощью измеряемых показателей, то имейте в виду, что люди устроены так, чтобы "хакать" любые измеряемые показатели. И это нельзя решить объяснениями, взращиванием "правильной" культуры. Фокусируйтесь на достижении целей, а не достижении целевых показателей.

Вышел 1.0.0 релиз axios'а. Axios - это, наверное, самая популярная либа для делания сетевых запросов (или, по-крайней мере, была такой). Но при этом axios находился в вечной бете (0.х.х версии). Какое-то время даже был слух, что разработка axios приостановилась. Однако, 4 октября вышел в свет релиз 1.0.0. Хотя к 7 октября уже вышла 1.1.2 - видимо пришлось залить в короткие сроки много фиксов. С одной стороны, ничего принципиально нового не случилось. С другой стороны, это знаменательное событие для axios.

Meta опубликовали свой инструмент для поиска утечек памяти в JS приложениях под названием MemLab в открытый доступ. Как я понял, MemLab использует puppeteer для навигации по сайту, а затем сравнивает снапшоты памяти для поиска потенциальных кандидатов на утечку. Также MemLab предоставляет удобный интерфейс для анализа "утёкших" объектов. В статье нет глубоких технических подробностей о работе инструмента, но зато есть кейс самой Мета - они уменьшили количество крашей страниц на Facebook из-за нехватки памяти в 2 раза с помощью MemLab. Также есть несколько конкретных кейсов: утечка памяти из-за React Fiber реализации и утечка памяти из-за Relay

Команда preact рассказала про разработанные ими сигналы (signal) Сигнал - это новый (в preact) способ описания стейта, который очень близок к реактивным атомам. ``` import { signal, computed } from "@preact/signals"; const count = signal(0); const double = computed(() = count.value * 2); function Counter() { return ( button onClick={() = count.value++} {count} x 2 = {double} /button ); } ``` Сигналы - быстры, удобны и мало весят (1.6КБ). В статье перечисляются минусы традиционных подходов (хуки, селекторы, контексты). Все они сводятся к тому, что из коробки у них либо недостаточно производительности (т.е. нужно делать много дополнительных усилий для достижения оптимальной производительности) либо плохой DX (developer experience) либо и то и то сразу. Сигналы же решают обе проблемы сразу С точки зрения DX, сигналы очень просты - объяви сигнал, используй его в вёрстке и все будет работать из коробки. С точки зрения разработчика сигнал, как абстракция, немногим сложнее обычной переменной С точки зрения перформанса, команда preact сделала нативную интеграцию virtual dom и сигналов. Это позволяет при обновлении значения сигнала ререндерить только то, что действительно использует значение из сигнала. При этом они пошли еще дальше и могут определять, когда vdom вообще перестраивать не нужно, достаточно сразу поменять DOM-элемент - это кейс, когда мы связываем сигнал и dom-атрибут Выглядит очень интересно, а также наглядно показывает, почему вообще появляются реактивные инструменты для создания UI

Новый пост от Dr. Axel Rauschmayer, теперь про то, как работает Node.js. Рассмотрены следующие моменты: - Архитектура Node.js (где там Node.js, где v8, а где С++ код) - Встроенные возможности и глобальные переменные - Как работает event loop и асинхронное взаимодействие - Разница между асинхронным и синхронным I/O в рамках libuv - Возможности для многопоточности в Node.js Рекомендую, если вы хотите ознакомиться с Node.js или если вы работает на Node.js и вам интересно, как устроена внутренняя асинхронность

Статья про то, что open space офисы негативно влияют на качество сложной работы. Даются ссылки на исследования, книжки и рекомендации по организации работы в офисе. А затем это все переводится на реалии удалёнки т.к. удаленка может взять худшее из open space офисов. Работу над задачами можно разделить на 2 режима - "с погружением" и "на поверхности" (deep work и shallow work в оригинале) В первом режиме требуется концентрация и фокус. Эта работа создает что-то новое, развивает навыки, её нельзя просто так повторить или сделегировать Во втором режиме задачи не требуют большой когнитивной нагрузки. Так вот, типичный open space офис, в котором единое пространство для всех, не способствует первому режиму работы. Это подтверждается различными исследованиями. С другой стороны, для эффективной работы нужна коллаборация. В итоге хорошая организация работы в офисе - это дать возможность для эффективной совместной работы (например, наличие удобных переговорок) и также дать возможность для эффективной работы в режиме фокуса (например, изолированное личное пространство). Это рецепт для достижения идеальной продуктивности работы в офисе. Называется это *hub-and-spoke architecture*. Однако, с приходом COVID все мы перешли на удаленку и, казалось бы, проблемы open space офисов должны быть неактуальны. Но, на самом деле, у удалёнки есть схожие проблемы. Нажать кнопку в Zoom'е так просто, что все начали организовывать созвоны в любое доступное время. Отправить вопрос в чат проще, чем подумать самому. Это все ведет к тому, что удаленка превращается в цифровой open space - здесь нет места концентрации, только беспорядочные коммуникации. В статье рассказывается, как применить практики *hub-and-spoke architecture* в удаленной работе. Утрированный список советов: - Если у вас есть коллеги и в офисе и на удалёнке, то следует работать так, как будто все сидят на удалёнке - Используйте разные каналы коммуникации для разных целей - Организуйте рабочее пространство. В идеале - отдельная комната с дверью - Организуйте себе возможность сфокусированной работы. Отключив уведомления, мессенджеры, зумы и все такое (автор предлагает запускать помидорку и отключать wifi на время помидорки, звучит неплохо на мой взгляд) - Используйте правильные инструменты для совместной работы. Возможности IDE, борды в MIRO и тд - Сделайте канал для неформального общения среди коллег Рекомендую статью к прочтению

Одна команда решила перевести свои браузерные тесты с Cypress на Playwright. Это монотонная и скучная работа, которую, тем не менее, надо сделать. Однако, одному разработчику пришла мысль "а что если использовать для этого нейронку?". И оказалось, что это очень хорошая идея. Он открыл openai playground, где можно поиграться с нейронкой GPT-3 в рамках чата. Он отправил ей ``` Example Input: /* cypress code */ Output: /* playwright code */ Input: /* cypress code №2 */ ``` и нейронка вывела корректный перевод cypress code №2 на playwright. Автор говорит, что это позволило им значительно ускорить переезд на playwright, а также они использовали нейронку на уже переведенным людьми тестах, чтобы найти моменты для улучшения Рекомендую зайти в статью и пролистать её вниз, где есть гифка как GTP3 пишет код в чате. Мы все ближе подходим к моменту, когда нейронки будут сопровождать нас на постоянной основе. Так недалеко и до киберпанка

Очень хорошая статья про Dependency Injection с примерами кода на TS. Флоу статьи: - Что такое Dependency Injection - Проблема с гибко vs удобно использовать. Если делать слишком гибко, то становится неудобно использовать. Это ловушка, в которую попадают все, кто пробует DI. Из-за этой ловушки DI кажется бесполезной игрушкой для чистой архитектуры, а не реальных проектов. Но совместисть гибкость и удобство использования можно. - DI позволяет варировать реализацию функций через внедрение разных зависимостей - DI позволяет замокировать что-то в разработке, без изменения кода приложения - DI на классах - Почему важно правильно определять, что является зависимостью сервиса, а что не является. Если начать все выносить в DI, код станет слишком сложным и неподдерживаемым - Composition Root - место, где мы инстанцируем все сервисы и их зависимости. Также это называется DI контейнер - Автоматические DI контейнеры - самописные и из npm - Проблема циклических зависимостей - Проектирование сверху вниз с помощью DI Цитировать статью не буду т.к. там очень много и тяжело это адаптировать для канала. Лучше выделите 20-30 минут своего времени и прочтите статью. Она очень хороша.

Ещё одна статья, в которой рассказывается, почему не стоит использовать `export default`. В кратце: - Автокомплит не подсказывает, что у модуля есть `export default`, если вы начали делать импорт через `{ }` - То, что экспортируется через `export default` может быть импортировано под любым именем. Это создает сразу несколько проблем: возможность криво назвать, то что импортируется; возможность назвать по-разному одну и ту же сущность в разных файлах; возможность неконсистентного именования при импортах из пакетов Если вам нужен аргумент против использования `export default` в своих проектах - посмотрите эту статью. В целом у `export default` есть боле мене адекватные места для применения. Например, библиотеки. `import React from 'react'` - это как раз случай, когда `export default` не делает хуже. Хотя и с именоваными экспортами было бы нормально. Лично я предпочитаю забанить `export default` в проектах на уровне линтера. Отсутствие адекватного автокомплита и возможность накосячить с именованием слишком сильно бьют по DX в проекте

JSON Crack - визуализатор JSON'а. Вы загружаете в него JSON, а он отображает его как дерево. Из фичей - есть поиск и экспорт получившегося дерева

ReacType - инструмент для прототипирования интерфейсов, который позволяет делать и редактировать интерфейсы для React в визуальном редакторе. То есть можно накидывать интерфейсы используя базовые компоненты, размещая их на холсте, но при этом не написав не строчки кода, а затем экспортировать React-код. Либо можно править код прямо на месте, либо загрузить в редактор код и поиграться с интерфейсом. Из интересных фичей - инструмент умеет показывать граф данных, которые используют компоненты (из хуков, пропсов, контекста). Подход с визуальным программированием отлично ложиться на 2 кейса: обучение и работа с непрограммистами (например, дизайнер, продакт или пользователь продукта могут не словами описывать, что они хотели бы видеть - а могли бы накидать интерфейс). У меня большие сомнения на счет production использования ReacType, но, как и любой инструмент для визуального программирования, выглядит интересно

Новый туториал от Dr. Axel Rauschmayer, в этот раз про то, как работают запускаемые файлы (bin) в npm пакетах. Очень подробно рассказано, как же так выходит, что вы пишете `npx somepackage`, а npm запускает что-то конкретное. Рекомендую к прочтению. Там и про то, как регистрировать bin файлы в пакете, и куда они устанавливаются и как этим управлять, и как проверять пакеты через `npm link` (и альтернативы линковке) и про кэши. В общем, ИМХО, очень полезная статья для любого фронтенд-разработчика.

Еще одно сравнение перформанса bun, deno и nodejs. В этот раз сравнение идет на основе дашборда проекта Mitosis. Там есть какая-то бизнес-логика и это боле мене похоже на реальное приложение. Сравнивалась скорость SSR рендера этого приложения для этих рантаймов. Напомню, что bun на своей страничке обещает что он в 3 раза быстрее чем deno и node.js. В этом замере это не подтвердилось, но цифры все равно получились впечатляющие. Bun оказался в 2 раза быстрее node.js и на 10% быстрее deno.

Статья от автора книг "JavaScript testing best practices" and "Node.js best practices". Он рассматривает популярные в node.js мире паттерны и инструменты и оценивает их с точки зрения, насколько это актуально сейчас и какие есть альтернативы. Короткий список: - Dotenv для загрузки конфига из .env файла = Предлагается использовать `convict` - Жирный сервис, вызываемый из контроллера = Предлагается декомпозировать, создавая use-case - Закинуть все в DI (например в Nest.js) = Предлагается закидывать только то, что нужно конфигурировать - Passport.js = Слишком жирное решение, вместо комбайна следует использовать точечные библиотеки - Supertest для тестов api = http-библиотека + assert'ы от фреймворка тестирования - Декораторы fastify для функций (не для обработчкиов реквеста или веб-утилит) = корректная декомпозиция - Логирование из catch = Дополнение контекста ошибки в catch, но единое логирование в глобальном обработчике - Использование morgan = Используйте удобный вам логгер, напишите руками небольшую мидлварку - Условия на `NODE_ENV` = следует избегать Я очень сильно утрировал. Какие-то пункты очень странные. Я, например, не знал, что кто-то использует API fastify, потому что лень самим декоратор написать над функцией. Но во многих пунктах полезно прочесть не конкретную рекомендацию (они как раз неинтересны), а то, почему текущий паттерн - может быть плох, и на каких принципах следует основывать выбор паттерна или инструмента

Статья про trade-off между качеством и скоростью. Часто так бывает, что команды разработки готовы пожертвовать качеством, для того, чтобы увеличить свою скорость разработки. Это может исходить как от стейкхолдеров, так и от самой комманды разработки. В статье дается также определение высоко-качественного ПО: - Делает то, что должно делать - Безопасное - Поддерживаемое - Делает то, что нужно пользователю Проблема в том, что размен качество на скорость создает негативную обратную связь. Снижаем качество = снижается скорость, нам это не нравится, мы еще раз снижаем качество. В статье говориться, что trade-off качество-скорость - ложный. Его не существует. Мы не должны никогда резать качество в угоду скорости. Если мы хотим разрабатывать быстро, то надо разрабатывать качественно Что же предлагается делать? - Строить культуру ответственности команды разрабокти за качество производимого - Подерживать высокие стандарты качества - Встраивать качество в процессы и оценку Немного своих мыслей: хороший вопрос, который остался без ответа "что такое качество?" (ну точнее в статье ответ есть, но он очень абстрактный). Нужно ли нам всегда делать безупречное ПО? Действительно ли нужны безупречные интерфейсы? Действительно ли в каждой фиче следует следить за поддерживаемостью решения? Для меня очевидно, что нет. ИМХМО, разные контексты требуют разного отношения. Степень "безупречности" будет отличаться для маркетингового лендинга и формы оплаты. Для лендинга, который будет жить всего неделю - не иметь автотестов, архитектуры, какие-то огрехи в UI и UX - это норма. Это то качество, которое нам требуется. Но для формы оплаты так не подойдёт - там цена бага большая, как и цена плохого дизайна системы.

Скоро выйдет Storybook 7.0 и команда storybook начинает рассказывать про изменения. На этот раз пост посвящён новому дизайну интерфейса storybook. Обновили layout, встроили основные инструменты в интерфейс storybook (показ сетки, изменение вьюпорта, смена цвета бекграунда). Кроме изменений интерфейса storybook также теперь поставляет свой интерфейс предсобранным. Раньше, при сборке storybook проекта, кромме историй проекта собирался и сам storybook. Это занимало время (и непонятно зачем так вообще надо было делать). Теперь storybook поставляется предсобранным, что ускоряет старт проекта.

В блоге Deno команда разработки поделилась планами на Deno. И как же два основных направления похожи на то, что предлагает bun - совместимость с nodejs API и самый быстрый рантайм. Первое направление для работы - совместимость с существующими пакетами в npm. Изначально, команда Deno не ставила себе целью сделать так, что любой npm пакет мог бы работать на Deno. Deno предлагает web-совместимый API, но пакеты, расчитывающие на nodejs api - не работали. Однако запрос от сообщества есть. Все хотят просто поставить пакет из npm и чтобы он просто работал. Deno планирует сделать так, чтобы 90% пакетов npm работали в Deno. Второе направление для работы - это перформанс. Буквально "Our goal is to make Deno the fastest JavaScript runtime". Также из интересного еще рассказано про автодокументацию 3rd-party пакетов от Deno. Deno планирует собирать документацию для всех пакетов, публиковать ее и индексировать для создания единого поиска по документации всех пакетов Deno экосистем.

На обсуждение TC39 представлен пропозал про добавление аннотаций типов в JS. Данный пропозал предлагает добавить в стандарт основные уже существующие способы описывать типы. Цель данного пропозала - не добавить типизацию в JS, а только лишь добавить синтаксис для типов, который браузер будет отбрасывать (воспринимать как комментарии к коду). Зачем это нужно? Ну, на это есть несколько причин: JS давно требуется типизация, но как её внедрить - непонятно. Стандартизация аннотаций - первый логичный шаг. Браузер при этом будет В стандарт предлагается ввести самый популярный синтаксис для объявления типов. Это полезно по нескольким причинам. Во первых, мы на шаг ближе к тому, чтобы не транспайлить простой типизированный код. Во вторых, стандартизация синтаксиса для типов позволит привести тулинги проверки типов к единому знаменателю. А это значит, что могут появиться новые имплементации проверки типов, между которым будет возможен легкий переход. В целом, ИМХО, выглядит как отличный первый шаг. Но пока stage 0. А это значит что пропозал пока не обсуждался комитетом и путь до stage 4 будет очень долгим.

Достаточно большой читшит разных трюков для написания программ, где размер кода критично важен. Например, это разные челленджи вида "напиши свой твиттер\игру\блог и умести его в 3кб кода". По сути, весь читшит - это инструкция как самому стать минификатором кода. Некоторые хаки очень даже элегантны, если можно применить к ним такое слово. Ниже представлены примеры кода, которые мне особенно понравились в `setTimeout` и `setInterval` можно передавать строки, вместо функций ``` setInterval(function(){console.log("z")},100) // before setInterval('console.log("z")',100) // after ``` Обмен значений переменных ``` var a=1,b=2,c;c=a;a=b;b=c // before var a=1,b=2;a=[b,b=a][0] // after var a=1,b=2;a=b^a^(b=a) // after - not as useful, but can come in handy ``` Use `[]._` instead of `undefined` `""._, 1.._` and `0[0]` also work, but are slower. `void 0` is faster than `undefined` but longer than the alternatives. Более короткий вариант `Math.round` ``` Math.round(a) // before a+.5|0 // after ``` Является ли x - функцией? Instead of using typeof x=='function', you can use /^f/.test(typeof x).

Сайт-учебник про паттерны для веб-приложений. Паттерны оень хорошо описаны и визуализированы. Сам сайт не очень большой, но там есть ссылка на основной труд - книгу про паттерны проектирования веб-приложений на 435!!! страниц. Рекомендую к просмотру

Состоялся релиз Astro 1.0! Astro - это веб-фреймворк, который ставит перформанс в приоритет. Центральная концепция - Island Архитектура. Фреймворк разбивает UI на изолированные компоненты, которые грузятся независимо друг от друга. Также фреймворк стремится отсылать 0 JS в браузер, загружая его только по необходимости.

Статья от команды Basedash про то, как она в течение года использовала React Query, но решила уйти обратно в fetch + redux для загрузки и хранения данных. Основная проблема, на которую указывают в посте, это изменение данных в кэше React Query. Например, вы загрузили данные о пользователе и пользователь из интерфейса обновил свой логин. Теперь вам надо чтобы во всех местах, где был useQuery с данными пользователя, обновился логин. Вы можете сбросить кэш и тогда React Query сделает новый запрос, но это лишний сетевой вызов и, возможно, мигание интерфейса. Вы можете использовать внутреннее API React Query для изменения сохраненных в кэше данных. Но и тут все непросто т.к. надо про это не забыть и правильно все вызвать, чтобы обновилось действительно во всех местах использования данных. Я очень коротко пересказал суть проблемы, в статье это описано немного подробнее. Поэтому команда решила использовать загрузку данных через fetch и складывать все в redux. При этом используют мощь redux-toolkit и нормализации данных