Опыт команды superhuman, которая разрабатывает веб-приложение для работы с почтой с поддержкой работы в оффлайне. Статья достаточно короткая, но хорошо показывает основной челлендж offline-first приложений - синхронизация того, что наделал пользователь с данными в оффлайне с тем, как изменились данные в мире, пока пользователь был в оффлайне. Эта проблема усложняется тем, что пользователь может делать изменения в нескольких вкладках на одном устройстве.

Moon - еще один тулинг для организации monorepo для фронтенд-проектов.

Архитектура фронтенда - сложная тема. Во первых, большинство практик по разработке хорошо подходят для backend разработки, но плохо подходят для frontend разработки Во вторых, почти на каждый аспект системы в фронтенде необходимо принимать решение. Свобода выбора такая, что одну и ту же задачу можно решить тысячью способов, перебирая разные подходы и библиотеки. В данной статье автор высказывает свою позицию относительно архитектуры фронтенд приложений. И это позиция очень хороша. Чтиво достаточно долгое - у меня заняло около 40 минут. Но чтиво очень хорошее. В целом автор рассказывает про самые базовые принципы хорошей архитектуры. Они верны для любой разработки, в том числе и для фронтенда. Цель хорошей архитектуры - предоставить способ построить поддерживаемое, тестируемое, гибкое приложение 2 основных принципа: Command Query Separation и Separation of Concerns CQS говорит о том, что нужно разделять получение данных (query) и изменение данных (commands) Separation of Concerns говорит о том, что нам нужно явно разделять ответственность слоев архитектуры. Также в статье подробно рассмотрено как применить эти принципы на практике, при этом нет жесткой привязки к инструментам (кроме React'а) - можно это реализовать и на GraphQL и на redux и на хуках. Кроме этого, автор рассказывает про основные архитектурные паттерны, считающиеся классическими (чистая архитектура, MVC и тд) В целом, статья реально хорошая и рекомендую ее к прочтению всем, кто заинтересован в архитектуре фронтенд-приложений. Кроме того у автора в целом достаточно хороший блог. Лично я подписался.

Короткая статья, рассказывающая про новый хук useEvent и проблемы, которые он решает.

Google собирает информацию по производительности страниц с миллионов открытий страниц в браузере Google Chrome. Эта информация есть в свободном доступе, а значит ее можно использовать для разного рода анализа. В этой статье эти данные используются для анализа корреляции между производительностью сайта и фреймворком, который он использует. Очень занятная статья. тлдр: - сайты без использования фреймворков в среднем быстрее - в анализе большинства метрик производительности все фреймворки выдают +- одинаковую цифру. Однако в некоторых замерах некоторые фреймворки могут сильно отличаться. Например, в части метрик Angular сильно отстает от вообще всех фреймворков Какие выводы можно сделать: - Не особо важно какой у вас фреймворк. Важно то, насколько вы нацелены сделать быстрый сайт и насколько хорошо вы умеете это сделать. - Сайты без фреймворков открываются быстрее. - Есть очень интересные способы использовать доступные в интернете данные о сайтах и пользовательских сессиях

Неплохая статья про то, почему fastify должен восприниматься как стандарт для создания вбе-серверов на nodejs вместо express Собственно вся статья сравнивает fastify с express. Когда-то мне не хватало именно такой статьи чтобы ссылаться на нее при рекомендации взять fastify вместо express или koa. В статье упоминается что fastify лучше чем express потому что: - Более адекватное API для расширения функционала - Перформанс - Некоторые вещи есть пря внутри fastify Того, чего нет в статье, но что я оценил в свое время в fastify - typescript first - встроенное апи для тестирования сервера. Вместо того чтобы приседать с поднятием сервера через какой-нибудь supertest, в fastify из коробки есть возможность эмулировать обработку запроса, и эмулированный запрос пройдет все стадии обработки также, как и настоящий

Дэн Абрамов добавил RFC на новый хук useEvent. Если совсем утрировать, то это как useCallback, но без приседаний с мемоизацией. Т.е. обычно, чтобы правильно использовать useCallback, мы должны передать все, что используется внутри useCallback как зависимости, а значит на каждое изменение зависимости - будем изменяться и ссылка на функцию, что может привести к лишним ререндерам. У этой проблемы были разные воркераунды, но теперь команда react решает эту проблему на уровне инструменте с помощью нового хука. По ссылке можно прочесть обсуждение и сам RFC.

Вышел React 18. Кажется об этом не сказал только ленивый, поэтому я просто приведу краткий список фич: - React теперь умеет в concurrent render. Подробнее лучше почитать в статье - Suspense можно начинать использовать в фреймворках. - React теперь умеет автоматически батчить изменения. Например, при вызове подряд двух setState, теперь будет всего 1 ререндер (следствие concurrent render). - Добавлена фича Transitions. Она позволяет выделить обновления UI, которые не требуют срочного ререндера. - Обновлены render-методы для ReactDOM - Новое интересное поведение Strict Mode. Strict Mode в режиме разработки тепреь будет эмулировать анмаунт и маунт компонента, чтобы проверить, есть ли в компоненте нежелательные сайд-эффекты. Также в Канале SuperOleg dev notes есть разбор нового реакта в плане перформанса (тлдр: React 18 - быстрее по пользовательским метрикам и выдает больше RPS) Подробнее: https://t.me/super_oleg_dev/49

Bulletproff-react - еще один гайдлайн по архитектуре react приложений. С одной стороны - ничего нового. С другой - гайдлайн неплохо описан

Opinionated список рекомендаций для проектов на React. Описаны рекомендации от написания кода компонентов, до тестирования кода и производительности приложения.

На хабре вышла статья от Miro про ускорение SPA приложения. В статье нет явного указания, что Miro оптимизировали свое приложение. А было бы интересно посмотреть, какие у них были проблемы и как они их решили и как это повлияло. Эта статья об оптимизации загрузки сайта в общем случае. В целом неплохая статья. Радует что очень подробно описано выделение контента, который нужен не сразу, в отдельные чанки

Asciinema - приложение для записи действий в терминале и плеер для их воспроизведения. Само приложение интересно с технической точки зрения и об этом можно почитать у них в документации. Но этот пост про обновление 3.0 - цель которого - улучшить перформанс. Стек изменился с clojurescript + react на rust + solid, что позволило ускорится в более чем 50 раз.

Когда SPA-фреймворки только пришли, было нормой делать сайты без SSR вообще. В итоге пользователь видел белый экран, пока не загружался и не исполнялся весь JS, который уже все рендерил. Следующей итерацией было делать SSR и затем полный ререндер приложения в браузере. Т.е. грубо говоря, мы рендерим всю верстку на сервере, а затем рендерим ее же в браузере и заменяем первую на вторую. В идеале различий не должно быть, но мы тратим время на замену всего DOM-дерева приложения. Потом фреймворки научились переиспользовать тот DOM, который был отрендерен во время SSR. Этот процесс назвали гидрацией. Это уже намного лучше того, что было ранее. Но для полноценной работы сайта требуется загрузить весь JS и подождать, пока все приложение гидрируется. Только после этого инпуты и кнопки "оживали". В данной статье описывается следующий шаг - частичная гидрация. Это когда мы гидрируем только то, что реально нужно гидрировать сейчас. Например, нам важно быстро гидрировать то, что показывается пользователю на первом экране. А все что ниже - можно гидрировать по-позже. Также в статье, кроме описания самой техники, сравнивается, как различные фреймворки и библиотеки подходят к частичной гидрации

Использование Any в typescript считается анти-паттерном. Наверное, вы встречались с этим утвержденеим в докладах и общении на конференциях или даже в своей команде. Люди готовы вложить много усилий в то, чтобы в коде не было ни одного any (есть даже eslint правило, запрещающее any в коде). Однако, нам не следует быть такими категоричными на счет any. Any подходит для случаев когда: - Вы мигрируете код с JS на TS и вы не можете протипизировать все разом - Вы используете библиотеку с плохими тайпингами - Проверки TS требуют от вас лишних телодвижений. Например, вы написали код и уверены что он работает, вы покрыли его тестами. Но TS выводит ошибки в типах. В некоторых случаях угодить TS - сложно. В таком контексте применения any - обосновано. - Вы дейсвтительно ожидаете any. Контексты для использования any - единичны. Поэтому в tsconfig следует включить опцию noImplicitAny, чтобы все any были явными.

Небольшая статья про бест-практисы использования Context в React.

Вышел SWR 1.0 - hook для реакта для запроса данных. С релизом 1.0 много сделано для перформанса (уменьшен вес библиотеки) и все покрыто тестами. Если вы искали как дергать API из компонентов - можно посмотреть на SWR

40 бесит практисов для интеграционного тестирования сервисов на nodejs. Многие советы никак не привязаны к технологическому стеку

Практически для любого контента нам нужно уметь показывать 4 состояния: - ожидание - загрузка данных - ошибка загрузки - успешная загрузка В статье рассматриваются два способа реализации этих состояний в react компоненте. По сути это: - условия в разметке - отдельные компоненты Оба способа имеют свои плюсы и минусы и подходят в разных контекстах

Статья про антипаттерн, когда чаилд-компонент работает с передаваемым ему апи, зная его реализацию В частности, когда в чаилд компонент передаётся setState от родителя Из минусов статьи - аргументация. Это плохо потому что это плохо и вообще не надо так.

У вас есть 2 обьекта одного типа Type. type Type = { a: string, b: number } Функция принимает параметр key типа keyof Type и перебрасывает из одного обьекта значение key в другой обьект. function fn(key: keyof Type) { obj1[key] = obj2[key] } В этом случае Typescript будет думать, будто-бы мы ЛЮБОЙ ключ obj2 кидаем в ЛЮБОЙ ДРУГОЙ ключ obj1. Т.е. rак будто пытаемся записать string | number либо в поле с типом string, либо в поле с типом number. Typescript кинет ошибку т.к. ему нужно доказать что мы правильно перезаписываем поля. Такое поведение неочевидно, потому что для разработчика ожидаемое поведение другое. Из кода понятно, что мы не можем тут записать неправильный тип данных. Решение для этой проблемы, а также пара других похожих проблем можно прочитать в статье.

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

Команда поиска Яндекс внимательно следит за производительностью своего поиска. Поиск яндекса - пример бизнеса, в котором производительность критична. У команды поиска уже были хорошие доклады про то, как они следят за перформансом своего приложения. Теперь же они оформили свой опыт оптимизации исполнения кода в виде статьи на хабре.

Еще одна статья про проектирование маленьгого react приложения вместе с xstate

Пошаговый пример проектирования небольшой страницы с помощью XState

Тул для удобной автоматической публикации npm пакетов от Microsoft. - Синхронизирует гит и нпм - Генерирует ченджлоги - Сам поднимает версии по семверу - Работает как с моно-репо и так и single-репо - 0-config

Расширение для vscode для автоматического рефакторинга JS и TS кода. Некоторые рефакторинги выглядят весьма впечатляюще

Статья от Dr. Axel Rauschmayer про монорепы с использованием npm, который умеет в workspaces, и примером правильной настройки tsconfig в рамках монорепы

Бест практисы для тестирования во фронтенде: - Следовать DRY и KISS - AAA паттерн - arrange, act, assrt - Правило трех (Что проверяем, в каких условиях и что ожидаем) - Изолированный стейт для каждого теста - Отдельные селекторы для тестирования (data-test-id) - Ожидать чего-то конкретного (например элемента), а не просто wait(500)

Opinionated топик про тестирование фронтенд-приложений - какие тесты и на каких уровнях нужно писать, а какие комбинации писать не нужно Из плюсов: учитывается архитектура и здравый смысл. Из минусов: за все хорошее, против всего плохого

Typehole - расширение для vscode, добавляющее описание интерфейса typescript на основе данных в рантайме. Как это работает: - допустим вы делаете запрос в апи и не знаете что оттуда приходит - вы оборачиваете res.data в специальную функцию typehole - typehole в рантайме проверяет объект и отсылает в редактор описание интерфейса - расширение добавляет интерфейс в код Выглядит волшебно