Development

Статья про создание самой маленькой либы для валидации схем. В целом это статья не про валидацию схем, а про проектирование библиотеки с минимальным размером. Конкретно здесь автор влез в 400 байт.

Civet - язык программирования, который компилируется в Typescript. Это типа coffeescript но для TS. Не то чтобы я советовал всем переходить на этот язык, но кому-то может показаться интересным. На лендинге есть примеры кода на Civet и на TS (хотя некоторые примеры конечно фееричные, например когда пишется `for` вместо `map`). Конкретно мне показался интересным моментами более лаконичный синтаксис, по сравнению с JS.

Доклад с TeamleadConf от Виктора Фабриченко про процессы разработки и основные концепции менеджмента в интеллектуальном труде. Конкретных ответов "как правильно" в этом докладе нет, т.к. это обзорный доклад со ссылками на всякое полезное, что полезно любому тимлиду.

В статье на примерах объясняется как работает сборщик мусора в JS. Без углубления в теорию, а просто на практике рассматриваются примеры вида "вот в глобальном скоупе есть функция, у которой есть замыкание на переменную, когда она будет почищена?". Все это делается с помощью `FinalizationRegistry` - это API в JS, которое позволяет отловить момент, когда сборщик мусора собирает переменную.

Список ресурсов для разработки local-first веб-приложений. Вы не знаете, с чего начать, что посмотреть, какие примеры и инструменты существуют для реализации local-first приложений? Эта ссылка для вас

Вышел публичный релиз WebContainer API. Если коротко - webcontainer позволяет запускать node.js приложения прямо в браузере. И все это сделано с помощью wasm. Там есть разные ограничения, но текущие примеры вызывают уважение - можно прямо в браузере собрать код, запустить expressjs сервер, сделать линтинг. Технология открывает новые возможности для веб-приложений. Но Stackblitz явно нацелены на запуск полноценного окружения или IDE прямо в браузере, чтобы пользователи могли собрать приложение, не требуя запуска кода в какой-нибудь железячной виртуалке.

HOTScript - библиотека с утилками типа `lodash`, но для системы типов TS. Уже где-то вроде говорили, что система типов в TS является тьюринг полной. А это значит, что в теории на ней можно построить любую программу. Вот HOTScript дает удобные утилки для подобного рода задач. Я плохо представляю кому это может понадобится, но just for fun выглядит интересно. Вот вам пример решения следующей задачи: - Есть массив чисел - Прибавь к каждому 3 - Соедини в строку через точку - Раздели строку по точке - Переведи строки в числа - Прибавь к каждому числу 10 - Выведи ответ В примере кода ниже это все расчитывается в системе типов и складываетя в тип res ``` import { Pipe, Tuples, Strings, Number } from "hotscript"; // prettier-ignore type res1 = Pipe // ^? 95 [1, 2, 3, 4, 3, 4], [ Tuples.MapNumbers.Add3, Tuples.Join".", Strings.Split".", Tuples.MapStrings.ToNumber, Tuples.MapNumbers.Add10, Tuples.Sum ] ; ``` Скоро первое апреля, можно подготовить МР своим коллегам, где вы реализуете фичу чисто на системе типов C:

Последнее время реактивность в разработке набирает популярность, а в частности сигналы в разных фреймворках. Статья объясняет, в чем же разница между сигналами и традиционными способами управления данными Статья поясняет, что традиционное API, например `useState` возвращает этот самый `state` и способ его изменять. Но если компонент объявляет у себя `useState`, то не факт, что конкретно он использует эти данные. Возможно, они используются в каком-то колбеке или в дочернем компоненте. Невозможность определить, использует ли компонент эти данные в своем рендере, является одним из основных минусов, по сравнению с сигналами. При использовании сигналов компоненту даются не данные, а способ их получить. Тем самым, если какой-то компонент хочет получить текущие данные - он вынужден явно указать это. Например, такое поведение достигается использованием геттера, вместо сырых данных. Т.е. вместо `state`, например, `useState` мог бы возвращать функцию `getState`, которая бы при вызове уже возвращала `state`. Это звучит как усложнение, но, по факту, если сразу проектировать API системы вокруг сигналов, то это не создает дополнительного оверхеда на вызов функции. А самое важное - это позволяет точно определить, какие данные компонент действительно использует в своем рендере, что позволяет оптимизировать рендер, не задумываясь о приседаниях мемоизацией и прочими хаками (типа использования рефов) В статье приведена более подробная аргументация и хорошие примеры того как это работает и как это может быть реализовано

Статья про эффективное использование HOC в React. Не смотря на то, что хуки сейчас - лучший выбор для переиспользования логики, HOC'и все еще могут быть полезны. Автор подробно разбирает хорошие и плохие паттерны организации HOC'ов

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

Часто менеджмент ставит цель "ускорить разработку". Ну т.е. ускорить либо velocity команды, либо скорость запуска фич. В данной статье рассматривается, почему это желание (ускорить разработку) - это вредно. Статья написана немного в стилей agile коучей (собственно автор и есть коуч) и поэтому в статье присутствуют манипулятивные приёмчики (в основном связанные со значениями цифр). Но в чем суть и что предлагает автор. Давайте представим, что у нас есть 2 команды: А и Б. В команду А мы нанимаем лучших аджайл коучей с рынка и начинаем коучить их, чтобы они учились делать как можно больше фич за то же время. Команду Б мы коучим, чтобы они проводили более качественное исследование того, что надо сделать. Теперь, нам нужно принять правду об IT-разработке: из всех фич, что мы делаем, большинство вообще не имеют влияния на бизнес, а меньшая часть делится на те, которые негативно влияют и те, которые позитивно влияют. В здоровом бизнесе фич с позитивным влиянием должно быть больше. Команда А действительно начнет делать больше фич, за тот же период времени и количество "хороших" фич в абсолютном значении будет больше. Условно, раньше за год делали 6 фич, которые приносили деньги, теперь 6 фич. Команда Б же будет тратить больше времени на исследования (а то ли мы делаем? а что хочет пользователь? и тд и тп), но зато теперь эта команда будет делать больше (пропорционально) полезных фичей. В итоге, хотя команда Б в целом делает фичей меньше, её влияния на бизнес будет более ценным. Автор подчеркивает 2 важных мысли: - "do the right things" - "our job is to minimize output, and maximize outcome and impact" В принципе, если вам надо убедить коллег, что надо не делать больше, а делать нужное, то статья очень хорошо показывает, как объяснять это графиками и цифрами обычным людям. Можно просто брать и повторять.

Хорошая статья про то, как создавать переиспользуемые компоненты. В статье рассматривается, как нарушение принципов хорошего дизайна делает компоненты менее удобными в разработке. Статья пошагово показывает, как появляются слишком сложные компоненты, на примере кнопки. Сначала нам нужна была просто кнопка, потом кнопки разных размеров, стилей, с разными иконками. В итоге компонент кнопки становится слишком сложным. Вместо этого следует четко выделить ответственность кнопки - уметь обрабатывать клики, уметь быть разных размеров. Но все что внутри кнопки - не ответственность самой кнопки. За пару безопасных рефакторингов кнопка становится по-настоящему гибкой. Далее показывается, как принцип "компонент ответственен только за свое поведение, а не за свой контент" вместе с принципом композиции помогает реализовать переиспользуемую модалку. Хорошая статья, очень просто и наглядно показывающая, почему полезен принцип "компонент ответственен только за себя, а не за свой контент"

3 пост в серии "ускорение JS экосистемы". Напомню, что автор доказывает, что не надо переписывать JS экосистему на go, rust, etc, вместо этого следует заняться оптимизацией текущей экосистемы на JS. В этот раз автор ускоряет eslint - инструмент, который есть, наверное, в каждом крупном проекте. Было найдено несколько проблем. 1. Поиск нужного токена комментария в правиле JSDoc Почему-то при парсинге комментариев для правила проверки JSDoc класс `BackwardTokenCommentCursor` аллоцируется более 20 миллионов раз. Переделка работы поиска нужного токена вынесена из текущего поста, но в целом, главная проблема - это лишние вызовы класса. Т.к. аллоцируется так много элементов то поиск по ним идет долго. В коде eslint используется метод `findIndex`, который линейно перебирает токены. Автор переписал поиск на бинарный поиск и ускорил работу этого участка кода в 2 раза. 2. Движок селекторов В eslint есть поддержка синтаксиса для матчинга AST-нод аля "css-селекторы". Это достаточно удобная фича, но движок селекторов также требует оптимизации. Медленный участок кода в селекторе - функция `getPath`. Это функция, которая достает свойство объекта по его строковому пути. Например `getPath({a: {b: true}}, 'a.b') === true`. В этой функции было 2 проблемы, которые влияли на перформанс: 1. Старый транспайленный код. Проект, видимо, давно не публиковался с новыми транспайлерами с таргетом под современные рантаймы, а цикл `for-of` при транспиляции заменяется на генераторы, что сильно медленнее нативного `for-of`. Это частая проблема в экосистеме. Замена на for-of значительно ускорила код. 2. `for-of` делается по `path.split('.')`, что вызывает алокации памяти. Вместо этого автор переписал код на ручной проход по строке с поиском точек и выделением части пути. Итог этой оптимизации: 2.7с = 486мс Также был сделан ранний выход из движка. Движок селекторов очень мощный, но часто при написании eslint правил разработчикам достаточно матчить только тип AST-ноды, а это можно делать вообще без запуска движка. Далее автор приходит к логичной мысли, что eslint когда-то решил что удобно писать точечные селекторы с css-семантикой. В целом это удобно, но eslint также мог бы дать простое API для JS-селекторов. Ну т.е. зачем нам придумывать какой-то движок, повторяющий семантику css селекторов, если можно просто писать нативный JS код, проверяющий что нам нужно. Автор проверил, будет ли это работать быстрее - и это действительно так. Простая JS функция в 30 раз быстрее, чем движок селекторов. 3. Конвертация AST в AST Eslint использует свой формат AST, в который другие парсеры вынуждены переводить свои AST. И если babel-parser имеет почти такой же AST, то вот typescript-parser имеет свой AST и при парсинге файлов переводит свой TS-AST в расширенный AST для eslint. Это влияет на перформанс дважды: нужно хранить 2 дерева AST и нужно делать дополнительную работу по переводу AST в AST. Автор сравнил скорость работы typescript eslint parser и babel eslint-parser и выяснил, что последний работает в три раза быстрее. Так что, если вам не нужны правила, которые имеют информацию о типах (киллер фича typescript parser, он, например, позволяет проверять, что никто не проходит for in по массиву), то можете заменить парсер на babel и ускорить свой линтинг. Рекомендую к прочтению в оригинале. Хорошая статья и хорошие примеры оптимизации перформанса.

Пост в блоге Deno про развитие веба от чисто серверного рендеринга к чисто клиентскому рендерингу, затем обратно к серверному, затем к гибридному способу, где взято лучшее из обоих миров. Также показывается на примерах кода, как правильно достичь этого в Deno Краткая история веба: Сначала сервера рендерили достаточно легкий HTML (часто даже без картинок), потому что клиентские устройства были слабые, сеть была медленная, да и были технологические ограничения (были времена когда не было JS, затем JS появился, но не было возможности делать запросы из JS кода в браузере). Затем, когда сеть стала лучше, а клиентские устройства стали мощнее, многие компании перешли на браузерный рендеринг. Можно было вообще не содержать никакие серверы, а раздавать чисто статику с CDN, а там JS в браузере уже делал все грязные дела - грузил данные, рендерил страничку. Это позволило начать делать сайты с очень хорошим user experience (отображение контента без перезагрузки страниц, богатые возможности в интерактивности). Однако, очень скоро появились и проблемы: - как обеспечить равные возможности для пользователей мобильного и быстрого интернета? - JS-статика стала такой тяжелой, что пользователь мог долгое время наблюдать просто белый экран Поэтому произошел обратный виток в Server Side Rendering. Это когда те же самые фреймворки загружали все данные и рендерили приложение сначала на сервере, отдавали пользователю готовый HTML, на который уже можно было смотреть, а затем пользователь скачивает весь JS и происходит "оживление" приложения в браузере. Однако, у нас остается проблема, что может быть необходимо загрузить слишком много JS. Поэтому следующий виток развития - научить фреймворки "оживляться" только теми частями, которые сейчас необходимы пользователю. Это называется islands architecture. Deno нацелен на имплементацию именно этой архитектуры и в статье показывается, как ее реализовать в этом рантайме.

BlockNote - текстовый редактор на react, который повторяет UX notion'а. Если вы хотите вдруг сделать свой notion или что-то подобное - то вам понравится. Выглядит действительно приятно.

Короткая, но очень ёмкая и крутая книга про рефакторинг. Примеры кода написаны на JS, но в целом практики применимы для любых языков Я сам не читал, но несколько глав полистал. Очень качественное чтиво: хорошо и доходчиво объясняется как плохо, как хорошо, как можно это отрефакторить. Отдельно мне нравится, что, хотя книга и называется "рефакторинг", но на самом деле она сожержит много полезного, не привязанного к рефакторингу. Объяснение разных полезных принципов и паттернов. Например, обработка ошибок - с рефакторингом особо не связано, но глава очень хорошо объясняет разные паттерны работы с ошибками

Большая статья про проблемы проведения перформанс ревью разработчиков. Перформанс ревью разработчиков стало стандартом индустрии. Практически все большие технологические компании измеряют работу разработчиков и на основе оценок определяют, кто молодец, а кто - нет. По идее, разработчик проявляет хороший перформанс, что выгодно в целом компании или заказчику, и компания награждает за это разработчика чем-нибудь (напримре, бонусы). Звучит хорошо. Однако, на практике, все может быть с точностью до наоборот: разработчик получает хорошую оценку по перформанс ревью, а заказчик недоволен. Проведение перформанс ревью в компании может вредить итоговой цели и сделать хуже. Почему так? Потому что проведение перформанс ревью может вызвать разные дисфункции: - Оценивается индивидуальный вклад. Это снижает ценность командной работы. А командная работа лежит в основе современной разработки - Оценивается результат работы человека, а не то, как работает система в целом. - Фокус на количестве, а не на качестве. Это связано с тем, что качество сложно померить. А вот померить количество - легко! Как следствие, качество начнет деградировать в угоду количеству. - Стандарты, по которым идет оценка, всегда отстают от текущего положения дел. Для оценки мы всегда вынуждены сравнивать текущие показатели с какими-то прошлыми. - Невозможность точных измерений в разработке - Безрисковые ставки. При постановке целей, тот, кого будут измерять, будет стремиться ставить такие цели, которые можно легко достигнуть. Есть теории о достижении целей. Они предоставляют способ смоделировать, как измерение разных активностей влияет на достижение целей. Если мы можем измерить все - то, вероятно, мы пойдем оптимальным путем и принесем счастье пользователю. Если мы все измеряем так себе, то разработчик будет идти тем путем, который будет эффективен для него, но не для системы в целом. Если мы не измеряем ничего, то, вероятно, мы пойдем тем путем, который принесет счастье пользователю. Я немного утрировал, но суть такова: не измеряя ничего мы будем сфокусированы на счастье пользователя, а не на достижении измеримых целей. Какая альтернатива у перформанс ревью? Learning and development review! В чем отличие? Вместо того, чтобы оценивать персональный вклад, следует сфокусироваться на развитии мастерства разработчика (и хард и софт скилы). Это убирает конфликт "мои целевые показатели vs потребности бизнеса". Я сильно сжал статью, потому что она реально гигантская. Но мне понравились следующие мысли, которые коррелируют с моей практикой: - Постановка индивидуальных целей ведет к тому, что человек сфокусирован на выполнении целей, а не на доставлении счастья пользователю - Современная разработка - это всегда командная работа. Здесь нет места индивидуалистам - Постановка целей должна быть связана с обучением и развитием - Процесс разработки нельзя измерить, не навредив Рекомендую к прочтению тимлидам и менеджерам

Статья в блоге Мартина Фаулера про проектирование реакт приложений с применением бест практисов индустрии в рамках архитектуры UI приложений. В статье подроно объясняется, зачем нужно разделять UI-приложение на разные слои, как декомпозировать логику, а также есть пример рефакторинга небольшой фичи. Как всегда в блоге Мартина Фаулера - показывается и рассказывается все очень круто и наглядно. Статья по-немногу дописывается и могут появляться новые разделы. Рекомендую к прочтению.

Текстовая версия доклада от Авто.ру про реальный кейс улучшения перформанса веб-приложения. Автор последовательно показывает методику ускорения Авто.ру. Сначала флоу приложения декомпозировали на этапы (серверный код, рендер, css, js) и в каждом отдельном этапе уже искали возможно для улучшения перформанса. Кроме приёмов для ускорения, также показаны и рассказаны инструменты, с помощью которых можно профилировать перформанс приложения. Рекомендую к прочтению т.к. это реальный кейс улучшения перформанса реального сайта, а не теоретические выкладки.

Библиотека для обработки ошибок простым, консистентным и удобным способом. Основные фичи: - Поддержка TS - Составление иерархии ошибок (классы, наследование) - Возможность указать причину ошибку (типа связать две ошибки, пример будет ниже) - Возможность добавлять свои свойства ошибкам - API для сериализации и восстановления ошибок, что позволяет безопасно работать с ошибками и неошибками - Логику можно расширить плагинами (в том числе самописными) Немного примеров, показывающих возможности библиотеки Иерархия ошибок ``` import ModernError from 'modern-errors' const BaseError = ModernError.subclass('BaseError') const UnknownError = BaseError.subclass('UnknownError') const error = new UnknownError('Unknown error'); console.log(error instanceof UnknownError) // true ``` Указание причины ошибки ``` try { throw new BaseError('Какая-то ошибка') } catch (cause) { // прокидывание оригинальной ошибки в cause // объединяет текста ошибок и стактрейсы throw new InputError('Не смогли сделать что-то.', { cause } } ``` Если у вас есть потребность в структурировании работы с ошибками в приложении, рекомендую посмотреть эту либу

Хорошая статья, объясняющая, почему не так просто работать в `useEffect` с асинхронными функциями (тлдр: хук ожидает `cleanUp` колбек, а не промис, в strict mode хук исполняется дважды, да и вообще надо учитывать что хук может исполнится второй раз, пока первый асинхронный вызов еще не завершился) Автор подробно с примерами кода описывает, как обойти все эти проблемы и указывает на то, что код получается слишком сложным, если учитывать все нюансы. Поэтому он предлагает создать хук `useAsyncEffect` (описан в статье), скрывающий всю эту сложность. Хотя, как по мне, вся эта сложность - это в первую очередь показатель проблемы в дизайне React. Вместо того, чтобы сделать удобное решение, разработчики вынуждены либо плодить баги либо писать велосипеды.

Статья от Microsoft про влияние css-селекторов на производительность страницы и про оптимизацию перформанса стилей. Статья объясняет: - Как браузер обрабатывает селекторы и как они влияют на производительность - Какие инструменты есть в браузере для профилирования проблем с производительностью - На специальной демке наглядно, с цифрами, показывается, как "медленные" css-стили могут повлиять на перформанс и как это исправить Рекомендую к прочтению - очень хороший гайд по достаточно редкой теме.

Статья про продуктивность при проведении исследовательской работы. Автор занимается работой, часть которой состоит из глубоких исследований. У долгой исследовательской работы есть важная особенность: долгое время нет явных результатов работы, что приводит к следующим эффектам: - Кажется, что прогресса нет. Из-за этого может наступить демотивация т.к. у коллег, друзей, знакомых, за это время в рамках обычной работы может быть уже множество результатов - Сложно фокусироваться на такой работе. В худшем случае - хочется отвлечься на что-нибудь типа твиттера. В лучшем - заняться работой, которая не так важна, но понятна! Например, у вас может быть сложная исследовательская задача, она идет тяжело и медленно. Но есть же другие простые задачи, на которые хочется переключится - ответить на email, написать какой-то конкретный код (пофиксить баг), заняться административной работой. Автор ответственно подошел к решению своей проблемы с фокусировкой. Автор измерил: - В какие периоды времени работается лучше (утро, день, вечер, выходные) - Какими интервалами фокусировки лучше работать - Какие перерывы стоит делать - Когда и как отключать нежелательные штуки, на которые можно отвлечься. Сначала автор ставил блокировку для захода на определенные сайты, но потом понял, что даже если заблочить твиттер, то будет желание отвлекаться через что-то рабочее, но неважное. Поэтому автор начал периодически не только блокировать "вредные" сайты, но отключать wi-fi, убирать телефон и уведомления. - Какие варианты медитации могут помочь со сменой контекста Статья достаточно большая и сложно читается, но подход автора к повышению персональной продуктивности очень крут и он очень хорошо описывает проблемы больших задач с большой неопределенностью.

По ссылке можно получить книжку "от 0 до сотни деплоев в день". Книга достаточно короткая (60 страниц), но в ней рассказывается, как по шагам можно пройти путь от очень медленной разработки с деплоями раз в полгода к разработке с сотнями деплоями в день. Рассматриваются как технические аспекты (какой процесс Code Review должен быть на каждой фазе), так и культурные (как взращивать нужную культуру (например открытости) команды разработки)

Статья про то, как отделить реализацию тестов на компонент от реализации самих компонентов. Автор предлагает делать отдельный API для тестов, который инкапсулирует в себе взаимодействие с компонентом. Вообще такой паттерн уже есть и называется Page Object (название, победившее все другие варианты в далеких 200х годах), но автор зачем-то вводит новое понятие Component Object Model (далее COM), который полностью повторяет смысл. На примере простого компонента, который нужно протестировать, автор вводит для него COM описывающий, как взаимодействовать с компонентом (заполнять форму) и как получать его текущее состояние (например, текст с верстки) Это удобно по нескольким причинам: - Изменения в коде приложения не влияют на код тестов. Максимум, что потребуется поменять - код COM. Это достигается тем, что COM инкапсулирует в себе знания о реализации компонента - Код тестов читается легче. Вместо "кликни на кнопку с селектором таким-то" в коде теста видно "отправь форму" - COM может быть переиспользован между разными тестами У меня про это даже доклад был на одной из конференций, но я это называл просто Page Object. Мы в проекте активно использовали эти абстракции. В идеале, один интерфейс Page Object может быть использован и для браузерных тестов и для тестов на jsdom. В более идеальном случае Page Object можно написать единый для двух видов тестов (однако тут есть свои требования к стеку и, возможно, есть ограничения, которых я не вижу). В целом идея делать удобное API для тестирования функционала - это правильно. Даже в обычных юнит-тестах разработчики, когда им надоедает писать один и тот же бойлерплейт, выносят внутренние тестовые утилки. Иногда даже идут дальше - готовят кастомные асерты. Но обычно всем лень сделать шаг дальше - выделять API для тестирования субъекта, которое сделает тесты читаемыми, защитит тесты от рефакторинга и сделает создание тестов более легким. Статью рекомендую к прочтению т.к. она очень коротко и ясно показывает плюсы создания Page Object.

Еще одна статья про синдром бесконечных встреч и иллюзию продуктивности при проведении встреч. Есть несколько простых фактов: - Люди все больше и больше времени проводят на встречах. В статье есть исследования 2007 и 2020го года. ИМХО, после повсеместной удаленки из-за ковида ситуация стала еще хуже. - В целом людям не нравятся встречи. Кто-то хочет меньше встреч, кто-то присутствует на встречах, в которых они по факту не участвовали, кто-то теряет фокус при видео-созвонах. - Многие люди воспринимают встречи как работу. Ну т.е. как будто бы задачи не были бы сделаны, если бы мы о них не поговорили - При этом, согласно исследованиям, большое количество встреч ведет к снижению продуктивности В итоге, создается иллюзия, что если человек участвует в большом количестве встреч, то он много работает. Но, таким образом, у человека не остается времени на просто подумать, хотя бы в пассивном режиме, о чем нибудь важном и развивающем. Вместо того, чтобы учавствовать в очередной встрече, было бы полезнее просто поработать. Автор статьи дает 5 простых советов по улучшению персональной продуктивности: - Установить для себя соотношение времени встреч к рабочему времени. Например, убеждаться что не более половины рабочего дня уходит на встречи и созвоны - Планировать следующий день. - Делать самые важные задачи первыми. - Делегируйте - Хакните встречи. Если встреча запланирована на 30 минут, попробуйте уложится в 20. Также старайтесь делать так, чтобы все встречи проходили друг за другом и таким образом у вас был большой период времени для самостоятельной работы

Статья рассказывает, как `useReducer` исправляет "тяжелые" случаи использования `useState`. Иногда, когда в компоненте становится много состояний, объявленных через `useState`, становится сложно с ними работать. Код плохо читается, требуется ручная синхронизация состояния. Автор предлагает в таких случаях использовать `useReducer`. Конечно, можно закинуть большое состояние в 1 `useState`, но `useReducer` имеет несколько преимуществ: - т.к. reducer - это функция, то можно легко туда добавлять разную кастомную логику (условия, циклы, сравнения дат при обработке события) - редусер можно переиспользовать в разных компонентах, прокидывая его в `useReducer` - можно заиспользовать immer и получить удобный мутирующий синтаксис для установки нового значения Я не фанат `useReducer`, но статья неплохо рассказывает о том, почему стоит использовать его, а не `useState`, в случаях, когда в компоненте логики больше, чем просто установка 1,2 флагов.

Разбор того, как работает система типов с точки зрения теории множеств. Очень доступно объясняется, почему `1 | 0 extends 0 ? true : false` - это `false`, что такое расширение и уточнение типа, что такое `never` и `any` и прочие концепции TS. Рекомендую к прочтениб

Команда TypeScript анонсировала TypeScript 5.0. Бетка уже доступна к использованию. Из больших изменений: декораторы, const в параметрах функции, каждый элемент енама теперь является отдельным типом, улучшение проверок JS через JSDoc, оптимизация перформанса, удобное расширение конфига и другое. Погрузимся в некоторые пункты. *Переработка декораторов* Самое ожидаемое изменение - это переработка декораторов. У декораторов была нелегкая судьба - сначала их довели почти до релиза в TC39, а затем откатили и переработали. Вот в Typescript 5 будут новые декораторы. В статье достаточно много места уделяется различным примерам работы новых декораторов. Что же со старыми декораторами? Команда TypeScript оставит флаг для работы старых декораторов. По идее, маленькие кодовые базы могут переехать на новые декораторы единомоментно. А в больших проектах придется делать отдельный под-конфиг, включающий опцию с легаси декораторами там, где они используются, и итеративно переписывать одни декораторы на другие. *const параметры функций* Часто в коде на TS требуется писать `as const` чтобы TS не приводил тип к более широкому при прокидывании аргументов в функции. Теперь же можно при указании параметра дженерика в функции указывать const, что сохранит это поведение, если это возможно Пример из статьи ``` declare function fnGoodconst T extends readonly string[](args: T): void; // T is readonly ["a", "b", "c"]. Без const T будет преобразован в string[] fnGood(["a", "b" ,"c"]); ``` *Все енамы теперь union* Про Enum'ы. Теперь каждое значение в Enum имеет свой уникальный тип. А сам enum - это union от всех значений в Enum. ``` enum Color { Red, Orange, Yellow, Green, Blue, Violet } type PrimaryColor = Color.Red | Color.Green | Color.Blue; function isPrimaryColor(c: Color): C is PrimaryColor { /* code */ } ``` Глядишь, когда-нибудь позволят использовать инлайн значения, вместо енамов *Удобное API для композиции конфигов* Наконец-то сделали удобное API для композиции конфига проекта из нескольких частей ``` { "compilerOptions": { "extends": ["a", "b", "c"] } } ``` *Улучшение JSDoc* В TS есть возможность проверять типы в JS файлах. В этом случае JSDoc можно использовать для объявления типов. Теперь в JSDoc добавили поддержку пары новых фич - satisfies и overload *Улучшение перформанса* Команда TS давно делала разные подходы к оптимизации своей кодовой базы. Иногда удачные, иногда нет. Но в текущем релизе итоговый размер пакета TS уменьшился почти в 2 раза - на 25МБ!! Это ускоряет сборку всех проектов, которые используют TS. Например, VS Code собирается теперь на 19% быстрее. В статье есть ссылки на подробное описание оптимизаций, но основной вклад, как я понял, дали переезд с неймспейсов на модули, использование нового сборки тулинга, который хорошо оптимизирует модули, а также изменение стратегии пакетирования кода и удаление легаси кода. Также вчера в канале был репост от Никиты Дубко, где он также рассказывал про изменения в новом TS.

Вышел Astro 2.0! Улучшение работы с markdow, гибридный рендер, ускорение работы и новый родмап. Давайте разберемся по-подробнее. Проверки типов при работе с markdown и MDX. При генерации сайта или блога из markdown контента часто случаются проблемы компиляции или рантайм (cannot read something of undefined). Astro 2 внедряет Content Collections API. Это типизированное API к локальным markdown файлам. В ссылке про Content Collection API достаточно красочные гифки, подробно показывающие крутые возможности нового API Гибрый рендер. Раньше Astro давал выбор: SSR или SSG. Т.е. рендерить на сервере (SSR) каждый запрос, что позволяет делать динамический контент для пользователя, или пререндерить все в статику, получая меньше головой боли с деплоем и поддержкой, но никакой динамики. Теперь же Astro 2 позволяет вручную разметить, где использовать SSR, а где SSG Улучшение Developer Experience: еще быстрее, чем раньше Новый публичный родмап прямо в Github. Вот благодаря этому посту узнал, что на github тоже можно делать родмап с колонками.