ИИ я использую. Но в этом проекте он был исключительно быстрой документацией — особенно когда добрался до selection/range API, про которые до этого знал чуть меньше чем ничего. Реализация все равно была за мной.

Так вот — ReadGen. Блочный конструктор README-файлов. Месяц, 2-3 часа в день, React и TypeScript и небольшая пачка дополнительных библиотек для разумного облегчения жизни. Важно понимать что это не коммерческий продукт и не претендует на решение чьей-то боли. Просто техническая задача которую я давно хотел разобрать.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Почему

contenteditable — старый добрый дед среди браузерных API. То что он старый - это да, а вот доброта - под вопросом.

Он искренне хочет помочь, сам расставляет <div> и <br>, сам решает что делать с Enter, сам форматирует как считает нужным. Проблема в том что его никто не спрашивал. Когда тебе нужен предсказуемый блочный редактор с контролируемой структурой данных — такая самодеятельность становится основным источником боли.

Готовые текстовые движки эту боль скрывают. Я хотел её почувствовать лично. Понять где именно браузер начинает делать по-своему и что с этим делать. Это и был настоящий вопрос проекта.

Поначалу казалось что задача не супер сложная, но довольно быстро понял что полноценный текстовый редактор это бесконечные edge cases которые не влезут ни в какой месяц. Граница была проведена жёстко: плоская структура блоков, никакой иерархии. Всё остальное — потом, в другой жизни.

Так задача сузилась до честного и реалистичного объёма, блочный конструктор README без вложенности, с предсказуемым ядром и нормальным экспортом.

Три OM

Между реальным DOM и виртуальным DOM React затесался ещё один — MOM, Markdown Object Model. Пафосное название для того что по сути является flat map структурой документа. Но только по сути — на деле это целое ядро, состоящее из парсера, валидатора, гардов, движка, сериализатора. Это по сути модули без внешних зависимостей (кроме dexie.js в подмодуле storage) которые принимают данные, делают свое дело и отдают, впрочем как и принято в среде порядочных разработчиков.

Архитектурно MOM живёт как отдельный изолированный модуль — ведёт себя как shared слой в FSD, но это не набор утилит а самостоятельное ядро. Всё остальное приложение построено на гибриде FSD и layered подхода, но MOM существует по своим правилам.

Один DOM, два хозяина

Вот где настоящий конфликт. Структурой документа, порядком блоков, состоянием UI управляет React. Но внутри редактируемых блоков он полностью отступает. Там нет react рендеринга, только innerHTML и чистый DOM. Синхронизация происходит в эффекте, источник истины — содержимое contenteditable, и именно оттуда формируется MOM.

Два хозяина поделили территорию. React взял всё снаружи, DOM взял всё внутри. С одной стороны казалось бы все круто, так и должно быть, но на самом деле это порождает новый пласт проблем.

Отдельная история внутри этой истории — курсор. Позицию нужно постоянно сохранять и восстанавливать через selection/range API, и синхронизировать это с React. Это отдельная боль внутри общей боли.

Деструктивная синхронизация DOM — innerHTML = '' перед каждой манипуляцией выглядит грубо, зато работает. Можно было конечно написать свой reconciliation но учитывая исходные рамки по времени я решил отказаться.

Генераторы в сериализаторе

Экспорт документа в .md — финальная точка всей архитектуры. MOM → Serializer → файл. Впервые за все время своего осознанного программирования я решил тут применить генераторы в деле.

Каждый тип узла имеет свою функцию-генератор. Первый yield — контент блока, второй yield "" — пустая строка-разделитель. Тут мы избавляемся от аккумулятора который нужно тащить в глубь и код делаем более плоским и понятным. Array.from(gen).join("\n") в конце собирает всё в строку.

Drag and drop на Pointer Events

Кастомный drag and drop с анимацией как отдельный хук. И тут я познакомился с довольно таки мощными событиями класса pointer

о существовании которого я знал но почему то всегда обходился с touch

и mouse ивентами.

Pointer Events унифицируют всё что раньше требовало отдельных mouse и touch обработчиков. Без pointercancel drag зависает если браузер решает прервать жест сам. setPointerCapture — чтобы события не терялись когда курсор уходит за пределы контейнера.

Компромиссы

MOMRaw — честное признание границы. Все что не попало в текущую версию движка (таблицы, инлайн-картинки, инлайн-код и т.д.) живёт в одном компромиссном блоке. Вставляй сырой Markdown или HTML, смотри превью через внешнюю библиотеку в изолированном Shadow DOM.

То же самое с блоком кода - MOMCode. Для этого я подключил библиотеку uiw, думаю в будущем заменю его на более современное и понятное решение.

Виртуализации нет, README на 10 000 блоков не существует в природе, проблема надуманная ну или просто не успел (выбирайте сами).

Мелочи которые просто есть и работают: менеджер глобальных шорткатов, тултипы для вставки блоков, эмодзи и форматирования текста, миниатюры документов через modern-screenshot, хранение в IndexedDB без бэкенда.

Заключение

Месяц закончился. contenteditable я теперь знаю лично — и он знает меня. Selection/Range из страшного незнакомца превратился в рабочий инструмент. Понял где React уместен, а где лучше отойти и дать DOM делать своё дело. Нашёл наконец задачу где генераторы оказались не паттерном ради паттерна а реально лучшим решением.

Демо: readgen-eight.vercel.app

Репозиторий: github.com/islamxm/readgen

Представьте: пятница, 18:30. Релиз через час. Вы меняете один роут в конфиге — и внезапно половина приложения отлетает. Поздравляем, вы только что познакомились с классической болью фронтендеров.

Проблема кроется в самой природе JavaScript. Строковые пути вроде /users/profile/${id} существуют в коде как обычные строки — без проверок, автокомплита и гарантий корректности. Опечатался в /usres вместо /users — и твоя навигация сломалась, а TypeScript молчит как рыба.

Двадцать лет назад мы кликали по window.location.href, десять лет назад — радовались React Router, а сегодня пора переходить на типизированные решения.

Когда прочитаете эту статью, сможете настроить типобезопасную навигацию в своем проекте, забудете про сломанные ссылки после рефакторинга и перестанете нервничать на релизах.

Суть проблемы

Проблема очевидна: путь /admin/products размазан по всему коду. TypeScript не знает, что эти строки связаны с определенной директорией, поэтому не проверяет их корректность. Опечатка в product вместо products — и вылетает ошибка 404.

В больших проектах эта проблема критична. Приложение с 200+ путями, где навигация разбросана по сотне компонентов, превращается в минное поле. Один программист меняет структуру URL, а остальные даже не подозревают об этом. Команды используют TypeScript для типобезопасности, но навигация остается уязвимой.

Что такое типизированная навигация?

Типизированная навигация превращает строковые пути в типизированные объекты. Вместо /admin/products/123/edit программист работает с функциями, которые знают структуру приложения и проверяют корректность написания путей на этапе компиляции.

Представьте GPS-навигатор, который знает все адреса в городе. Вы не можете ввести несуществующую улицу — система сразу выдаст ошибку. Так работает типизированная навигация: TypeScript проверяет, что путь существует, параметры переданы правильно, а структура URL соответствует пути.

Три ключевых преимущества: автокомплит в IDE, проверка на этапе компиляции и безопасный рефакторинг. Поменяете пути в коде — TypeScript сразу покажет все места, которые нужно обновить.

Польза зависит от уровня разработчика:

• Джуны получают защиту от опечаток и автокомплит — меньше глупых ошибок и быструю разработку.
• Миддлы ускоряют разработку благодаря надежному рефакторингу — можно смело менять структуру URL без страха что-то сломать.
• Сеньоры используют типизацию для построения архитектуры приложения — создают переиспользуемые компоненты навигации, проверяют параметры и строят масштабируемые системы путей и директорий.

Типизированная навигация превращает хрупкий код в надежную систему, где ошибки находятся до деплоя.

Как использовать React Router вместе с TypeScript

Для базовой типизации в React Router v6 сначала определите структуру путей. Создайте интерфейс, который описывает все пути в приложении:

Типизация параметров URL решает проблему с useParams. Вместо any получаете конкретные типы:

Query-параметры типизируются аналогично через useSearchParams. Создайте интерфейс для каждой страницы с query-параметрами и оберните хук.

Так система будет дополнять код в IDE, проверять все пути на этапе компиляции и защитит от опечаток. Полчаса настройки сэкономят вам часы отладки и целый вагон нервов.

Как внедрить типизированную навигацию в проекты

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

Конфигурация избавит от нужды дублировать код при генерации типов. TypeScript автоматически выведет все возможные пути и их параметры из одного объекта.

Современные библиотеки решают проблему из коробки. Например, Tanstack Router предоставляет полностью типизированную систему путей с автогенерацией типов, а Type-route создает типобезопасные пути через API.

Библиотека typesafe-routes внедряется даже в крупные проекты без необходимости менять сотни строк кода.

Выбор инструмента зависит от размера программы. Если у вас небольшое приложение — быстрее написать хук в пару строк. Но если разрабатываете сложный сервис — используйте библиотеки.

Как не сломать код при использовании типизированной навигации

Не пытайтесь переписать весь проект за раз — создайте типизированные хуки для новых фич, а старый код обновляйте по мере рефакторинга.

Чеклист для код-ревью поможет не уронить прод:

• Все новые navigate() и используют типизированные версии;
• Параметры путей явно типизированы;
• Нет магических строк в навигации;
• Query-параметры описаны интерфейсами.

Важно: не используйте одновременно строки и типизированные пути — выберите один подход для проекта и не допускайте высокого уровня вложенности в объектах.

Автоматизация упрощает процесс. ESLint правило no-hardcoded-routes запретит использование строк в навигации. Код-генераторы создают типы из OpenAPI схем или конфигурации роутера.

Производительность не страдает — типы исчезают после компиляции. Теряется немного времени на компиляцию TypeScript, но экономия на отладке перекрывает затраты.

Где применять типизированную навигацию

SPA-приложения получают максимальную пользу от типизированных путей. В дашбордах с десятками страниц навигация становится еще важнее — один сломанный путь может уронить проект.

E-commerce проекты выигрывают от типизации каталогов и фильтров. Пути вроде /catalog/:category/:subcategory?filters=price,brand содержат много параметров, которые легко сломать при рефакторинге.

Интеграция с Redux и Zustand упрощает синхронизацию состояния с URL. Типизированные селекторы автоматически обновляются при изменении роутов:

Вложенные директории требуют особого внимания. Каждый уровень вложенности усложняет типизацию — планируйте структуру заранее, а не рефакторьте задним числом.

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

Так случалось, пока не появились инструменты вроде TanStack Query и не родились «обертки», которые уменьшают объемы рутины. Как перестать тонуть в запросах на разработку API и начать дышать свободно, рассказывает Дмитрий Скляр, старший разработчик компании Axenix.

API: нервная система цифрового мира

В современном ИТ-ландшафте API давно перестал быть просто техническим термином. Теперь он — один из столпов, на котором держится цифровая цивилизация.

Философия современной разработки давно сместилась от принципа «сделай все сам» к парадигме «собери из лучших компонентов». API стал языком, на котором взаимодействуют цифровые сервисы. Он превратил ИТ-ландшафты и интернет из собрания разрозненных приложений и сайтов в единую живую экосистему, где каждый элемент может взаимодействовать с другим.

Когда разработчик использует API картографического сервиса, ему не нужно разбираться в геоданных или алгоритмах прокладки маршрутов — он просто отправляет запрос и получает готовое решение. Это похоже на то, как мы пользуемся электричеством: не нужно понимать, как работает электростанция, чтобы включить свет в комнате.

Но настоящую революцию API совершил в бизнесе, создав целые экосистемы цифровых услуг. Такие компании, как Stripe, Twilio или Plaid построили свои империи именно на API, предоставляя другим разработчикам готовые «кирпичики» для создания финансовых, коммуникационных или аналитических сервисов.

Внутри крупных компаний API выступают в роли «дипломатов» между микросервисами и ИТ-системами, позволяя разным командам работать независимо, но при этом сохранять общую согласованность. Когда маркетинговая система запрашивает данные о продажах, а сервис логистики получает информацию о новых заказах — все это происходит через четко определенные API-контракты, которые делают сложные системы управляемыми и гибкими.

Боль, которую никто не замечает

Но не все так просто и далеко не так радужно.

Да, формально API — это универсальный мост, например, между фронтендом и бэкендом. На практике же он часто напоминает шаткую подвесную конструкцию: данные приходят в разном формате, документация устаревает еще до релиза, а поля user_name и username существуют одновременно просто потому, что «исторически сложилось».

Типичный сценарий: вы пишете код для запроса списка товаров, все типизируя и описывая модели — 50 строк. Добавляете фильтрацию — еще 30 строк. А через месяц бэкенд меняет структуру ответа, забывает предупредить — и вы тратите день на поиск багов в трех разных местах. И самое обидное: 80% этого кода — копипаст. Проверка ошибок, трансформация данных, инвалидация кэша — все одно и то же, но плодится как вирусы.

Сюда можно добавить также сложность поддержки — API меняется, код устаревает.

Другой момент: код для каждого API-метода имеет схожую структуру. Повторяются основные шаблоны, а различия лишь в типах данных и отдельных деталях. Чем больше API-методов, тем сложнее отслеживать изменения в коде и поддерживать его в актуальном состоянии.

В итоге — дублирование кода, которое усложняет приложение, снижает его читаемость и замедляет разработку новых функций. Документация? Либо устарела, либо ее вообще не писали.

Спасение — в системе

Однажды наши разработчики устали писать однотипные хуки, чинить сломанные запросы и объяснять новичкам, что где находится, почему именно так это работает и почему нельзя просто взять и использовать что-то другое. Устали писать однотипный код для каждого запроса, захотели минимизировать ошибки и ускорить разработку, а также сделать работу с API более структурированной и понятной. Также у команд назрела потребность в скорейшем включении в проект новых разработчиков. Для всех этих задач подходит одно решение: унифицированный подход к API, который также наводит порядок в данных и отчетах, упрощая аналитику и логику приложения.

Тогда и родилась идея фабрики API — слоя абстракции, который скрывает рутину. Для этого мы привлекли возможности TanStack Query, семейство библиотек для управления состоянием данных (data fetching) в клиентских приложениях. Помимо TanStack Query (ранее React Query), к этому классу инструментов также относятся: RTK Query (из Redux Toolkit), Apollo Client (для GraphQL) и SWR.

Их общая философия: «делать рутину невидимой для разработчика». Рассмотрим Конкретные проблемы и их решения.

Однотипные хуки для каждого запроса

В большинстве проектов без дополнительной абстракции каждый хук под API-запрос пишется вручную. Меняется только URL и параметры, а структура остаётся одинаковой: queryKey, queryFn, опции запроса. Это быстро приводит к копипасту, дублированию логики и усложнению поддержки.

Например, для каждого ресурса вроде пользователей, продуктов, заказов и т.д. приходится повторять одну и ту же конструкцию. Если нужно изменить поведение запроса (например, добавить retry или staleTime), правки необходимо делать в десятках мест.

Решение: Универсальная обёртка над хуками TanStack Query

Создание единой функции-генератора для хуков позволяет избавиться от повторяющегося кода. Она принимает ключ, функцию запроса и опциональные параметры — и возвращает сразу «пачку» готовых хуков.

Такой подход:

• снижает количество шаблонного кода;
• упрощает масштабирование;
• централизует поведение всех запросов;
• позволяет быстро адаптироваться к изменениям (например, добавить логирование, типизацию, трансформации и т.п.).

Хрупкость при изменении API

В типичном приложении без централизованной трансформации мы напрямую используем ответ от бэкенда. Любое изменение формата требует правок в типах, в местах использования данных, и часто приводит к багам.

Решение: Централизованная трансформация данных + class-transformer.

С помощью class-transformer можно объявить классы сущностей и задать правила преобразования один раз.

Плюсы:

• Все данные автоматически приходят в нужном виде;
• Компоненты работают с гарантированно типизированными данными;
• Один источник правды: при изменении API – правим только Entity-класс;
• Удобно масштабируется, особенно если API большое и сложное.

«Мусор» в данных и отчётах

Решение: Валидация данных при трансформации (например, через class-validator); автоматическая синхронизация кеша (актуальные данные во всём приложении).

Почему это лучше ручного подхода? Смотрите: строк кода на 1 endpoint при ручном управлении потребуется 30+, а с фабрикой — 5-10. Времени для добавления нового поля — 1 час вручную, с фабрикой — 5 минут. Количество мест для правки при изменении API — вручную их много, с фабрикой — лишь одно.

Реальный кейс: в проекте с 50+ endpoint’ами переход на фабрику сократил код на 70%. Разработчики перестают быть «переводчиками» между API и интерфейсами сервисов и приложений, а сосредотачиваются на бизнес-логике. Как сказал один тимлид: «Теперь мы не фиксим баги данных, а делаем фичи, которые нравятся пользователям».

Еще пример: вместо пяти отдельных хуков для CRUD-операций фабрика дает одну функцию createApi(). Вместо ручного парсинга — автоматическую трансформацию данных через class-transformer. А главное — единые правила игры для всего проекта.

Как это работает? Представьте, что вы говорите системе: «Вот endpoint для товаров, вот их модель данных, вот правила валидации» — а все остальное она делает за вас. Хотите получить товар по ID? Пишете useGetByIDQuery. Нужно обновить? — useUpdatetMutation. И никакого шаманства с ручным описанием каждого хука.

Но главное — когда бэкенд меняет API, правки нужны только в одном месте. А новые разработчики перестают спрашивать: «Почему у нас три разных способа загрузить список пользователей?».

Как договориться и не сойти с ума

Проблема в том, что без четкого контракта, набора правил и подходов фронтенд- и бэкенд-разработчики живут в параллельных реальностях. Один думает, что данные придут в camelCase, другой шлет их в snake_case. Один ожидает массив, другой неожиданно подсовывает null. Итог — бесконечные баги, исправления «на живую» и испорченные нервы.

Решение? Четкий контракт. Простой, прозрачный, однозначный. В нем должны быть:

1. Единые правила именования — если бэкенд отдает snake_case, фронтенд не должен гадать, будут ли остальные поля в camelCase, или, например, если в одной модели данных full_name , в другой не будет fullname и так далее.
2. Единый формат запросов и ответов.
3. Договоренности о структуре URL, формате данных и кодах ошибок.
4. Строгая типизация — TypeScript-интерфейсы, которые знают, какие поля обязательны, а какие могут отсутствовать.
5. Документация, которая не врет — если Swagger говорит, что поле email есть, оно должно быть. Всегда.

И самое главное — этот контракт должен соблюдаться. Если бэкендеры меняют API, они обязаны предупредить. Иначе фронтенд превращается в сапера, который каждое утро разминирует прод.

Но, как правило, контракт сделать тяжело. Каждый видит REST по-своему: разные URL, форматы данных, обработка ошибок. Модели данных непоследовательны — поля то есть, то их нет, вложенность меняется. Документации либо нет, либо она устарела, так что API изучаем методом проб и ошибок. От такого надо отказываться сразу и стараться договорится на берегу.

Для унификации и строгого соответствия данных мы используем class-transformer: автоматически приводим данные к нужным форматам, вместо работы с сырыми JSON-объектами. Так получаются экземпляры классов с методами и свойствами. Далее убираем ручную обработку и проверки данных, преобразовываем вложенные структуры и применяем кастомные трансформации.

Что получаем в итоге?

Когда контракт есть, а обертка API готова, магия начинает работать:

• Простота использования: вместо десятков хуков — единая фабрика createApi(). Меньше boilerplate-кода.
• Мощные возможности: данные приходят уже в нужном формате без ручных проверок. Кэш, инвалидация и оптимизации — TanStack Query делает за вас всю грязную работу.
• Новички влетают в проект: больше не нужно объяснять, почему useGetEntity в одном компоненте работает не так, как в другом.
• Активное сообщество: TanStack Query — тысячи разработчиков, готовых ответить на вопросы. Здесь можно найти примеры для любых кейсов: от интеграции с Next.js до кастомного кеширования.
• Нет ограничений по использованию: TanStack Query — не только для React, есть версии для Vue, Svelte и даже Solid.js. Также работает с любым API — REST, GraphQL, WebSockets.
• Работа с SSR без боли: готовая интеграция с Next.js, Remix и другими фреймворками. При этом данные, полученные на сервере, автоматически передаются на клиент. TanStack Query синхронизирует серверный и клиентский рендеринг.

Но есть и ложка дегтя. Отладка усложняется, если что-то сломается внутри обертки — придётся копать глубже. Возникает зависимость от библиотек: class-transformer, axios и сам TanStack Query становятся обязательными.

Однако игра стоит свеч. Потому что время, сэкономленное на рутине, можно потратить на то, что действительно важно — фичи, которые понравятся пользователям, а не бесконечные правки API-вызовов.

Сравнительные примеры

GET /products — Список продуктов

GET /products/:id — Один продукт по id

POST /products — Создание продукта

PUT /products/:id — Обновление продукта по id

DELETE /products/:id — Удаление продукта по id

Как это выглядит в обертке

Все свойства и возвращаемые хуки и конфиги из фабрики:

Пример использования в компонентах:

Использование конфигов:

Для сравнения с классическим решением:

Когда стоит переходить на обертку?

Не каждый проект нуждается в таком подходе к API. Если у вас два-три endpoint’а и они никогда не меняются — возможно, обертка будет избыточной. Но представьте стартап, где каждый месяц добавляются новые сущности: сначала товары, потом отзывы, потом промокоды, рекомендации, аналитика.

Вот где система раскрывается на полную! Новая сущность? Пять минут на добавление — и готовы все CRUD-операции. Изменился бэкенд? Правим в одном месте — и все работает. Пришел новый разработчик? Он не тратит неделю на изучение особенностей API.

Правда, если бэкенд живет в мире хаотичных endpoint’ов (например, GET /fetch_items, но DELETE /removeProduct), обертка не спасет.

Но как навести порядок?

Главный секрет — общаться. Не ждать, пока API сломается, а сразу договориться:

• Какие будут названия полей (created_at vs createdAt);
• Как структурированы ошибки;
• Когда и как можно менять контракт.

Как сказал один разработчик: «фронтенд и бэкенд — как соседи по коммуналке. Можно ругаться из-за бардака на кухне, но лучше сесть и написать правила совместного проживания».

А напоследок — график, для закрепления разницы между работой с оберткой и без нее.

В статье мы разберёмся, как запустить кодген на основе OpenApi схемы для веб-приложения на стэке React + redux-toolkit.

Для справки: контракт — соглашение о формате данных между клиентом и сервером

Какие проблемы решает кодген?

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

В микро-сервисной архитектуре цена таких ошибок высока — оперативно доставить обновления многочисленным клиентам иногда бывает проблематично.

Кодген снижает вероятность таких ошибок, так как методы статично создаются на основе схемы, которая, в идеале, также должна генерироваться на основе кода бекенда. Рассмотрим подробнее.

Синхронизация контрактов

При активной разработке бекенд постоянно обновляет контракты. Без кодгена все обновления на стороне фронтенда синхронизируются вручную.

Также на основе контрактов создаются побочные интерфейсы, например, для redux-слайсов и react-компонентов. Ошибка в основном контракте создает цепочку проблем со связанными типами и интерфейсами.

Сочетание кодген-контрактов и typescript-утилит для создания побочных интерфейсов делает доставку обновлений простой и безопасной.

Устранение дубликатов

Когда проект не имеет четкой структуры, контракты оказываются разбросаны по всей кодовой базе. Разработчики, не сумев найти нужный интерфейс, просто создают свои варианты контрактов. Так рождаются дубликаты и несогласованность.

Кодген решает эти проблемы, создавая единую точку входа для всех методов и интерфейсов.

Совет: Кодген проще и безопасней внедрять на начальных этапах разработки. А в уже написанных проектах — стоит внедрять его постепенно, например, по несколько эндпойнтов за раз.

Что понадобиться для кодгена?

Прежде чем запускать кодген нам нужно минимально настроить проект:

Подготовить схему

OpenAPI-схема в формате yaml:

Важно: Любая ошибка в схеме приводит к поломке кодгена. Поэтому важно, чтобы ваша схема проходила валидацию.

Проверить валидность OpenAPI схемы можно на в swagger редакторе

Настроить Redux

Redux-клиент для API-запросов:

Redux-слайс для хранения данных из API-запроса:

Redux-хранилище с подключенным API-клиентом и редюсером:

Настроить кодген

Для кодгена возьмём официальную библиотеку от Redux — @rtk-query/codegen-openapi

Затем создадим файл настройками кодгена:

Библиотека хороша тем что покрывает все основные потребности, позволяя быстро запустить когден без долгих настроек. Цена удобства — отсутствие гибкости. Адаптировать результат когдена под сложный кодстайл будет проблематично.

Если вам нужна гибкость, попробуйте использовать @openapitools/openapi-generator-cli с различными готовыми шаблонами или Orval от tanstack

Запуск кодгена

Для запуска добавим команду в package.json:

Далее заходим в корень проекта и запускаем команду:

На выходе должен получиться файл codegenApi.ts с содержимым:

Проверяем результат:

• Инджект кодген эндпойтов в baseApi;
• Системные типы Props Response Error;
• Контракт User;
• RTK-query хуки.

Совет: создание кодгена можно автоматизировать, например, сделать его отдельным этапом в CI/CD, который выполняется прямо перед билдом приложения.

Возможные проблемы

Необычные типы данных

При внедрении кодгена в проект на Kotlin я столкнулся с проблемой парсинга: кодген не мог распарсить тип данных LocalDateTime, который должен возвращать строку с датой в формате ISO. Вместо строки когден возвращал пустой объект.

LocalDateTime — это класс из Java-библиотеки java.time, который представляет дату и время без учёта временной зоны.

Данную проблему я решил с помощью кодмода:

Кодмод запускается после команды codegen. Он бежит по файлу сверху вниз, находит нужный тип и меняет его значение на string.

Совет: При добавлении кодмода в общий файл обязательно опишите проблему которую он решает. Когда кодмодов станет много и они начнут конфликтовать, вам будет проще разобраться в их работе.

Кодмоды отлично генерируются с помощью AI.

Плюсы и минусы кодгена

Плюсы:

• Генерируем API-слой всего приложения за секунды;
• Получаем автоматическое строгое создание интерфейсов и типов;
• Избавляемся от опечаток в URL и параметрах;
• Обнаруживаем проблемы с обратной совместимостью контрактов на ранних этапах сборки;
• Экономим время.

Минусы:

• Качество кодгена зависит от качества описания OpenAPI схемы;
• Если схема не генерируется в автоматическом режиме, актуальности OpenAPI схемы потребуется поддерживать вручную;
• Логику нестандартных запросов придётся описывать вручную.

Напоминание: API-слой сложного проекта невозможно покрыть кодогенерацией на 100% — это нормально. Будьте готовы при помощи методов enhanceEndpoints и injectEndpoints комбинировать когден-эндпойнты с эндпойнтам написанными вручную

Заключение

Кодген ускоряет разработку и делает доставку изменений с бэкенда более безопасной, однако подход требует качественной спецификации, поэтому если у вас небольшой проект — скорее всего кодген для вас будет лишним усложнением.

В остальных случаях, используя кодген, вы получите предсказуемый и масштабируемый API-слой, который сэкономит сотни часов разработки и поможет вашей команде сместить фокус c рутинных задач на создание качественной бизнес-логики для вашего веб-приложения.

Ускоряй работу, автоматизируй рутину, используй лучшие тулзы. Все самые полезные инструменты тут.

Немного базы

В этих статьях рассказываем о том, что нужно знать новичкам и не только.

• ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — помогаем новичкам войти войти и показываем опытным разработчикам, что они могли упустить.
• Какие есть паттерны в React и для чего они нужны: часть 1 и Какие есть паттерны в React и для чего они нужны: часть 2 — здесь объясняем популярные архитектурные паттерны в React, когда и зачем их применять.
• 7 библиотек для анимаций на React / Tproger — собрали актуальные библиотеки для анимации в React; сравнение, демо и рекомендации.
• Типичные ошибки джунов, использующих React — показываем типичные ошибки junior-разработчиков в React, рассказываем, как писать чище и стабильнее.
• Подготовка окружения React-приложения: VSCode, Prettier, ESLint, Stylelint, Husky — рассказываем, как начать работу с приложениями на Реакте и что должно быть на рабочем столе.
• React Native против Flutter: что лучше (для общего развития) — сравниваем популярные фреймворки для кроссплатформенной разработки; плюсы, минусы и рекомендации.
• Deeplink в React Native: Полное руководств для новичков — рассказываем, что такое deeplink и как их писать на Реакте.

Практикуемся

• Современный Drag and Drop в React с помощью dndkit: создаем перетаскиваемое меню — здесь о том, как сделать меню, кнопки и все с помощью dndkit.
• Пишем приложение с бэкендом на Django и фронтендом на React — рассказываем, как создать REST API на Джанго, добавить React и объединить это в один проект.
• Создание ToDo-листа бесконечной вложенности на React, TypeScript и MobX — пошагово создаем вложенные задачи в ToDo-приложении, используем MobX, React и TypeScript.
• Создание Typing Test приложения на React + TypeScript + Redux Toolkit — учимся создавать приложение для проверки скорости набора текста, используем Redux Toolkit.
• Найди ошибку в React-компоненте: Функциональное Карри — практический кейс: ищем ошибку в React и заодно изучаем каррирование функций.
• Создание приложений для Windows на React Native — разбираем, как запускать и разрабатывать React Native-приложения под Windows, примеры и инструменты.
• Оптимизация графиков Recharts — ускоряем отрисовку графиков на React с помощью Recharts, практика, кейсы и улучшения.
• Как разработать своё первое приложение на React Native — инструкция по созданию первого мобильного приложения на React Native, от идеи до запуска.
• Пет-проект на React. Как мы «озвучивали» интернет — история реализации проекта с Web Speech API и React. Учим браузер говорить.

Кстати, похожий гайд мы уже делали — про Python. Можно заценить здесь.

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

Но что если запросы такие же легкие как в примере выше? Мы просто берем данные и показываем их. Разве нам нужно каждый раз проделывать такую рутину, если можно облегчить себе жизнь?

Как раз для таких случаев есть инструмент rtk-query (входит в reduxjs/toolkit). Посмотрим как теперь выглядит наш запрос.

В build.query мы передаем два аргумента, 1 — тип, который вернется и 2 — параметры, которые мы принимаем в хуке в компоненте.

Далее в компоненте мы вызываем хук и передаем данные для вызова апи и вторым аргументом, параметры для самого хука. Например, свойство refetchOnMountOrArgChange перезапросит данные при unmount компоненте. В документации можно подробнее прочитать о каждом из них.

Самое главное, что в ответе хука у нас появляются все статусы/данные/фичи. Каждый из них может быть полезен для конкретной ситуации, но все вместе они покрывает почти все кейсы.

Теперь компонент выглядит легко и изящно. Тут мы используем isFetching (отличие от isLoading в том, что он активируется при любой загрузке, а isLoading только при начальной). Можно вызывать refetch для перезапроса или проверить isError при ошибке.

Также мы можем вызывать хук с задержкой. Так называемый lazy query.

Тут мы делаем запрос из хука. Обычно это нужно, если хотим передать аргумент в хук, который появляется не сразу. Также проверяем isUninitialized, чтоб хук был проинициализирован и далее при загрузке стал false.

Плюс к этому, rtk дает возможность использовать мутации для обновления данных. Это будет выглядеть примерно так:

Для чего не подходит rtk?

Для сложных операций, таких как пагинация или хранение переменных между запросами. В подобных кейсах лучше использовать саги и не ставить костыли с ртк. Ведь его главная цель избавить нас от рутинных запросов.

Меня зовут Юсуп Изрипов, я сеньор разработчик в VK. Работаю над продуктами, которыми ежедневно пользуются миллионы человек.

В этих статьях я расскажу вам о самых популярных паттернах и приведу примеры кода. Мы рассмотрим, когда каждый из них может пригодиться, а также отметим их плюсы и минусы. Поговорим о классических приёмах вроде контейнеров и HOC, эволюции к хукам, также обязательно рассмотрим новые паттерны появившиеся в последних версиях React.

Container + Presentational Components

На первом месте работы ещё во время разработки на Vue мы с подачи нашего тимлида решили ввести этот паттерн. Глобально у нас были так называемые «умные» и «тупые» компоненты (или как я тактично называл их на демо — визуальные). Как вы наверняка догадались, роль Container у нас исполняли «умные» компоненты, а роль Presentational — «тупые». В чём, собственно, суть этого паттерна? Слышали выражение «разделяй и властвуй»? Паттерн Container & Presentational Components (контейнерные и презентационные компоненты) ровно об этом: он разделяет логику (данные и взаимодействие с ними) и отображение (UI) на разные компоненты.

Presentational Components отвечают только за то, как что-то выглядит. Они получают данные через props и отображают их, больше ничего. Это, как правило, чистые функциональные компоненты, часто без собственного состояния (ну разве что мелкий UI-стейт типа «раскрыт ли dropdown»). Им всё равно, каким образом взять список пользователей — они просто ожидают условный props.users и отображают его в соответствии с дизайном.

Container Components, напротив, знают, что показать и откуда это взять, но не занимаются тем, как это отображается. Они содержат в себе всю логику: могут загрузить данные, подписаться на store или контекст, хранить состояние, а рендерят в презентационных компоненты, передавая им готовые данные. Контейнер может вообще не иметь собственного HTML, кроме того, что приходит от дочернего презентационного компонента. Его задача — это взаимодействие с данными.

Зачем же нужен такой подход? Во-первых, лучшая разделённость ответственности (UI отдельно, данные отдельно) упрощает понимание и поддержку приложения. Во-вторых, улучшается переиспользование: один визуальный компонент вероятно использовать с разными источниками данных через разные контейнеры. Дизайнеры могут менять внешний вид компонента в одном месте, не затрагивая бизнес-логику. И тестировать тоже проще: можно отдельно протестировать логику контейнера (без верстки) и отдельно визуальный компонент (с моком данных).

В этом примере UserList не содержит никакого стейта, не подписан на store или контекст, лишь отображает список. Ему всё равно, как и где получают пользователей — просто принимает проп users и выводит его. Контейнер UserListContainer же занимается работой с данными: делает fetch, сохраняет результат в useState, и потом рендерит UserList, прокидывая в него данные. Благодаря такому делению компонент UserList легко переиспользовать — хоть для локальных данных, хоть для данных из Redux или context — достаточно написать другой контейнер.

Конечно, не всегда нужно городить пару компонентов вместо одного. Этот паттерн полезен, когда приложение растёт: вы начинаете замечать, что пропсы идут через несколько уровней просто транзитом, или один компонент слишком перегружен логикой. Тогда вы «вытаскиваете» логику в контейнер, а UI — в презентационный компонент, и код сразу становится чище. Это не обязательное правило, а приём для рефакторинга по мере необходимости.

Стоит отметить, что с появлением React-хуков граница между логикой и отображением несколько размылась. Теперь можно выносить логику в кастомные хуки и вызывать их прямо внутри компонента, вместо того чтобы создавать отдельный контейнер-класс, как это делали до 2018 года. Тем не менее, принцип «держи логику отдельно от представления» по-прежнему полезен. Даже с хуками можно структурировать код, разделяя функциональность: написать хук useUsersData() для получения пользователей и применять его в разных компонентах (вместо дублирования запроса).

Плюсы: чёткое разделение обязанностей, возможность переиспользовать и заменять части независимо (UI-компонент можно переиспользовать с разными данными), облегчение тестирования.

Минусы: появляется больше файлов/компонентов, чем могло бы быть, что может казаться избыточным для мелких случаев. Иногда чрезмерное дробление на «глупые» и «умные» компоненты лишь усложняет структуру, если паттерн применён не к месту. Как говорится, включайте голову — не каждую кнопку нужно выделять в отдельный контейнер.

Higher-Order Component (HOC)

Когда я впервые услышал термин HOC, он показался мне чем-то из математики. Но на практике всё горадо прозаичнее: HOC — это всего лишь функция, которая принимает React-компонент и возвращает новый компонент, оборачивая исходный дополнительной функциональностью. Проще говоря, HOC — это «обёртка». Мы помещаем один компонент внутрь другого, чтобы на выходе получить расширенную версию переданного в HOC компонента.

Зачем это может понадобиться? Представим, у нас есть несколько разных компонентов, и всем им нужно что-то общее: например, обработка ошибок или подписка на внешние данные. Можно было бы скопировать этот код в каждый из компонентов, но куда элегантнее написать HOC один раз и применить ко всем. Классический пример — Redux-функция connect: вы пишете export default connect(mapState)(MyComponent), и ваш компонент получает пропсы из глобального стейта.

connect — как раз и есть HOC, который инъектирует данные из Redux в компонент, не требуя от вас переписывать все под Redux вручную.

Создать свой HOC тоже несложно. Супер банальный пример — сделаем HOC, который добавляет компоненту стейт счётчика:

Здесь withCounter — HOC, он возвращает новый функциональный компонент WithCounter, который внутри себя использует useState и передаёт состояние и функцию увеличения внутрь WrappedComponent. В итоге EnhancedButton — это улучшенная версия ClickButton, которая умеет считать клики, даже если исходный ClickButton об этом не знал.

Плюсы: один HOC может добавить функциональность множеству компонентов сразу — не надо копировать код везде. Логику обновляется в одном месте (внутри HOC) — и все обёрнутые компоненты получают изменения. HOC можно комбинировать: например, обернуть компонент сначала в HOC, добавляющий тему оформления, потом в HOC, добавляющий логирование, и т.д. В итоге получим компонент, обладающий сразу несколькими дополнительными возможностями.

Минусы: за такую магию мы платим усложнением структуры. Когда компонентов обёрток становится много, React-дерево раздувается, и возникает эффект «матрёшки». В DevTools вы могли видеть что-то вроде: Connect(withRouter(WithTheme(MyComponent))) — разобраться, что к чему, становится сложнее. Дебаг таких цепочек — тоже удовольствие то ещё, приходится пробираться через несколько уровней абстракций. Кроме того, HOC часто прокидывают пропсы во внутренний компонент, что чревато конфликтами имён (нужно следить, чтобы, например, prop.title от HOC не перезаписал пропс title, который вы передали самому компоненту). Ещё нюанс — HOC усложняют типизацию в TypeScript (надо правильно описывать generic для пропсов), но это выходит за рамки нашей темы.

React-разработчики со временем несколько охладели к HOC. В официальной документации прямо сказано: «компоненты высшего порядка не так часто используются в современном React-коде». Отчасти их вытеснили хуки, тем не менее, HOC никуда не делись: их продолжают применять сторонние библиотеки — тот же Redux, Relay и другие. Да, и в старом проекте вы почти наверняка встретите хотя бы пару HOC. Поэтому понимать этот паттерн стоит. Просто имейте в виду современные альтернативы и используйте HOC там, где это действительно необходимо.

Паттерн Render Props

Следующий паттерн я бы назвал «перевёрнутый HOC». Render Props — это подход, когда компонент сам не рендерит что-то внутри себя, а принимает функцию (часто через проп render или просто используя детей как функцию) и вызывает её, чтобы получить содержимое. То есть мы передаём компоненту инструкцию, что именно отрендерить, а он сам обеспечивает, когда и с какими данными вызвать эту инструкцию.

Представьте компонент <MouseTracker> для отслеживания положения курсора. Классически он может хранить x, y в своём состоянии и отрисовывать, скажем, <p>Mouse at (x, y)</p>. Но что, если мы хотим переиспользовать эту логику уже с другим UI? Паттерн Render Props предлагает сделать компонент <Mouse>, который не определяет жёстко JSX внутри себя, а вызывает функцию, переданную через проп (или children функцию), передавая ей координаты. Эта функция сама решит, что рисовать. Таким образом, <Mouse> инкапсулирует логику (слежение за мышкой), а отображение делегирует наружу.

Пример: реализуем компонент-утилиту <FilteredList items={...} filter={...}>, который отображает список на основе передаваемого фильтра. Вместо того чтобы жёстко прописывать разметку элемента списка, сделаем его с render проп через children:

Здесь <FilteredList> знает, как отфильтровать массив (items.filter(filter)), но не знает, как отрисовать каждый элемент. Вместо этого он вызывает функцию, которую мы передали в качестве дочернего элемента (children), для каждого элемента списка. Эта функция возвращает <li> для каждого item. В результате логика фильтрации инкапсулируется внутри FilteredList, а конкретное отображение списка задаётся извне. Мы могли бы так же использовать этот компонент для массива объектов, отрисовывая, например, товары — достаточно передать другую children-функцию.

Паттерн Render Props здорово повышает гибкость компонентов. Мы можем переиспользовать <FilteredList> для списков чего угодно — чисел, пользователей, товаров — просто изменяя функцию отображения. Другой пример: компонент <Mouse> может предоставлять координаты курсора, а внешний код решит, просто вывести текст, нарисовать по координатам картинку или вызвать какую-то совершенно другую логику — не нужно делать несколько вариаций компонента для каждого кейса.

Плюсы: Render Props позволяет компоненту-провайдеру (в примере выше FilteredList является провайдером данных) быть максимально универсальным, а конкретную разметку делегировать наружу. Многие библиотеки воспользовались этим паттерном: например, React Router (до версии 6) позволял вместо компонента страницы передать проп render в <Route> — функцию, которая отрисует JSX на основе параметров маршрута. Formik предлагал компонент <Formik> с функцией-ребёнком для рендеринга формы. Downshift (библиотека для автокомплитов) — тоже классический пример паттерна render props.

Минусы: главное неудобство — излишний шум в JSX. Код с вложенными функциями бывает тяжело читать. В нашем простом примере всё компактно, но представьте, если у вас будет несколько уровней таких компонентов: <Foo>{foo => ( <Bar>{bar => ( ... )}</Bar> )}</Foo> — легко получить «оберточный ад» из стрелочных функций прямо в разметке. Это значительно затруднит отладку такого кода при возникновении каких-либо проблем. К тому же, каждый раз при рендере создаётся новая функция, что может негативно сказаться на производительности, если таких компонентов много (React конечно оптимизирует функции в пропсах через механизм сравнения, но всё же). Также возникает неявная связь: внешний код должен знать, какие аргументы ожидает функция. TypeScript конечно помогает, но при чтении кода не сразу видно, что children, например, это не просто элемент, а функция.

Как и HOC, паттерн Render Props сейчас используется реже. Многие задачи, решаемые через него, теперь элегантнее с точки зрения кода решаются хуками, в официальной документации это также отмечено. Но всё же понимать его нужно, потому что легаси-код и некоторые библиотеки всё ещё работают на нём. Если видите, что компонент принимает функцию в виде пропса (чаще всего называется render или передаваётся через детей), знайте — это он, Render Props.

В следующей части расскажу про хуки и кастомные хуки, а также про Compound Components и Серверные компоненты и Suspense.

Если вы создаете мобильное приложение на React Native, то рано или поздно столкнётесь с необходимостью организовать навигацию между экранами. Сегодня мы разберём одну из самых популярных библиотек для этого — React Navigation . Это мощный инструмент, который позволяет создавать сложные и гибкие системы навигации. Погнали!

Что такое React Navigation?

React Navigation — библиотека, которая помогает управлять переходами между экранами в React Native приложении и не только. Она предоставляет готовые компоненты и API для создания различных типов навигации: стек, таб, боковой навигации и даже модальных окон.

Основная идея заключается в том, что навигация представляет собой дерево , где каждый узел — экран или группа экранов. Это дерево можно строить рекурсивно, добавляя новые уровни навигации внутри уже существующих.

Как это работает?

React Navigation использует концепцию навигаторов (navigators). Навигатор — контейнер, который управляет группой экранов. Вот основные типы навигаторов:

1. StackNavigator — стек навигация, где экраны накладываются друг на друга.
2. TabNavigator — таб навигация, где экраны переключаются через нижнюю или верхнюю панель.
3. DrawerNavigator — выдвижная боковая панель для навигации.
4. BottomSheetNavigator — модальные экраны, которые выдвигаются снизу.

Каждый навигатор может содержать другие навигаторы, формируя древовидную структуру. Например, у тебя может быть TabNavigator, внутри которого есть StackNavigator для каждого таба. Листьями будут конечные экраны приложения.

Структура навигации как дерево

Структура навигации — фундамент вашего приложения. От того, насколько грамотно она организована, зависит не только удобство пользователей, но и простота поддержки кода, производительность и масштабируемость проекта.

Навигация должна быть организована логично. Например:

Здесь AppNavigator — корневой навигатор, который содержит два дочерних навигатора: AuthNavigator и MainNavigator. В свою очередь, MainNavigator содержит HomeStack, который уже управляет экранами HomeScreen и DetailsScreen.

Такая структура позволяет:

1. Логически разделить функциональность: Например, экраны авторизации можно отделить от основной части приложения.
2. Управлять состоянием: Каждый навигатор хранит своё состояние (текущий экран, параметры переходов и т.д.), что делает управление предсказуемым.
3. Оптимизировать рендеринг: React Navigation автоматически оптимизирует рендеринг экранов, загружая только те, которые находятся в текущем фокусе.

Как строится навигация?

Корневой навигатор

Корневой навигатор — первый уровень дерева. Обычно он используется для разделения логики авторизации и основного приложения. Пример:

Здесь AuthNavigator и MainNavigator — отдельные компоненты, которые содержат свои собственные навигаторы.

Навигаторы внутри навигаторов

Как видно из примера выше, навигаторы могут быть вложенными. Это позволяет создавать сложные системы навигации. Например, MainNavigator может быть TabNavigator, а внутри одного из табов — StackNavigator.

Здесь HomeStack — стековая навигация, которая находится внутри MainTabs.

Логика авторизации

Один из самых распространённых подходов — разделение навигации на две части: для неавторизованных и авторизованных пользователей. Это можно сделать с помощью глобального состояния (например, Redux или Context API).

Пример:

Такой подход позволяет легко переключаться между двумя состояниями приложения.

Таб навигация

Таб навигация — один из самых популярных способов организации интерфейса. Вот пример простой реализации:

Совет: используйте библиотеку react-native-vector-icons для иконок. Они делают интерфейс более привлекательным.

Почему такая структура?

Разделение ответственности

Каждый навигатор отвечает за свою часть приложения. Например:

• AuthNavigator управляет экранами входа и регистрации,
• MainNavigator управляет основным функционалом приложения.

Это упрощает поддержку кода и делает его более читаемым.

Управление состоянием

Каждый навигатор хранит своё состояние. Например, если пользователь находится на экране Details внутри HomeStack, то при возвращении на главный экран Home, состояние будет сохранено.

Гибкость

Вложенная структура позволяет комбинировать различные типы навигации. Например, вы можете использовать TabNavigator для основных экранов и StackNavigator для деталей внутри каждого таба.

Почему не стоит использовать стандартный header?

Стандартный header библиотеки часто выглядит слишком сырым, плохо кастомится и неочевидно работает. Лучше скрывать его и реализовывать собственный компонент для заголовков. Это даёт больше контроля над дизайном и функциональностью:

Deeplink при помощи навигации

Deeplink позволяет открывать конкретные экраны приложения через ссылки. Например, если пользователь кликнет на ссылку myapp://profile, он сразу попадёт на экран профиля.

Для реализации deeplink используйте метод linking в корневом навигаторе:

Более подробно про deeplink рассказывал тут.

Хуки React Navigation

React Navigation предоставляет множество полезных хуков, например:

• useNavigation — получение объекта навигации,
• useRoute — доступ к параметрам текущего маршрута,
• useIsFocused — проверка, находится ли экран в фокусе.

Пример использования:

Про хуки можно рассказывать много и долго, лучше этот момент изучить в документации. Но есть несколько советов относительно их использования:

1. Не злоупотребляйте useNavigation. Если вы используете useNavigation слишком часто, это может быть признаком того, что ваша архитектура требует пересмотра. Постарайтесь минимизировать его использование.
2. Избегайте лишних ререндеров. Хуки, такие как useIsFocused или useFocusEffect, могут вызывать дополнительные ререндеры. Используйте React.memo или useCallback для оптимизации.
3. Очистка эффектов. Не забывайте очищать эффекты в useFocusEffect, чтобы избежать утечек памяти.
4. Проверяйте типы данных. При работе с useRoute всегда проверяйте, что параметры существуют, чтобы избежать ошибок.

Подводные камни и нюансы

1. Передача параметров между экранами. Не забывайте очищать параметры, если они больше не нужны. Иначе это может привести к утечкам памяти.
2. Глубокое дерево навигации. Слишком сложная структура навигации может затруднить отладку и поддержку кода. Старайтесь держать её максимально простой.
3. Анимации. По умолчанию анимации могут быть тяжёлыми для производительности. Используйте react-native-reanimated для оптимизации.
4. Обновление состояния. При использовании глобального состояния (например, Redux) убедитесь, что оно обновляется корректно при переходах между экранами.

Вспомогательные библиотеки

Для улучшения работы с React Navigation полезны следующие библиотеки:

1. react-navigation-shared-element — анимации переходов между экранами,
2. react-navigation-hooks — хуки для удобной работы с навигацией,
3. react-native-screens — оптимизация производительности экранов.

Как лучше всего построить структуру: советы

Минимизируйте вложенность

Как уже упоминал ранее, слишком глубокая вложенность усложняет отладку и может привести к проблемам с производительностью. Старайтесь держать структуру максимально плоской.

Используйте ленивую загрузку

Ленивая загрузка экранов помогает уменьшить время загрузки приложения. Например:

Избегайте дублирования

Если у вас есть повторяющиеся элементы интерфейса (например, header), вынесите их в отдельные компоненты, чтобы избежать дублирования кода.

Используйте глобальные параметры

Для передачи данных между экранами используйте параметры маршрута (route.params). Однако избегайте передачи больших объёмов данных через параметры — лучше используйте глобальное состояние.

Пример полной структуры

Правильная структура навигации — ключ к созданию удобного и производительного приложения. React Navigation предоставляет мощные инструменты для организации, но важно подходить к этому процессу осознанно. Разделяйте логику, минимизируйте вложенность и следуйте лучшим практикам, чтобы ваше приложение было не только красивым, но и удобным для поддержки.

Если остались вопросы или хотите обсудить конкретные случаи — пишите в комментариях!

Мы собрали топ самых эффективных инструментов для фронтенда в 2025 году. Актуальная информация о фреймворках, библиотеках, средствах сборки, проверки и отладки будет полезна как начинающим, так и опытным прогерам.

Фреймворки и библиотеки для разработки интерфейсов

Создание фронтенда, то есть клиентской части программного продукта — неотъемлемый этап разработки сайтов и приложений. Фронтендеры работают с с HTML, CSS, JavaScript, а также используют многочисленные библиотеки с готовыми решениями. Даже новички в курсе, что без фреймворков проекты сегодня не пишутся — это долго, тяжело и непродуктивно. Ниже — наиболее эффективные фреймворки для разработки UI.

React.js

Созданная Джорданом Валке, ведущим программистом самой известной в мире соцсети, библиотека React остается лидером в сфере разработки инфраструктуры на JavaScript UI. На React.js написаны такие проекты, как Skype, PayPal, Airbnb, Dropbox и многие другие.

Популярность библиотеки объясняется вполне объективными причинами:

• Обширное комьюнити. Только на GitHub вы найдете больше 110 тыс. публикаций с тегом «react». Библиотекой пользуются во всем мире, а тысячи профессиональных программистов постоянно обновляют инструменты и актуализируют данные. Если у разработчика появится вопрос, он обязательно найдет на него ответ в сообществе.
• Технологический бэкграунд. Библиотеку создали профи из FB для себя — такие проекты делаются максимально качественно и надежно. Тот факт, что технологии доверяют крупнейшие мировые корпорации, говорит сам за себя.
• Активное взаимодействие с TypeScript. Этот инструмент представляет собой продвинутую версию JS, который со временем стал слишком тяжелым в плане кода. TypeScript лишен многих недостатков Java, поэтому активно применяется в React.js. В общем, в 2025 году фреймворк точно не умрет.
• Версионность. В React, в отличие от Angular или Vue, код, написанный даже несколько лет назад, без проблем запустится на новейшей версии. А если там есть неактуальный элемент, программа сама подскажет, как его исправить.

В React 19 появились новые, еще более мощные компоненты, повышающие производительность и пользовательский опыт:

• Улучшенная поддержка Server Components, с которой более удобно работать с серверным рендерингом и загружать контент в больших проектах;
• Новый API — Actions, который делает более простой и продуктивной работу с формами и интерактивными элементами;
• Директивы preload и preinit обеспечивают предварительную загрузку важных ресурсов, что ускоряет работу приложений;
• Новый канал релизов React Canaries позволяет протестировать некоторые опции React еще до их официального выпуска.

Улучшения произошли и в экосистеме React. Упрощается работа с Redux — библиотекой, которую все чаще используют в связке с React. Инструменты для работы с таблицами и интерфейсами React Table 8 более доступны и производительные.

Vue.js

Еще один мощный, но при этом простой и гибкий в применении инструмент для фронтенд-разработчиков — Vue.js. Согласно экспертным прогнозам, он сохранит свои позиции в топе-3 фреймворков для JavaScript в 2025 году.

Относительно недавно создатели Vue радикально обновили движок и архитектуру. При этом доля TypeScript кода в репозитории приближается к 99%, что расценивается профессиональными прогерами крайне позитивно.

Команда разработчиков Vue.js, возглавляемая Эваном Ю, в свое время заявила, что фреймворк станет самым простым и удобным инструментом из всех существующих. По мнению экспертов, их слова полностью подтвердились.

В числе главных преимуществ фреймворка:

• Подходит для новичков. Для освоения достаточно знания HTML, CSS, JavaScript;
• Небольшой вес. Размер новой заархивированной библиотеки runtime меньше 10 kb;
• В пакет входит виртуальный DOM — объектная модель документа;
• Активное крутое сообщество. Профессионалы помогут, если у разработчика возникнут проблемы.

Количество полноценных приложений, сделанных на Vue.js, превышает 36 тысяч. Это число постоянно растет, и в 2025 году тренд обязательно продлится. В экосистему внедряются новые технологии, например, Vapor Mode, — инструмент, открывающий новые горизонты для разработки высокопроизводительного софта.

Подход, заданный Composition API, позволяет создавать компоненты через импорт функций вместо обновления опций. На выходе получаем более чистую архитектуру, что особенно важно для продуктов со сложной логикой.

Появление высокоуровнего фреймворка Nuxt 4 принесет важные улучшения в плане производительности и гибкости разработки. Поддержка Vue 3.3+ в Nuxt 4 улучшает работу с анимацией и межкомпонентные переходы. Пользовательский интерфейс становится более динамичным и плавным.

На фреймворке Vue созданы сайты Ozon, Zoom, Chess (сайт для шахматистов с посещаемостью 20 млн пользователей в месяц), Livestorm — платформа для запуска вебинаров, и многие другие ресурсы.

Angular

Этому мощному фреймворку доверяет Google, что уже говорит само за себя. Множество десктопных и мобильных приложений создано на AngularJS — это крутой инструмент с минимальным риском критических ошибок. На сайте фреймворка создатели призывают разработчиков сосредоточиться на приложениях, а код Angular берет на себя.

И хотя профи считают этот фреймворк более сложным в освоении, чем Vue и React, его функциональность оправдывает все трудности учебного процесса. В 2025 году эволюция Angular продолжится: его последние версии показывают существенные изменения в подходах к реактивности ПО и управлению состоянием.

Новые решения, на которые стоит обратить внимание:

• К числу ключевых нововведений фреймворка относится технология Signals, которая делает взаимодействие с реактивными данными более простым. «Сигналы» актуальны в том случае, когда требуется синхронное обновление UI и оптимизация производительности приложения.
• В Angular 19 компоненты Standalone стали новым стандартом. Теперь они могут использоваться без добавления в модуль. Такое решение упрощает архитектуру приложений и делает подход к коду более прямолинейным.
• Внедрение зависимостей (DI, Dependency Injection) дополнено новой функцией inject() — она заменяет стандартный конструктор, что также упрощает код и делает его более гибким.
• Автоматическая миграция продуктов к новому API — еще один шаг к упрощению и сокращению кода. Это напрямую отражается на производительности современных приложений, в первую очередь, на больших и логически сложных.

Прежние плюсы Angular остались неизменными — расширяемость, взаимодействие с другими фреймворками и инструментами, множество надстроек и дополнений — Auto Validate, Complete, Grid и т.д.

На фреймворке написан сайт британской газеты The Guardian, интерактивные элементы PayPal, самый посещаемый сайт мониторинга погоды Weather.com, фронтенд музыкального ресурса VEVO и многие другие продукты.

Svelte

В свое время фреймворк предложил принципиально новый подход к разработке пользовательских интерфейсов. Концепция создателей Svelte — делать больше с минимальными затратами. Некоторые разработчики считают Svelte больше компилятором, чем фреймворком, что по сути соответствует действительности.

В чем основные фишки Svelte:

• При меньшем весе проекты более производительны — им не требуется виртуальный DOM;
• Фреймворк прост в освоении, поэтому подходит начинающим разработчикам;
• Опытные прогеры обращают внимание на быстроту и стабильность инструмента;
• Анимации в Svelte доступны прямо из коробки — сторонние библиотеки не требуются.

На текущем этапе этот фреймворк рано ставить на одну ступень с React и Vue, но его рейтинг на GitHub постоянно повышается, и в 2025 году растущий тренд точно сохранится.

Фронтенд-разработкой с фреймворком Svetle пользовались такие компании, как Spotify, Ikea, Finance.yahoo, Music.apple и многие другие.

Solid.js

Минималистичный фреймворк, который по производительности и быстроте превосходит все остальные фреймворки из топа. Solid напоминает React, но вместо виртуального DOM использует компиляцию. Проект без проблем компилируется в JavaScript-код, что обеспечивает быстрый рендеринг страницы (трансформацию кода в картинку для пользователя).

В чем плюсы:

• Тонкая реактивность обеспечивает оптимизацию рендеринга в реальном времени;
• Есть бесшовная интеграция со всеми актуальными библиотеками на JS;
• Компоненты фреймворка — стандартные JavaScript-функции: они выполняются однократно для настройки представления, после чего автоматически обновляют интерфейс.

Solid.js, по состоянию на 2025, — идеальный инструмент для одностраничных приложений и продуктов с максимальной интерактивностью (чат-ботов, мессенджеров, панелей управления).

Фреймворк используют такие ресурсы, как 1c.ru, криптовалютная биржа Ape.pro, маркетплейс Майнкрафт Waypoint Studios и другие.

Инструменты для сборки и разработки

По мнению большинства экспертов, в 2025 году ведущим трендом в сборке и разработке на JavaScript будет работа с универсальными мета-инструментами, совместимыми с любыми фреймворками.

Топ наиболее эффективных инструментов этого направления:

• Vite. Локальный сервер разработки от Эвана Ю. В новой версии Vita 6 возможности существенно расширились, в том числе в плане поддержки других фреймворков, помимо Vue. Благодаря модульной архитектуре и новой системе плагинов, улучшилась кастомизация сборки (процесс внесения изменений). С Vite можно использовать несколько фреймворков в одном проекте — для сложных приложений это актуальная опция. Обновления в реальном времени происходят быстро и стабильно.
• Webpack. Сборщик модулей, который компилирует части кода в единый файл. Работает с JavaScript и TypeScript. Несмотря на появление новых инструментов сборки, в 2025 году Webpack останется обязательным инструментом, особенно для работы с масштабными проектами. Он оптимизирует размер и скорость загрузки ресурсов, эффективно выстраивает процессы разработки, в том числе HMR — горячую замену модулей. Плюс обеспечивает совместимость продуктов с различными версиями браузеров.
• Parcel. Главная фишка этого инструмента в том, что его не нужно настраивать и конфигурировать — это делается автоматически. Parcel применяет воркеры — скрипты для многоядерной компиляции, и содержит кэш файловых систем для ускоренной сборки. Есть поддержка из коробки JS, CSS, HTML, поэтому соответствующие плагины не требуются. Модули, которые меняются в процессе разработки, обновляются автоматически.

Тестирование и отладка

В 2025 году в тестировании и отладке продуктов наиболее востребованы следующие инструменты:

• Jest. Самый популярный фреймворк для тестирования кода на JavaScript. Работает с синхронным и асинхронным кодом, интегрируется с React и Vue. В числе основных плюсов — простая настройка и удобное применение. Подходит для проверки и отладки сложных приложений.
• Cypress. Инструмент для автоматизации тестирования, который подходит новичкам. Использует тест end-to-end, покрывая весь путь пользователя, и внедряется в CI/CD — процессы непрерывной доставки и развертывания. Благодаря подробной документации подходит для новичков.
• React Testing Library. Библиотека эффективных инструментов для тестирования пользовательских интерфейсов UI. RTL позволяет абстрагироваться от внутренней логики компонентов и проверяет состояние реального DOM, то есть имитирует действия пользователей, руководствуясь только данными браузера.
• Storybook. Позиционируется как максимально простое средство тестирования и разработки. Создает изолированную программную среду для ускоренного и эффективного процесса.

Инструменты для контроля версий

Актуальные в 2025 средства для контроля созданных разработчиками версий:

• Git. Распределенная VCS (система управления версиями) отслеживает изменения в исходном коде и файлах в совместных проектах. Позволяет править и контролировать версии в процессе разработки. Обладает расширенными возможностями работы с репозиториями.
• GitHub/GitLab. Службы управления репозиториями, которые используются и для управления изменениями в опенсорс-проектах. Оба репозитория обладают полным набором инструментов для контроля и интеграций, обеспечивая эффективную совместную разработку и неограниченное сотрудничество. Обладают встроенными опциями безопасности, которые разработчики могут в любой момент активировать.
• Bitbucket. Аналог GitHub с бесплатным доступом к контролю команды до пяти разработчиков. Подходит для написания частных проектов, обладает гибкостью, совместим со множеством других инструментов, в том числе с Jira, — средой для управления проектами. Интеллектуальный семантический поиск JQL сканирует код по запросу пользователя.

CSS-процессоры и CSS-фреймворки

Инструменты для первичной трансляции кода, актуальные в 2025 году:

• Sass. Препроцессор упрощает написание кода, исключая одинаковые участки или заменяя ключевые элементы синтаксиса одним знаком. Sass считается самым надежным языком расширений CSS, содержит средства импорта и множество других функций.
• Less. Этот препроцессор поддерживает CSS и позволяет разработчикам применять его методы для улучшения и дополнения веб-приложений. В Less встроены логические, строковые, математические функции, а также функции списков.
• Bootstrap. Классический фреймворк для ускоренной верстки со множеством встроенных компонентов. Более 20% всех сайтов в мире создано с его помощью. Автоматически выстраивает адаптивную сетку на базе Flex-модели, создает изображения, поставляется с панелями навигации и другими компонентами.
• Tailwind CSS. Фреймворк, который пользователи называют прогрессивной версией Bootstrap. Содержит обширный каталог утилитарных классов и инструментов для прототипирования, стилизации сайтов и приложений. Легко настраивается, работает с собственными служебными шаблонами, создает сложные адаптивные макеты, в том числе с ориентацией под мобильные устройства.

Инструменты для работы с API и серверной логикой

Эффективная работа с API обеспечивает надежность при обработке информации в приложениях.

В 2025 году топ таких инструментов выглядит следующим образом:

• GraphQL. Язык, описывающий взаимодействие клиента с сервером. Рассматривается как альтернатива стандартного инструмента REST. В сравнении с последним, более удобен в применении, содержит обширный инструментарий.
• Apollo Client. Язык запросов, созданный разработчиками FB. Интегрируется с GraphQL и React для управления состоянием приложения. Предоставляет эффективные инструменты в виде поддержки кэширования, управления состоянием и исправления ошибок. Интегрируется с библиотекой Redux и другими фреймворками.
• Axios. JS-библиотека для работы с HTTP-запросами, а по сути — клиент для работы в браузере и с платформой Node.js. Помогает настроить взаимодействие между frontend и backend.

UI и UX-дизайн

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

Эти инструменты сохраняют свою актуальность в 2025 году:

• Figma. Графический редактор, который остается самым популярным инструментом для проектирования интерфейсов, прототипирования и тестирования. Также это среда взаимодействия команды разработчиков, доступная непосредственно в браузере. Содержит удобные инструменты, может работать в режиме многозадачности.
• Adobe XD. ПО для работы с интерфейсами, анимированием, прототипами сайтов, сервисов и приложений от лидера индустрии. Основной инструмент UX-дизайнеров, желающих создавать юзабельные и современные макеты и делиться результатами работы с командой. Содержит многочисленные инструменты для рисования, создания 3D-эффектов, добавления интерактивных функций и анимации.
• Sketch. Выбор многих профессионалов индустрии UI/UX дизайна. Упрощает разработку интерфейсов благодаря множеству встроенных полезных функций — артбордов, редакторов, поддержкой командной работы в режиме онлайн. Работает только с macOS.

При выборе фреймворков и инструментов фронтам стоит руководствоваться удобством и простотой использования, соответствием собственному профессиональному уровню, языковой поддержкой, ценой, а также спецификой создаваемого продукта.

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

Рассказывайте в комментариях, какими фреймворками и библиотеками пользуетесь вы. А если хотите найти большей полезной информации про фронтенд — вам сюда.

Впервые идея создать приложение для подбора меню появилась в начале 2024 года. На тот момент в моей жизни было две главные проблемы:

• Я работала в Учи.ру, где мы писали браузерную игру на чистом JS, поэтому я очень скучала по реакту.
• Мне надоело придумывать, что готовить. Из-за этого мы с мужем перешли на готовые рационы. Но, во-первых, питаться только доставками дорого. А во-вторых, всё равно приходилось мыть посуду, потому что мы сознательные разработчики, которые сортируют мусор и сдают пластик в переработку.

В какой-то момент я поняла, что пришло время перемен, и придумала, как разом решить все мои проблемы — нужно создать приложение для подбора меню.

Подготовка

Первое, что я сделала — набросала схему в FigJam. Здесь отметила, какие функции обязательно должны быть в MVP, а какие войдут в следующие версии проекта (v1.5, v2 и даже v3).

После этого нарисовала первый прототип приложения. Потом поняла, что совсем не шарю в графике, и обратилась к подруге — веб-дизайнеру. Вот такое «до/после» у нас получилось.

Чтобы ничего не забыть, все задачи отмечала в Notion, а когда он закрылся, перешла в AnyType. Кому-то он нравится больше, но лично мне не хватило возможности переносить таски из одного столбика в другой (или я просто не поняла, как это делать). Поэтому в скором времени планирую переезд в Obsidian.

Кое-что по технарю

Для разработки я выбрала эти инструменты:

• Библиотека: ReactJS. Думаю, пояснения будут излишни.
• Стор: Redux Toolkit. Много раз видела его в вакансиях, но ни разу с ним не работала, поэтому было интересно пощупать на практике.
• Базы данных: Supabase — аналог Firebase. Тоже взяла впервые.
• Сборка: Vite, потому что он быстрый и классный.
• Деплой: Vercel. В отличие от GitHub Pages может делать всё за одно нажатие кнопки.

Ещё хотела использовать UI-библиотеку, но так как приложение небольшое, то решила не тащить лишние килобайты и сверстать всё сама.

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

Как работают алгоритмы

Основа приложения — это три главных экрана:

• рецепты,
• холодильник,
• список покупок.

Работает это просто: я заполняю раздел «Холодильник» и отмечаю, какие продукты уже есть дома, а приложение подбирает подходящие рецепты из базы данных.

Например, сейчас в базе есть рецепты шакшуки, авокадо-тоста или гранолы с фруктами. При этом для шакшуки у меня есть 67% ингредиентов, для тоста — ровно половина, а для гранолы — только 33%. Поэтому идём по пути наименьшего сопротивления и выбираем на завтрак яйца. А недостающий перец автоматически отправляется в список покупок.

Конечно, высчитывать проценты не обязательно, тем более, все равно нужно идти в магазин. Но, во-первых, не хочется тащить до дома гигантский пакет, а, во-вторых, нужно успеть использовать уже имеющиеся продукты до истечения срока годности.

Список покупок можно заполнять и вручную. Если продукт, который вы хотите добавить, там уже есть, то высветится предупреждение. А вот рецепты пока пополняются только через базу данных — в будущем хочу это исправить.

Немного проблем

В процессе работы было несколько трудностей:

• Нехватка времени. Я начала делать приложение на новогодних каникулах, а потом они кончились, и свободного времени не осталось.
• Лень. Если честно, заполнять базу данных рецептами довольно муторно, поэтому со временем мы снова перешли на доставку готовых рационов.
• Странности с Supabase. На бесплатном тарифе база данных замораживается, если не пользоваться ей неделю. Потом можно опять активировать, но я думаю перейти на Nitra, чтобы ни от кого не зависеть.
• Уход от плана. В какой-то момент я настолько вошла во вкус, что забыла про свои схемы и черновики. В итоге актуальная версия приложения очень отличается от той, что была запланирована.

Планы на будущее

Сейчас приложение на этапе MVP, но есть много идей, куда и как его можно развивать. Вот что точно хочу сделать в будущем:

• Общий список покупок. Чтобы там были не только продукты, но и другие вещи. Думаю, будет логично хранить всё в одном месте.
• Генерация меню на несколько дней. Это упростит процесс покупок, и не придётся лишний раз ходить в магазин.
• Внесение блюда в базу данных через интерфейс. Надеюсь, это решит мою проблему с ленью, и я найду силы и время добавить в приложение все рецепты.
• Тёмная тема. Она уже готова, нужно просто подключить.

Ещё думаю над тем, чтобы вывести приложение в паблик и дать возможность всем желающим подключить свою базу данных. С open-source всё сложнее — пока не настолько доверяю людям, чтобы дать им возможность решать, что будет у меня на завтрак 🙂

Зачем делать пет-проект

Пет-проект — это классный способ прокачать свои навыки. Если у вас тоже есть своя задумка, рекомендую не откладывать её в долгий ящик. С помощью пет-проекта вы можете:

• Решить свою актуальную проблему, как это сделала я. С одной стороны — сняла головную боль с придумыванием блюд, с другой — вернулась к любимому реакту.
• Поработать с новыми технологиями, которые хочется пощупать, но нет возможности в основном проекте.
• Попробовать себя в новых ролях. Если на работе вы только разработчик, то здесь одновременно аналитик, архитектор, проджект-менеджер, тестировщик и дизайнер;
• Пополнить резюме. Новый опыт и технологии точно пригодятся на собеседованиях.

Как решаете проблемы с производительностью и масштабируемостью? Было бы здорово услышать реальные кейсы.

Несмотря на то, что популярность библиотеки Redux уже стихла, она идеально подходит для разбора примеров по двум причинам: во-первых, многие знакомы с этой библиотекой, а во-вторых, код, который создаётся вокруг этой библиотеки, можно упростить и сделать читабельнее.

Абстракции

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

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

Создание редьюсера подобно оглавлению книги: оно позволяет быстро найти необходимую функцию по типу экшена. Функции, такие как signIn и signOut, иллюстрируют преобразования состояния объекта: они принимают на вход полезную нагрузку и текущее состояние объекта. Второстепенный код, включающий проверку типов экшена, вызов нужной функции и прочее, скрыты за функциями createReducer и on.

Для удобства мы добавим вспомогательные функции useAction и useStore:

Линзы

В функциональном программировании, линзы – это абстракции, которые позволяют работать с вложенными структурами данных, такими как объекты или массивы. Проще говоря это иммутабельные сеттеры и геттеры. Эти функции называются линзами, потому что они позволяют сфокусироваться на значении определенной ветки объекта:

Для начало давайте взглянем как обновляется значение объекта без линз:

:

Ниже представлена реализация линз. Обратите внимание, что все эти функции уже существуют в библиотеке Ramda:

Каррированные функции

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

Можно написать функцию curry, которая позволит преобразовать любую функцию в каррированную и позволит вызывать её с разным количеством параметров:

Ниже приведена реализация и пример ее использования.

Я часто замечаю, что многие разработчики по какой-то причине оборачивают callback функции в анонимные, только чтобы передать параметр.

Вместо этого просто нужно передать функцию в качестве параметра. Однако стоит помнить, что функция then ожидает колбэк-функцию с двумя параметрами. Поэтому прямая передача будет безопасной только если setUsers ожидает только один параметр.

Это напоминает мне сокращение дробей или уравнения из школьной алгебры.

Предлагаю сократить функцию updateCity:

Можно сразу вставить функцию в редюсер без объявления переменной:

Но самое главное, теперь функцию set можно включить в композицию и выполнять несколько обновлений:

Такой стиль программирования называется комбинаторным (point free) и широко используется в функциональном программировании.

Эта статья получилась немного длиннее, чем планировалось, но я надеюсь, что вы узнали что-то новое для себя. В следующей статье мы представим конструкцию try/catch в виде функции. И, как обычно, небольшой тизер к следующему посту:

В статье я не буду описывать создание стилей, а с полным кодом приложения вы можете ознакомиться в репозитории проекта.

Задачи

1. У пользователей должна быть возможность выбирать количество предложений
2. Текст необходимо получать из внешнего API;
3. Применение соответствующих стилей для правильного и неправильного символа;
4. Подсветка текущего символа;
5. Приложение должно вычислять и отображать скорость и точность печати текста пользователем;
6. Пользователи должны иметь возможность перезапустить текущий тест.

Настройка проекта

Создадим React проект с TypeScript шаблоном, выполнив в терминале следующую команду: npx create-react-app typing-test-app --template typescript.

После завершения установки, перейдем в директорию проекта, установим axios (npm install axios) и Redux Toolkit (npm install @reduxjs/toolkit react-redux).

Удалим все файлы, которые нам не пригодятся (оставим index.tsx, App.tsx, index.css, react-app-env.d.ts). Создадим папки api, assets, components, helpers, redux, types и style. Файл index.css переместим в папку style.

Отредактируем оставшиеся файлы.

Файл index.tsx:

Файл App.tsx:

Приложение мы пишем на TypeScript, поэтому для функциональных компонентов желательно указывать тип FunctionComponent, который мы импортируем из React.

Header и Footer

В папке components создаем папку ui, в которой создадим два компонента Header и Footer. В Header, импортируем логотип и стили. Возвращать будем

В Footer импортируем стили и возвращаем

Импортируем созданные компоненты в App.tsx.

Создание базовых компонентов

В папке components создадим компонент Test, пока что этот компонент будет отображать только слово ‘Test’.

В папке ui создадим компонент Button. Импортируем встроенный тип ComponentPropsWithoutRef, с помощью него мы сможем получить все атрибуты, которые есть у элемента и использовать эти атрибуты внутри нашего компонента в качестве props.

Там же создаем компонент ModalWindow. В этот компонент мы будем передавать текст для заголовка окна и необходимые элементы в качестве children.

НастройкаRedux Toolkit

Перед тем как использовать созданные компоненты в проекте, мы создадим состояние для теста. Для этого воспользуемся Redux Toolkit.

В папке redux, создадим папку store, в которой создадим файл testSlice. Опишем тип для состояния теста. Для isTestStarted и isTestFinished, мы зададим тип boolean, а sentences будет string. Начальным состоянием isTestStarted и isTestFinished установим false, а sentences будет строкой с цифрой 4.

Далее, с помощью метода createSlice создадим слайс для нашего приложения. У нас будет четыре редюсера, по одному для работы с каждым отдельным состоянием и один общий, для сброса состояния теста к исходным значениям. Для типизации action.payload воспользуемся встроенным типом PayloadAction, которому в качестве дженерика будем передавать необходимый тип.

Далее, в папке store создаем одноименный файл и в нем опишем store нашего приложения. Редюсер у нас пока один, импортируем его из файла testSlice.

Экспортируем созданный store, и так как мы используем TypeScript, необходимо создать и экспортировать дополнительные типы. Они понадобятся для работы с Redux хуками. Для RootState воспользуемся встроенной TypeScript утилитой – ReturnType, которая будет принимать определение типа метода getState, а возвращать тип возвращаемого getState значения. Для определения типа AppDispatch воспользуемся оператором typeof.

В папке redux создадим файл hooks, импортируем в него созданные типы. И создаем два кастомных хука: useAppDispatch и useAppSelector. Создание этих хуков подробно описано в документации Redux Toolkit, это просто типизированные версии встроенных Redux хуков useDispatch и useSelector.

В файле index.tsx. Обернем компонент App в Provider. В Provider передадим созданный store.

Откроем файл App, импортируем в него созданные хуки, функции setIsTestStarted и setSentences, и компоненты Button и ModalWindow.

Создадим функцию testStateToggler, внутри которой будем изменять состояние isTestStarted на true, тем самым запуская тест.

В блок

Теперь изначально будет отображаться компонент ModalWindow, а при нажатии на кнопку Start, появится компонент Test.

Работа с текстом

Для получения текста используем https://baconipsum.com/json-api/. В папке api создадим файл getText, который будет содержать асинхронную функцию. Внутри этой функции мы с помощью axios отправляем GET запрос на сервер и возвращаем ответ, в нашем случае в ответ на запрос мы ожидаем получить строку с текстом. В качестве аргумента функция getText будет принимать количество запрашиваемых предложений. Остальные параметры запроса берем из документации baconipsum

Теперь опишем тип для массива символов. В папке types создадим одноименный файл. Массив будет состоять из объектов с двумя свойствами: сам символ и css – класс.

Для работы с текстом создадим отдельный слайс, перейдем в папку redux/store и создадим там файл textSlice. Импортируем в него TextType и функцию getText. Для выполнения асинхронного запроса нам понадобится метод createAsyncThunk, импортируем его из redux toolkit.

Начнем с описания типа, здесь нам понадобится сам массив символов – text, состояние загрузки текста – isLoading, возможные ошибки загрузки – error, также нам нужно следить за индексом текущего символа – currentCharIndex, считать количество ошибок – mistakes и общее количество нажатий – pressingCount.

Далее, используя метод createAsyncThunk, создаем функцию fetchText. Для типизации createAsyncThunk используем дженерик, в который мы передадим три параметра. Первым параметром будет string, т.к. мы ожидаем, что функция вернет нам строку, вторым параметром также будет string, т.к. именно строку мы будем передавать функции колбэку и третьим параметром укажем rejectValue, он нам понадобится для обработки ошибок.

В сам метод createAsyncThunk мы передаем имя для action и асинхронную функцию для получения текста. Внутри этой асинхронной функции воспользуемся ранее созданной функцией getText, в которую передадим количество запрашиваемых предложений. В случае успеха будем возвращать response.data, в случае ошибки вернем встроенную функцию rejectWithValue с сообщением об ошибке.

В объекте reducers опишем редюсеры для работы с состоянием текста. setText для изменения массива с текстом, setCurrentCharIndex и setMistakes для изменения индекса текущего символа и количества ошибок соответственно, increasePressingCount для подсчета количества нажатий и resetTextState для сброса состояния к начальным значениям.

В extraReducers будем обрабатывать action для функции fetchText. Во время загрузки изменяем состояние isLoading на true и обнулять error. При успешном получении данных будем разбивать полученную строку на символы и формировать массив объектов, который сохраним в text. Для символа с индексом 0 сразу будем устанавливать класс ‘current-char’. В случае ошибки будем присваивать в error сообщение об ошибке.

Импортируем textSlice в наш store.

Для стилизации символов нам необходимо создать две функции. Первая будет стилизовать текущий символ, а вторая будет сверять нажатую клавишу с текущим символом и применять необходимый стиль, правильного или неправильного символа.

В папке helpers создадим файл charTransform. Начнем с функции getCurrentChar, на вход она будет принимать массив типа TextType и индекс текущего элемента, а возвращать новый массив типа TextType. Внутри самой функции будем перебирать входной массив и сравнивать индекс элемента массива с индексом текущего элемента, если индексы равны, то возвращаем элемент с классом current-char.

Теперь создадим функцию compareChars, на вход она будет принимать массив типа TextType, индекс текущего элемента, количество ошибок и нажатую клавишу, возвращать будет новый массив типа TextType, новый индекс текущего элемента и новое количество ошибок. Внутри функции делаем примерно тоже самое, проходим по массиву, сравниваем индексы и проверяем, правильно ли нажата клавиша.

Далее, в папке components создадим компонент Text. Импортируем в него функции getCurrentChar и compareChars. Из textSlice импортируем функции fetchText, setText, setCurrentCharIndex, increasePressingCount и setMistakes.

Для получения текста, внутри хука useEffect будем вызывать функцию fetchText. В которую будем передавать переменную sentences.

Добавим еще один useEffect, в котором при изменении индекса текущего символа, будем вызывать функцию getCurrentChar и изменять текст.

Для обработки нажатия клавиш также используем useEffect. Внутри будем сравнивать currentCharIndex с длиной текста и если currentCharIndex меньше, то используя конструкцию Function Expression, создаем функцию обработчик. В этой функции будем вызывать функцию compareChars, и обновлять текст, индекс текущего символа, количество ошибок и количество нажатий.

В этом компоненте мы используем условный рендеринг. Если есть ошибка, будем выводить на экран значение переменной error, если идет загрузка, будем отображать параграф с текстом «Loading text…», а когда текст загружен, будем выводить его на экран.

Импортируем созданный компонент Text в компонент Test.

Подсчет скорости и точности печати

Для подсчета скорости печати нам потребуется таймер. В папке redux/store создадим файл timerSlice. Начальным состоянием будет выключенный таймер и количество секунд равное 0. Также будет три редюсера, для изменения состояния таймера, увеличения секунд на 1 и обнуления секунд.

Импортируем timerSlice в наш store.

Теперь нам необходимо добавить включение и выключение таймера в компонент Text. Перед созданием обработчика нажатия клавиш, будем проверять количество нажатий и при первом нажатии запускать таймер. Внутри функции keyPressHandler будем проверять новое значение индекса текущего символа, и если оно равно длине текста, то будем выключать таймер и устанавливать состояние isTestFinished в значение true.

Далее создадим функции подсчета скорости и точности печати. Для этого в папке helpers создадим файл statsCounting, и в нем создадим две эти функции.

Функция accuracyCounting будет принимать количество ошибок и общее количество нажатий, а возвращать процент правильно нажатых клавиш. Так как общее количество нажатий может быть равно нулю, необходимо это проверить.

Функция speedCounting принимает количество правильных символов и количество секунд. Возвращает скорость печати (количество слов в минуту). Для вычисления скорости необходимо перевести секунды в минуты, а количество правильных символов в количество слов (обычно подобные приложения берут среднюю длину слов равную пяти символам). Секунды могут быть равны нулю, поэтому их также необходимо проверить.

Теперь в папке components создадим компонент Stats, который будем использовать для отображения статистики. Импортируем в него функции speedCounting, accuracyCounting и increaseSeconds. В качестве props этот компонент будет принимать только необязательных children.

Создадим состояние для скорости и точности, а ошибки, нажатия, секунды и состояние таймера будем брать из глобального состояния. Воспользуемся хуком useEffect и при изменении количества ошибок, нажатий или секунд, будем вызывать функции speedCounting и accuracyCounting и устанавливать результаты вызова этих функции в соответствующее состояние.

Добавим еще один useEffect, в котором будем проверять, включен ли таймер, и если включен, то будем увеличивать количество секунд.

Импортируем созданный компонент в компонент Test.

Завершение теста

В файле charTransform создадим еще одну функцию, она будет приводить массив с текстом в изначальное состояние. Принимать и возвращать она будет массив типа TextType. Внутри функции будем перебирать массив и устанавливать пустую строку в значение поля class вложенных объектов. Для объекта под индексом 0 class установим ‘current-char’.

В компоненте Test создадим две функции, для перезапуска и для начала нового теста. Добавим условный рендеринг, если isTestFinished – true, то будем отображать компонент ModalWindow со статистикой и двумя кнопками, Restart и New Test. Также в первый компонент Stats добавим кнопку перезапуска теста. Так как после нажатия кнопки, фокус остается на ней, нужно его принудительно снять, если этого не сделать, то при нажатии пробела во время печати кнопка будет срабатывать.

Выбор количества предложений

Последнее, что осталось сделать – это добавить возможность выбирать количество предложений. Для этого в папке components/ui создадим компонент Select.

Тут нам также, как и в компоненте Button потребуется тип ComponentPropsWithoutRef, чтобы мы могли получить все атрибуты элемента select. В качестве props компонент будет принимать значение по умолчанию и массив значений. Возвращать будет один элемент select.

Теперь перейдем в App и добавим созданный компонент Select в отрисовку ModalWindow. В качестве defaultValue будем передавать состояние sentences, для options создадим небольшой массив объектов с двумя полями value и name, а при событии onChange будем изменять значение sentences.

Приложение работает и полностью готово.

Заключение

Репозиторий проекта и Live. Буду рад вашим комментариям и советам. С радостью отвечу на любые вопросы!

Ошибка 1. Нет четких границ между слоями приложения

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

Можно выделить три базовых уровня:

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

Например, в FastAPI проще начать с хэндлеров, которые сразу ходят в SQLAlchemy-модель. Но если сразу заложить сервисный слой, расчёты комиссий и проверку бизнес-правил можно будет тестировать изолированно, не поднимая всю API. Слой репозиториев позволяет в будущем легко заменить Postgres на другую базу или добавить кэш, не переписывая логику приложения.

Чёткое разделение позволяет быстро находить, где живёт бизнес-логика, где происходит доступ к данным и куда добавлять новые фичи. Продукт растёт, а код остается предсказуемым, удобным для изменений и масштабирования.

Ошибка 2. Игнор масштабирования с первого дня

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

Важно сразу закладывать в архитектуру точки роста, даже если пока они не нужны на каждый день.

Например:

• Добавить очереди и фоновые задачи через Celery или RQ, если есть риск появления тяжёлых операций (генерация отчётов, массовая рассылка).
• Разносить чтение и запись: даже простое разделение на эндпоинты, где читающие операции не блокируются длительными транзакциями, уже помогает при росте нагрузки.
• Придумать, как кэшировать самые тяжелые запросы: например, использовать Redis, чтобы хранить агрегированные данные, а не считать их каждый раз.
• Закладывать возможность горизонтального масштабирования: не привязывать логику к локальному состоянию приложения, использовать хранилище с возможностью разделения нагрузки, не писать монолит, который нельзя будет разбить на части при росте.

На практике проект растёт быстрее, чем кажется. Сначала в API добавляется массовая выгрузка CSV, потом приходят интеграции с другими сервисами, а затем накатывается нагрузка от новых пользователей. Если архитектура не подготовлена, команде приходится ставить костыли, переписывать эндпоинты под фоновые задачи или внедрять кэш в экстренном порядке, исправляя баги в проде.

Закладывая масштабирование в архитектуру с первого дня, команда экономит себе месяцы переработок и спасается от бесконечных хотфиксов. Это инвестиция, которая позволяет команде развивать продукт спокойно.

Ошибка 3. Преждевременное усложнение архитектуры

Многие разработчики боятся, что проект не выдержит нагрузку, поэтому с самого старта закладывают сложные паттерны, микросервисы, брокеры событий и сразу три уровня кэширования. Но пока в системе нет ни пользователей, ни подтверждённой бизнес-модели, такие решения снижают скорость разработки и приводят к куче багов.

Рядовой пример — проект сразу запускается на Kubernetes с несколькими сервисами, которые обмениваются сообщениями через Kafka. В реальности такие проекты вначале требуют десятков часов на поддержание инфраструктуры, а баги приходится искать сразу в нескольких сервисах, между которыми гуляют события. При этом единственная реальная задача в начале — быстро проверить гипотезы и получить первых пользователей.

Упрощённая архитектура на старте позволяет команде сосредоточиться на продукте: монолит с чёткими слоями (контроллеры, сервисы, репозитории) куда быстрее дорабатывается и легче деплоится, чем микросервисы с отдельными контурами.

Что можно делать:

• Запускать монолит на FastAPI или Django, а не дробить на микросервисы до появления реальных узких мест.
• Использовать Postgres без брокеров событий, пока не появятся требования к масштабированию.
• Добавлять кэш Redis точечно, когда видна реальная нагрузка, а не вслепую кэшировать каждый запрос.

Сложные архитектуры требуют времени на поддержку и экспертизу, чтобы не допустить критичных ошибок (например, потерю событий в брокере или гонки данных между сервисами). Поэтому вложения в сложную архитектуру оправданы, когда проект достигает уровня, где без этого уже не обойтись.

Если команда делает стартап или MVP, преждевременное усложнение архитектуры только тормозит развитие продукта. Гораздо эффективнее заложить возможности для масштабирования (очереди, фоновые задачи, кэш), но держать архитектуру простой до тех пор, пока проект не начнёт расти и не появятся реальные вещи, требующие изменений.

Ошибка 4. Непродуманная работа с зависимостями

В начале проекта обычно кажется, что зависимости — это просто. Но со временем проект разрастается, зависимости множатся, версии начинают конфликтовать, а обновление одной библиотеки ломает другую.

Эта ошибка обычно проявляется в нескольких местах. Например, в проект могут без разбора ставиться зависимости про запас или ради одной строчки удобной функции, хотя можно обойтись стандартной библиотекой. Ещё одна частая проблема — зависимости фиксируются слишком жестко, что не дает обновляться безопасно, или наоборот, версии не фиксируются вовсе, и проект начинает падать после автоматического обновления библиотек.

Чтобы избежать проблем, важно с самого начала заложить порядок в работе с зависимостями:

• Использовать инструмент управления зависимостями, который позволяет контролировать версии и изолировать окружения.
• Разделять зависимости для разработки и продакшена.
• Периодически обновлять зависимости, чтобы не закапываться в старые версии, но делать это контролируемо и с прогоном тестов.

Например, при работе с Python удобным подходом будет использование Poetry: можно зафиксировать версии зависимостей в pyproject.toml, автоматически создавать lock-файл, следить за актуальностью библиотек и легко пересоздавать окружение. Если проект запускается на CI/CD, можно установить точные версии и сразу выявить, где обновление ломает тесты.

В длинных проектах непродуманная работа с зависимостями множится в геометрической прогрессии. Любой новый разработчик тратит время на настройку окружения, зависимости конфликтуют, часть библиотек остаётся неиспользованной. Порядок с зависимостями экономит часы и дни, снижает риск падений в проде и влияет на развитие проекта.

Ошибка 5. Нет стратегии управления состоянием

Состояние — это данные, которые хранятся между запросами или действиями пользователя: корзина, прогресс пользователя, кэшированные результаты запроса, состояние WebSocket-подключений. Если не продумать, как эти данные хранятся, обновляются и синхронизируются, приложение быстро начинает вести себя непредсказуемо.

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

Чтобы избежать хаоса, управление состоянием нужно продумать заранее:

• Выяснить, какие данные должны храниться между запросами и как долго.
• Решить, где хранить состояние: в базе данных, Redis, сторонних сервисах.
• Сразу заложить сериализацию и валидацию состояния, чтобы избежать рассинхронизации форматов.

Например, хранение кэша в памяти может подойти для небольших проектов, но если приложение начинает горизонтально масштабироваться, лучше вынести кэш в Redis, чтобы все инстансы работали с единым источником. Для сессий пользователей можно использовать JWT, если нужно масштабирование без общего состояния, или централизованное хранилище сессий, если требуется возможность их отзыва.

При работе с фронтендом стратегия управления состоянием не менее важна. Например, при использовании React или Vue проект может сначала обходиться локальным состоянием компонентов, но при росте сложности приложение начинает сыпаться из-за рассинхрона между компонентами. Важно заранее заложить подход с централизованным состоянием, а также понять, какие данные держать в состоянии клиента, а какие запрашивать заново.

Без стратегии управления состоянием проект становится сложным в отладке и поддержке. Грамотное управление состоянием ускоряет разработку и снижает количество багов в будущем.

А какие ошибки допускаете вы? Делитесь в комментариях или в тг-канале Веб-страница.

Мир изменился. Я чувствую это в воде. Чувствую в земле. Ощущаю в воздухе. Многое из того, что было, ушло. И не осталось тех, кто помнит.Всё началось с generic аргументов…

Один был добавлен для состояния, бессмертного и самого мудрого

Используя некоторые базовые типы из redux, мы можем типизировать большую часть аргументов:

Правда, сейчас вся польза, которую мы получили — это тип значения, возвращаемого из store.getState(). Хочу обратить внимание, что тут необходимо использовать именно MiddlewareAPI, но не Store, так как в мидлвари передаётся не весь интерфейс: replaceReducer и subscribe опускаются.

Сразу же мы можем прокинуть этот тип в createStateChangedBy:

При этом нам категорически без разницы, что именно возвращает селектор. Главное, чтобы он принимал конкретное состояние, что мы и обозначаем в типах.

В целом, такая типизация позволяет нам проверять, что обработчики, переданные в мидлварь, ожидают работать с одним и тем же состоянием.

Другой — отдан контексту, великому доставщику утилит без создания циклических зависимостей

Его типизировать, на самом деле, несложно. Единственное ограничение, которое хочется добавить: пусть это будет словарь. Чтобы было ясно, что там лежит:

И вот тут начинается первая магия (я имею в виду undefined as Context). Дело в том, что какой-нибудь абстрактный юзер может явно передать в Context какой-нибудь тип, но при этом опустить второй аргумент функции. И, если переданный тип будет несовместим с undefined, мы окажемся у разбитого корыта с некорректной типизацией. Однако TS прекрасно выводит типы самостоятельно, поэтому если передать хотя бы один явно типизированный обработчик, то типы для состояния и контекста выведутся корректно.

Я говорю всё это к тому, что при вызове createYam не нужно явно указывать значения generic-параметров. Да и вообще при работе с TS мы скорее хотим этого не делать, нежели наоборот. На моём опыте, автоматическое выведение всегда работает более качественно (и более гибко).

А ещё, ещё один тип был сделан для обработчиков, которые больше всего жаждали власти (над побочными эффектами)

Основная часть, которая подвержена типизации — это аргумент. Помимо состояния и контекста, которые мы ввели ранее, он также будет зависеть от действия. Ведь это так прекрасно, когда в createYamHandler мы сопоставляем друг другу действие и обработчик и точно знаем тип действия, который в этом обработчике нужно ожидать. Поэтому тип будет выглядеть так:

Таким образом типизировать обработчик не составляет труда:

Для внутренней типизации нам также пригодится тип самого обработчика:

Из всех аргументов обязательным является только тип состояния. Context может не использоваться, а действие, передаваемое обработчику, строго говоря, может быть любым. Поэтому такой набор аргументов кажется мне оптимальным.

И прежде чем добавить типы в createYam, нам осталось типизировать ещё одно место, связанное с обработчиками: инъекции. Чтобы грамотно разграничить типы действий, используемых внутри createYam, пришлось добавить ещё немного магии:

Использование type guards будет необходимо, потому что проверка action.type === handlerRequiredType на переменной типа AnyAction | ReturnType<typeof handlerRequired> никоим образом не может сузить тип до ReturnType<typeof handlerRequired>. Это связано с тем, что AnyAction также может иметь в качестве своего типа созданный нами символ, а мы не делаем никаких дополнительных проверок, чтобы это предотвратить.

Иными словами, совпадение action.type ещё не означает, что это обязательно нечто, что мы вернули из handlerRequired. Однако не будет же пользователь доставать из глубин библиотеки этот символ для создания действия, которое всё сломает. Не будет ведь?

Ну да ладно. В итоге получаем красиво типизированную мидлварь:

Единственный момент, который мне не удалось решить — это, так сказать, истинная опциональность контекста. Если вы передаёте контекст в мидлварь, все обработчики должны быть типизированы так, будто его ожидают (даже если не используют). Не получится опустить второй generic аргумент в HandlerArg, иначе createYam не примет такой обработчик, неправильно выведя тип. В целом, это не такая большая трагедия, ведь можно завести локальный тип: type AppHandlerArg = HandlerArg<AppState, AppYamContext> и использовать в обработчиках его, с уже подставленными состоянием и контекстом.

Но был сделан ещё один тип, подчинявший себе все другие

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

И начну я с одной большой проблемы, которая начала вызвать у меня боль ещё при попытке организовать типизацию для function createReducer(Record<ActionType, Reducer>): Reducer: невозможно в общем типизировать значения объекта в зависимости от ключа. Ну нельзя, и всё тут. Если бы я заранее написал конкретный объект: да, пожалуйста, TS их видит. Но при попытке обобщить всё просто перестаёт работать. Возможно, в будущем TS предоставит нам для этого какой-то интерфейс, но сейчас его просто нет.

Но ведь это смотрится странно. Если я говорю, что обработчик будет реагировать на конкретное действие, почему же в самом указанном обработчике действие всё ещё может быть любым? Я об этом:

Однако если посмотреть на этот код, становится понятно, что нет возможности сопоставить testAction и какую-то рандомную строку 'test', которая, оказывается, соответствует значению свойства у объекта, возвращаемого из функции, которая объявлена на игле, которая в яйце, которое в утке, которая… думаю, вы поняли.

Сомневаться в разумности команды, занимающейся поддержкой TS, смысла нет, запрос на подобную типизацию — из разряда неадекватных. Но и пользователя можно понять: я точно знаю, какое действие я хочу ожидать в обработчике, и не хотел бы явно писать его дважды.

К счастью, я не первый, кто добрался до этой проблемы, поэтому у меня было, на что опереться: те же ребята, написавшие Redux ToolKit, прекрасно справились с задачей. Если вкратце, то суть такова: мы не можем типизировать пару ключ-значение в объекте, но мы можем типизировать функцию, принимающую два аргумента! Дальше всё ограничивается только вашей фантазией. RTK выбрал путь строителя:

Тут происходит две важные вещи:

1. В соответствие кейсу ставится уже не тип в виде строки, но целый `actionCreator`.
2. Он содержит в себе не только строку action.type, по которой можно делать условный switch в редьюсере, но и тип для остальных полей в этом действии, который можно явно использовать в функции, переданной вторым аргументом.

Если очень грубо, тип получается примерно таким:

Как правило, в подобных решениях при создании actionCreator к функции также добавляется поле type, возвращающее строку, с которой это действие было создано, поэтому по сути мы имеем фабрику и константу для строки типа в одном лице:

Лично мне больше понравился формат, использованный в другой библиотеке, под названием deox. Она делает ровно то же самое, но имеет, на мой взгляд, более приятный интерфейс для редьюсеров:

Так что для реализации подобной типизации в yam я решил взять вариант с handle за основу.

Давайте начнём работу над createYamHandler. Для начала нам придётся разобраться с аргументом. Раньше он принимал только словарь, где типу сопоставлялся обработчик, теперь же он может принимать ещё и функцию. Высокоуровнево это выглядит так:

Здесь появляется некий map builder, из которого мы можем создать нужный нам словарь, да так типизированный (builder, то есть), чтобы для пользователя, создающего пары из actionCreatorов и обработчиков, правильно подставлялись типы действий.

Сам строитель имеет такой тип:

Как можно видеть в примере из deox, это некая функция, принимающая волшебный handle и возвращающая нечто, что поможет нам построить наш словарь. Тип возвращаемого значения — деталь чисто внутренняя, поэтому я выбрал [string, Handler] пары как самый простой и прямолинейный вариант (на мой взгляд). Сам же callback содержит в себе основную магическую магию, добавляя индивидуальный generic аргумент для каждого вызова:

На этом этапе уже может начать становиться страшно, поэтому давайте разберёмся по порядку:

1. State и Context — уже привычные нам generic аргументы, которые мы добавили в самом начале; здесь они передаются извне.
2. ActionCreator — generic аргумент, который можно явно передать функции при вызове или дать TS самому его вывести; главное, что на каждом вызове он может быть разным, в отличие от State и Context.
3. ActionCreator, вообще говоря, может быть любой функцией, возвращающей AnyAction aka { type: extends string; [key: string]: any }, но в аргументе мы также говорим, что нам важно, чтобы эта функция имела на себе свойство type, соответствующее типу возвращаемого действия.
4. Второй аргумент — это обработчик, в тип которого мы в первый (и единственный) раз передали третий generic аргумент: тип обрабатываемого действия.
5. Возвращаем мы пары тип/обработчик, из которых мы потом будем собирать словарь.

Это крайне интересный пример типизации, до которого я, наверное, сам никогда и не догадался бы, если не столкнулся бы с такой проблемой, но работает он на ура. Единственное, что в нашем примере осталось неопределённым, это createHandlerMap. Он вроде бы и простой концептуально, но вот там над TS придётся немного поглумиться, потому что он либо слишком умный, либо недостаточно — я так и не понял.

Самое страшное место здесь, которого, как я понимаю, невозможно избежать — это handler as Handler<State, Context>. Сперва мы доказываем TS, что наш обработчик работает над одним конкретным действием, а потом такие «нет, знаешь, вообще-то над любым».

Возможно, виной тому необходимость вернуться к Record<string, Handler>, который оставляет эту связь между типами только в run-time. Но без такого преобразования пользователь будет получать ошибку типа «ваш обработчик, конечно, подходит к выставленному ограничению, но может быть инициализирован другим подтипом, который не совместим с вашим» (собственно, с той же ошибкой мы сталкивались при типизации контекста и установке для него значения по умолчанию).

Так что тут нам придётся сказать TS: «Я знаю, что делаю, не ругай меня, пожалуйста, мне уже есть 18». Ну а fromEntries просто не имеет нормальной типизации, так что там мы его даже не обманываем.

Собрав всё воедино, получаем такую простыню:

И эта простыня позволяет нам написать прекрасное

И каждый обработчик наверняка знает, с каким типом он будет работать.

Заключение

Вот мы и завершили типизацию очередной мидлвари для redux. Найти репозиторий с полным кодом можно здесь.

В ближайшее время я постараюсь подготовить ещё одну статью, в которой соберу различные лайфхаки по использованию библиотеки. Потому что инструмент достаточно свободный, и сделать можно практически всё что угодно (и мы с вами прекрасно знаем, что на инфраструктуре redux это отразилось не лучшим образом), поэтому как-то направить рвения народа лишним не будет.

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

Слушай внимательнее

В прошлой статье вы видели пример обработчика, реагирующего на изменение параметров поиска:

Долгое время наш код жил примерно в таком формате. Однако на практике оказалось, что стоит сделать иначе.

На панели с фильтрами было несколько разных виджетов: обычный с чекбоксами, виджет с ценами (и полями ввода для произвольных диапазонов), виджет для выбора цвета — перечислять можно долго. И у каждого из этих виджетов была своя логика обработки, которая, в том числе, могла привести к выбору значения, совпадающего с предыдущим (и зачем нам тогда ходить на сервер?).

В изначальной реализации был волшебный requestBuilder, который использовался в компонентах и создавал новый набор фильтров, попадавший потом в состояние. Но со временем я понял, что это не совсем redux way. Лучше завести набор действий типа filters/checkbox:changed, filters/ranged:changed, filters/color:changed и так далее. Я не буду углубляться в детали реализации, но набралось их порядка десятка. И код обработки изменений фильтров действительно стал гораздо более приятным, но мне очень не хотелось явно перечислять все эти действия в обработчике, ходящем к серверу.

Более того, перед отправкой запроса происходило сравнение нового запроса с предыдущим, который хранился… в URL! Ох уж этот легаси код, так я его и не вылечил. Но в этот момент стало ясно, что слушаю я не столько действия, сколько изменения состояния. Потом до меня дошло, что можно использовать эту концепцию ещё и для сохранения состояния, будь то location.search или localStorage. Поэтому, помимо реакции на определённые действия, я решил добавить возможность реагировать на изменение состояния. И выглядело это примерно так:

Сравнение фильтров делается по ссылке, поэтому важно обеспечить, чтобы селекторы правильно отслеживали неизменность. При грамотной организации состояния и использовании reselect (тут) это не так уж и сложно сделать. Я реализовывал подобную логику даже для сложных структур (массивы объектов, которые можно сравнить по ключу вместо глубокого равенства, например), но это лежит за пределами текущей темы. Поэтому предположим, что селекторы работают правильно и возвращают нам тот же самый объект, если он по сути своей не изменился.

Единственная проблема, которая остаётся — это мемоизация. Если вы не знакомы с reselectом, опишу в двух словах: создаваемые селекторы кэшируют предыдущее вычисленное значение, и если входные данные не изменились, то и создавать новый результат нам не придётся.

Но по умолчанию размер кэша у этих селекторов равен единице, то есть как только на вход поступают новые данные, предыдущий результат выбрасывается. И что тогда? А то, что если несколько обработчиков используют фильтры (например, один для отправки запросов, второй — для записи их в location.search), первый вызванный обработчик собьёт кэш, и второй уже не сможет корректно отработать.

Можно было бы, кончено, поиграться с кэшированием используемых селекторов, но я нашёл гораздо более элегантное решение, не требующее какой-то особой магии от разработчика, использующего yam.

Вместо явного вычисления и сравнения прошлого и текущего состояний можно предоставить разработчику функцию, которая будет делать это сама:

Так давайте напишем свою собственную кэширующую магию, чтобы не сломать селекторы:

Теперь на одном вызове dispatch мы вызываем каждый селектор только два раза: один раз со старым состоянием и один раз с новым.

Есть лишь один недостаток, который мне так и не удалось победить. Предположим, у нас есть два зависимых кэширующих селектора:

Если в обработчике будет использовано stateChangedBy(selectRangeFilters), это собьёт кэш для selectFilters, так как он неявно вызовется с новым состоянием. Это ломает изолированность обработчиков и всю логику сравнения, но я так и не смог понять, насколько это распространённый сценарий, поэтому чинить не стал. Однако это надо иметь в виду. И либо иначе организовывать селекторы (например, убирая мемоизацию там, где она не нужна), либо колдовать с множественным кэшированием для селекторов типа selectFilters.

Пиши чище

Работая с такой мидлварью, я понял не только как можно её использовать, но и как её использовать не стоит.

Один из обработчиков содержал в себе крайне много условий и разных по своей природе эффектов. Читать этот код было практически невозможно, а с тестами всё было на порядок хуже. Огромное количество проверяемых кейсов, куча expect(dispatch).toBeCalledWith(action) и страшных моков на всё, что только можно. Много времени было потрачено на обдумывание и обсуждение способов упрощения этого обработчика.

Первая идея заключалась в том, чтобы разбить этот обработчик на несколько (разделение обязанностей, внезапно). Изначально это не было сделано из-за того, что пришлось бы дублировать некоторые проверки. Но, глядя на получившегося франкенштейна, я понял, что лучше написать одинаковый if в двух-трёх местах, чем это. И решение о разделении было принято. Но такое обсуждение натолкнуло меня на ещё более интересную мысль.

В моих обработчиках каждая ветка кода приводила к нескольким диспатчам, но, если делить их по зонам ответственности, в каждой из них был только один результат (и это правильно). И, в целом, это звучало как хорошая концепция: «В результате побочного эффекта мы можем получить одно дополнительное событие». Хочу обратить внимание, что не действие, а событие.

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

Таким образом мы не только добавили поддержку новомодных слов async/await, но и сделали обработчики проще в плане тестирования, а также ввели ограничение на написание чистых эффектов. Хотя бы касательно изменений состояния. Если эффекты касаются других хранилищ, увы, вызывать (и тестировать) эффекты придётся, как раньше: expect().toBeCalled() и всё в таком духе.

Делай прививки

Ещё одна фича, которой я никогда не пользовался, но очень часто натыкался на её упоминание в сети — это инъекция отдельных обработчиков в мидлвари при определённых условиях (чаще всего, на определённых страницах или при загрузке определённых компонентов).

Я считаю, что в маленьких приложениях совершенно необязательно так заморачиваться. Достаточно поставить проверку URL в обработчике и просто выходить из него. Опыт подсказывает, что десяток-другой === на вызов dispatch будет далеко не самой большой проблемой с производительностью. Поэтому в изначальной реализации я даже не думал о подобной логике.

Однако со временем я осознал, что такая фича полезна как минимум из соображений разбиения кода и уменьшения размера бандла, ведь мы не хотим тянуть в приложение код, который, возможно, даже и не понадобится некоторым пользователям. Ну и раз уж я планирую выложить эту библиотеку в общий доступ, я решил, что инъекции — это must have.

Наверное, можно придумать десятки вариантов, как добавить обработчик. Я решил опереться на то, что в идеальном приложении всяческие изменения происходят из-за некоторых событий. Значит, и новые обработчики должны добавляться тем же способом.

С именованием было сложно, так как многословно можно сказать, что нам стал нужен некоторый обработчик и обработчик перестал быть нужным, но это слишком «многабукафф». В итоге остановился на английских required и rejected. Если у вас есть лучшие названия для этих событий, буду рад увидеть их в комментариях.

С реализацией же всё оказалось не так сложно. Вдохновлялся я add/removeEventListener, которые принимают событие и обработчик и удаляют его по строгому равенству. Тогда внутри кода мидлвари можно хранить их в обычном массиве:

Действия на добавление обработчиков волшебные, поэтому на них цепочка мидлварей прерывается. Типы объявлены через символы для пущей безопасности: вдруг кому-то понадобится завести handlerRequired действие. Или даже yam/handlerRequired — никто не застрахован. Ну и вставленные обработчики хранятся на уровне store, потому что это кажется концептуально верным, хотя если учесть, что redux строго не рекомендует использовать несколько экземпляров store на приложение, можно было бы и в корень модуля положить. В остальном же всё должно быть понятно.

Будь в контексте

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

Его можно использовать, например, для передачи HTTPClient в обработчики (как дополнительный аргумент для redux-thunk), либо же для передачи dispatch, например, на период миграции, когда обработчики не могут просто так взять и отказаться от последовательных диспатчей. Дальше вы ограничиваетесь только вашей фантазией.

Заключение

На этом этапе yam стала гораздо ближе к варианту, готовому для испытаний в реальной жизни. Она даже стала прекраснее, чем то, что я оставил на своём старом проекте. Когда-нибудь здесь появится ссылка на npm пакет, а пока я предлагаю встретиться в следующий раз, чтобы обсудить последний, но отнюдь не по важности, момент: типизацию.

В этой статье вы узнаете об этих способах подробно. В каждом из них вы научитесь добиваться двух вариантов взаимодействия:

• от родителя к наследнику;
• от наследника к родителю.

Render props / props

Один из самых простых способов передачи данных в компоненты — это props (свойства).

Что такое prop?

Как известно, разметка в компонентах рендерится так:

Это отобразится как C component

C фактически отображается в P, так как P является его родительским компонентом. Кроме того, P может отобразить C следующим образом:

P добавляет дополнительные свойства в тег элемента C. Это очень похоже на <div id="d1"> </div> в HTML, где id — это атрибут со значением “nnamdi”. Каждый элемент на самом деле является отдельным экземпляром класса HTMLElement.

Тег <div> анализируется движком рендеринга в браузере, и для каждого тега создаются экземпляры класса HTMLElement. Все теги в HTML имеют соответствующий HTMLElement:

Каждый HTML*Element выше является подклассом HTMLElement. Эти HTML*Element имеют методы и свойства, которые можно использовать для манипулирования данными и рендеринга.

В случае выше будет создан HTMLDivElement:

Имя атрибута будет установлено в объект props вот так:

и передастся классу компонента C с помощью React.

Таким образом, компонент C может получить доступ к значению name в объекте props через props.name.

React основан на JSX, поэтому разметка в P будет скомпилирована в таком виде:

Первый параметр — это элемент для рендеринга, а второй содержит атрибуты элемента (в виде объектного литерала). CreateElement возвращает литерал, содержащий первый и второй параметры.

При рендеринге React проверяет, является ли этот литерал на самом деле элементом или же классом. Если это класс, React создаёт его экземпляр, используя ключевое слово new, затем передает этот экземпляр в объект props и вызывает метод render.

Приведённый выше код показывает, что фактически делает React для рендеринга компонента или элемента.

Примечание: фрагмент выше не полный, он нужен, чтобы продемонстрировать, как компоненты получают аргумент props.

Сначала проверяется, является ли objType элементом или классом. Затем IS_ELEMENT(…) проверяет список всех элементов HTML. Если objType соответствует одному из них, то возвращается флаг true: значит objType является элементом. Если IS_ELEMENT(…) возвращает false, то, objType должен быть компонентом класса, тогда он уничтожает props и экземпляр класса из objType. Затем он создаёт новый экземпляр класса, используя ключевое слово new и передавая его в props.

Таким образом P удаётся отправить данные в C.

Но как C теперь может отправлять данные обратно в родительский класс P? Это делается с помощью render props.

Что такое render props? Это концепция, посредством которой функция может быть передана дочерним компонентам в качестве свойства (props). Строка, объект, число или массив могут быть переданы через props дочерним компонентам. Это реализовано следующим образом:

Здесь функция () => {log ("render props")} передаётся компоненту C через свойство func. Затем компонент C может ссылаться на неё через func в аргументе props. Это функция выводит render props в консоли.

Итак, теперь вы знаете, что такое render props (или свойства для рендеринга). Давайте посмотрим, как дочерние компоненты могут использовать их для связи с родительскими.

Что происходит в этом фрагменте? У компонента P метод вывода связан с его экземпляром. bind(this) говорит JS запустить функцию внутри области видимости класса, объекта или функции. Вывод здесь выполняется за пределами класса P, но он по-прежнему может ссылаться на все свойства и методы, определённые в P.

Таким образом, метод вывода передаётся в компонент класса C, чтобы получить аргумент props через свойство func.

К кнопке «Send To Parent» компонента C привязано событие onclick, необходимое для вызова метода вывода, с переданным в него аргументом props через func. Так что теперь this.props.func в C содержит метод вывода в классе P:

Предположим, кнопка «Send To Parent» нажата. Вызывается this.props.func, ссылаясь на метод вывода в P, далее вызывается сам метод вывода. В консоли будет отображено следующее:

Теперь C успешно связался со своим родителем P. Можно изменить код, чтобы C отправлял данные в P.

В этом фрагменте кода в P добавляется состояние, которое содержит свойство count. В C при нажатии кнопки «Send To Parent» генерируется случайное число и передаётся в this.props.func. Метод вывода компонента P перехватывает значение из аргумента evt и обновляет состояние count полученным значением, вызывая this.setState(…).

Как вы видите, значение P отправилось из его дочернего элемента C.

Свойство Parent можно изменить, передав функцию компоненту Child и вызвав эту функцию внутри компонента Child.

Props и render props — это одно и то же, но они имеют разные концепции. Render props в основном используется для разделения логики рендеринга между компонентами. Но в данном случае этот метод был использован для передачи данных от дочернего компонента к родительскому.

Context

Для большинства разработчиков передача props глубоко вложенным компонентам в дереве была бы утомительной. React предоставляет способ определять глобальные данные в одном месте и получать к ним доступ из любого места в приложении.

Context (контекст) как раз используется в React для обмена данными между глубоко вложенными компонентами.

В этом фрагменте есть три компонента в дереве: App -> P -> C -> Sub-C. App отображает P, P отображает C, а C отображает Sub-C, который определён как context с именем ColorContext. P заключён в ColorContext.Provider, это обеспечивает доступ к данным, определённым в ColorContext, всем дочерним компонентам P.

Дочерние компоненты могут получить доступ к данным, определённым в ColorContext, выполнив {this.context}.

Чтобы сообщить React о намерении передать context от родительского компонента остальным его дочерним элементам, нужно определить два атрибута в родительском классе:

• childContextTypes,
• getChildContext.

Чтобы извлечь контекст внутри дочернего компонента, нужно определить в нём contextTypes.

Родительский компонент определяет context, который React использует для передачи данных глобально своим дочерним элементам.

Как теперь сделать так, чтобы дочерние элементы могли передавать данные своим родителям?

Дочерние компоненты могут изменять значение context, который будет отражаться во всех вложенных компонентах, включая и родительский компонент.

React-Redux/Redux

Это своего рода “ремейк” способа Context в React. Redux — это простая библиотека управления свойствами приложения, которая позволяет легко хранить эти свойства в одном месте и изменять их из любого места.

React-Redux был создан, чтобы сделать Redux легко совместимым с приложениями React.

Поскольку состояние определяется в одном месте, родительские компоненты могут устанавливать или обновлять его значение, а дочерние могут это фиксировать: связь Родитель-Наследник.

Аналогично дочерние компоненты могут устанавливать или обновлять значение состояния в хранилище, и оно также будет фиксироваться родительскими компонентами: связь Наследник-Родитель.

В этом фрагменте создаётся центральное хранилище, в котором содержится свойство count. P может обновить это свойство и дочерний компонент C получит его. Дочерний компонент также может обновить свойство count, и родительский компонент получит его.

Они могут подключиться к центральному хранилищу, объединившись в функцию connect(...), которая возвращает компонент высшего порядка.

Заключение

В этом материале вы увидели, как происходит взаимодействие между компонентами React и какими способами можно этого достичь:

• Родитель-наследник,
• Наследник-Родитель.

В первом разделе вы увидели использование props и render props, они работают с помощью HTML-подобных атрибутов. Context использует центральное хранилище, которое родитель и потомки могут как читать, так и обновлять. React-Redux и Redux делают то же самое, что и Context, компоненты выполняют чтение/запись из центрального хранилища.

Для дальнейшего освоения React вам может быть полезен данный материал.

Библиотека Redux — это способ управления состоянием приложения. Она основана на нескольких концепциях, изучив которые, можно с лёгкостью решать проблемы с состоянием. Вы узнаете о них далее, в этом руководстве по Redux для начинающих.

Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Содержание:

• Когда нужно пользоваться Redux?
• Использование ReduxНеизменяемое дерево состоянийДействияТипы действий должны быть константамиГенераторы действийРедукторы
• Хранилище
• Поток данных

Когда нужно пользоваться Redux?

Redux идеально использовать в средних и крупных приложениях. Им стоит пользоваться только в случаях, когда невозможно управлять состоянием приложения с помощью стандартного менеджера состояний в React или любой другой библиотеке.

Простым приложениям Redux не нужен.

Использование Redux

Разберём основные концепции библиотеки Redux, которые нужно понимать начинающим.

Неизменяемое дерево состояний

В Redux общее состояние приложения представлено одним объектом JavaScript — state (состояние) или state tree (дерево состояний). Неизменяемое дерево состояний доступно только для чтения, изменить ничего напрямую нельзя. Изменения возможны только при отправке action (действия).

Действия

Действие (action) — это JavaScript-объект, который лаконично описывает суть изменения:

Единственное требование к объекту действия — это наличие свойства type, значением которого обычно является строка.

Типы действий должны быть константами

В простом приложении тип действия задаётся строкой. По мере разрастания функциональности приложения лучше переходить на константы:

и выносить действия в отдельные файлы. А затем их импортировать:

Генераторы действий

Генераторы действий (actions creators) — это функции, создающие действия.

Обычно инициируются вместе с функцией отправки действия:

Или при определении этой функции:

Редукторы

При запуске действия обязательно что-то происходит и состояние приложения изменяется. Это работа редукторов.

Что такое редуктор

Редуктор (reducer) — это чистая функция, которая вычисляет следующее состояние дерева на основании его предыдущего состояния и применяемого действия.

Чистая функция работает независимо от состояния программы и выдаёт выходное значение, принимая входное и не меняя ничего в нём и в остальной программе. Получается, что редуктор возвращает совершенно новый объект дерева состояний, которым заменяется предыдущий.

Чего не должен делать редуктор

Редуктор — это всегда чистая функция, поэтому он не должен:

• мутировать аргументы;
• мутировать состояние. Вместо этого создаётся новое состояние с помощью Object.assign({}, ...);
• иметь побочные эффекты (никаких API-вызовов с какими-либо изменениями);
• вызывать нечистые функции. Это функции, результат которых зависит от чего-то кроме их аргументов (например, Date.now() или Math.random()).

Поскольку состояние в сложных приложениях может сильно разрастаться, к каждому действию применяется не один, а сразу несколько редукторов.

Симулятор редуктора

Упрощённо базовую структуру Redux можно представить так:

Состояние

Список действий

Редуктор для каждой части состояния

Редуктор для общего состояния

Хранилище

Хранилище (store) — это объект, который:

• содержит состояние приложения;
• отображает состояние через getState();
• может обновлять состояние через dispatch();
• позволяет регистрироваться (или удаляться) в качестве слушателя изменения состояния через subscribe().

Хранилище в приложении всегда уникально. Так создаётся хранилище для приложения listManager:

Хранилище можно инициировать через серверные данные:

Функции хранилища

Получение состояния:

Обновление состояния:

Прослушивание изменений состояния:

Поток данных

Поток данных в Redux всегда однонаправлен.

Передача действий с потоками данных происходит через вызов метода dispatch() в хранилище. Само хранилище передаёт действия редуктору и генерирует следующее состояние, а затем обновляет состояние и уведомляет об этом всех слушателей.

Советуем начинающим в Redux прочитать нашу статью о других способах передачи данных.

Вы получите аналогичное приложение после выполнения этих действий:

• локальная установка ReactJS при помощи шаблона;
• настройка «корзины» AWS (Amazon Web Services) S3;
• создание учетных данных пользователя AWS для загрузки файлов на S3;
• развертывание шаблона на AWS;
• проверка работоспособности.

Необходимые инструменты:

• Node.js версии 6.0 или выше;
• Yarn;
• Аккаунт AWS (бесплатного будет достаточно). Для интересующихся у нас есть шпаргалка по веб-сервисам Amazon.

1. Установка ReactJS

Клонируем шаблон (запустите команду в терминале), заменив «NameOfApp» на имя своего приложения:

Устанавливаем все библиотеки:

Запускаем React по локальному адресу http://localhost:3000/ (запуск может занять несколько секунд):

2. Настройка корзины AWS S3

Входим в свой аккаунт на AWS и выбираем S3:

Нажимаем «Create bucket» и вводим имя (например: onederful-quickstart). Нажимаем «Далее» на всех остальных шагах и создаем корзину (bucket, в русскоязычных источниках также можно встретить термин «бакет»):

Теперь открываем только что созданную корзину:

После появления всплывающего окна нажимаем на «Properties»:

Нажимаем на «Static website hosting» и вводим «index.html» в каждом из полей «Index document» и «Error document». Теперь у нас есть общедоступный URL:

Переходим на вкладку «Permissions», вместо [YOUR BUCKET NAME] вписываем свое название проекта:

3. Создаем учетные данные пользователя AWS для загрузки файлов на S3

В консоли управления AWS нажимаем на «IAM» (Identity Access Manager):

Переходим на вкладку «Users», находящуюся на боковой панели, и добавляем пользователя с именем «s3-admin»:

Прикрепляем «AmazonS3FullAccess policy»:

После создания пользователя сохраняем идентификатор доступа и секретный ключ (например, в блокноте) — они будут использоваться на последнем этапе этого руководства:

4. Публикуем шаблон на AWS

Замените следующие данные в файле tools/s3-upload.js:

• YOUR_BUCKET_NAME — на название корзины (со второго шага);
• YOUR_AWS_ACCESS_KEY — на свой идентификатор доступа (с третьего шага);
• YOUR_AWS_SECRET_KEY — на свой секретный ключ (с третьего шага).

Публикуем приложение:

5. Проверяем работоспособность и начинаем создавать приложение

Проверьте работоспособность приложения в вашем браузере. Если все работает, вы можете приступать к созданию логики вашего веб-приложения.

Настройка AWS должна выполняться только один раз, поэтому после внесения каких-либо изменений в ваше приложение можно просто запустить команду deploy, и в течение нескольких секунд изменения вступят в силу.