На главную

Программа курса

Полная программа

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

Модуль 1

Фундаментальные знания

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

1.1. SOLID в контексте React

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

  • S - Single Responsibility Principle: разделение ответственности между хуком, view-компонентом и контейнером
  • O - Open/Closed Principle: расширяемые компоненты через композицию и slot-подход вместо флагов-пропсов
  • L - Liskov Substitution Principle: подстановка типов и работа с нативными HTML-атрибутами через ComponentProps
  • I - Interface Segregation Principle: прозрачные пропсы и влияние интерфейсов на читаемость кода в команде
  • D - Dependency Inversion Principle: отвязка компонентов от backend, localStorage, IndexedDB, Supabase, Firebase и конкретного state management

1.2. MV*-паттерны: MVC / MVP / MVVM

Этот блок дает понимание, откуда вообще берется разделение на слои и роли. После него React, Vue и Angular перестают восприниматься как принципиально разные миры и собираются в единую архитектурную картину.

  • MVC и MVP: теория, презентация и разбор реализации на практическом проекте
  • MVVM: теория, Excalidraw-схема и реализация на практическом проекте
  • Роли и связи между слоями: View, Model, Presenter, ViewModel
  • Data-binding через Proxy: как реактивность работает под капотом

1.3. Сборка фундамента под React

Флагманское видео модуля, где все идеи соединяются в работающую архитектуру на React. Здесь теория перестает быть теорией и собирается в цельную систему, пригодную для реального проекта.

  • DIP и Dependency Injection на практике
  • Composition Root
  • Архитектурные роли во Frontend
  • Инфраструктурный код
  • DI через props и React.Context
  • Основы тестируемости архитектуры
  • Репозиторий с кодом, Excalidraw-доска, разбор render props и обзор структуры папок

После модуля ты

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

Модуль 2

Основная часть. Архитектура React-приложения от хаоса до production

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

2.1. Архитектурный скелет: от чистого React к слоистой системе

Базовая итерация приложения, на которой ставятся слои и направление зависимостей. Здесь становится видно, что чистый React при правильной архитектуре не уступает решениям с тяжелым стеком.

  • Рефакторинг стартового приложения: структура папок, инфраструктурный код, DI
  • Слои Service / Model / ViewModel / View / Composition Root
  • Архитектурные границы через роутинг
  • Инфраструктурный код, который держит чистоту даже на голом React + Context
  • Contract-first API и автогенерация DTO (orval)
  • Визуализация связей модулей на Excalidraw

2.2. Подбор стейт-менеджера и его роль в архитектуре

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

  • Zustand: правильное хранение бизнес-логики и роль Model
  • Service Locator: безопасное использование через Module Composition Root
  • Оптимизация ре-рендеров: селекторы, инкапсуляция состояния, children-пропсы
  • Global / Module / Local Composition Root
  • Preact/signals и HOC для работы с Service Locator
  • Effector: бизнес-логика как граф событий, паттерн Gateway из DDD
  • Reatom: философия и почему он сильнее аналогов на сложных проектах
  • Inversion of Control, Builder Pattern, Identify из LIFT
  • Высокоуровневые vs низкоуровневые модули
  • Самописный Zustand на useSyncExternalStore и fine-grained reactivity

2.3. Масштабирование архитектуры при росте сложности

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

  • Эволюция структуры папок и data flow по мере роста проекта
  • Как я реально использую FSD на боевых проектах
  • Bounded Context на практике
  • Когда внедрять микрофронтенды, а когда нет
  • Общение между модулями через Event Emitter
  • Module Federation для Vite и контроль зависимостей в host-приложении
  • Метрики сложности модуля

2.4. Одна фича - четыре реализации

Реалистичный сценарий про выбор уровня архитектуры под задачу и сроки. Одна и та же фича проходит путь от быстрого MVP до переиспользуемого решения для ui-kit.

  • Быстрое решение: когда "хорошо сейчас" важнее "идеально потом"
  • Модульная сборка зависимостей и продвинутый TypeScript для строгих API
  • Гибкое решение с привязкой к Reatom: AsyncWrapper, renderProp для списков
  • Перенос фичи в ui-kit на чистом React + reactuse
  • Паттерны slot и renderProp для композиции и подмены
  • Отвязка фичи от типов конкретного стейт-менеджера
  • Самописный DI-container и Poor man's DI: где он работает, где ломается

2.5. Глубокая теория State Management

Полный разбор стейт-менеджмента как класса задач, а не как набора библиотек. Этот блок помогает видеть общие принципы и понимать, зачем бизнес-логика должна жить вне UI.

  • Что такое State и какие виды состояния бывают
  • Виды стейт-менеджеров и их различия
  • Проблемы экосистемы React
  • Главная причина писать бизнес-логику вне UI
  • Проблемы технологий, прибитых гвоздями к React (на примере React Query)
  • Обоснование выбора Reatom для сложных проектов

2.6. Production-фичи: доводим приложение до боевого состояния

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

  • JSON Server и переход к реалистичной работе с API
  • ESLint-плагин для контроля архитектурных границ
  • Optimistic UI на Reatom: транзакции, ACID, атомарность
  • Сравнение подхода с Optimistic Updates в Tanstack Query
  • Обработка ошибок через концепцию Fail Fast
  • Декларативная композиция через вспомогательные компоненты
  • Ролевая модель: проблема FSD-слоя entities и зачем нужен core
  • Авторизация vs аутентификация и защита модулей через Dependency Inversion
  • Компонент Can для декларативной работы с ролями
  • Cross-domain коммуникация и паттерн Facade
  • Сила чистых функций при cross-domain взаимодействии
  • Builder vs Adapter: разница на практике
  • Что произойдет, если выкинуть слой Service
  • Perceived Performance как метрика UX

2.7. Архитектура без IoC-контейнера

Реалистичный блок про ситуацию, когда идеальной инфраструктуры нет. На примере Tanstack Query разбирается, как чистая композиция и разделение бизнес-логики и UI работают даже на хуках.

  • Рефакторинг приложения на Tanstack Query
  • DI через самописный контейнер и через React.Context
  • Dependency Scopes
  • Public API модуля
  • Переход с классов на функции-фабрики и обоснование выбора синтаксиса

2.8. Работа с формами и аутентификация

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

  • React Hook Form: API, отличия от Formik
  • Zod: типобезопасная валидация и гибкие схемы для сложных форм
  • JWT Auth: теория и взгляд со стороны бэкенда
  • Реализация Axios-интерцепторов
  • Главная ошибка фронтендеров при работе с формами
  • Разделение логики формы и UI

2.9. Разработка Kanban-доски

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

  • Feature и Widget: что это и как различать
  • Page-first подход в проектировании страниц
  • Архитектура страницы проектов: атомизация в Reatom, чистая работа с формами через DI
  • Менеджер модальных окон: архитектурная проблема привязки форм к жизненному циклу React
  • Канбан-доска на dnd-kit: high cohesion внутри фичи, отделение типа домена от типа фичи
  • SSoT и атомарный стейт-менеджер для построения цепочек производных значений
  • CRUD для канбана: нормализация данных, проблема синхронизации React Router и React
  • Undo/Redo через паттерн Event Sourcing
  • Local-first как направление развития (референс - архитектура Linear)

2.10. FSD на практике: ловушки и инфраструктура

Типичные ошибки при работе с FSD и любой архитектурой, плюс инфраструктурные вещи, которые появляются в production: тема, feature flags и безопасная композиция provider'ов.

  • Destructive Decoupling: частая ошибка при работе с FSD и любой архитектурой
  • Разработка темы приложения
  • Разработка feature-flags
  • Нарушение правил FSD и возможные циклические зависимости
  • Компонент Compose для плоской композиции provider'ов

2.11. Интернационализация

От локальных переводов до асинхронной подгрузки локалей и связки i18n с валидацией форм.

  • Интернационализация через i18next: теория и практика с локальными переводами
  • HttpBackend-плагин и асинхронная подгрузка локалей
  • Localize-хэлпер для создания Zod-схем

2.12. Экосистема MobX

Обзор стека следующих уроков и обоснование выбора MobX как основы для MVVM-архитектуры.

  • Почему MobX
  • MobX: базовые механики и реактивность
  • mobx-tanstack-query
  • mobx-react-hook-form

2.13. Работа с API: абстракции и Fetches

Разбор цены абстрактного интерфейса и практическая работа с API через библиотеку Fetches.

  • Трейдоффы абстрактного интерфейса и где абстракция вводит в заблуждение
  • Библиотека Fetches для работы с API

2.14. MVVM и ViewModel

ViewModel как связка паттернов Facade и Mediator: что это, зачем нужно и чем отличается от Store.

  • Что такое ViewModel
  • ViewModel как связка механик Facade и Mediator
  • Разница ViewModel и Store

2.15. Наследование во Frontend

Как полезно применять наследование: скрытие сложности форм, абстрактный ViewModel и привязка к жизненному циклу React.

  • Классы SchemaForm и EnhancedForm для скрытия сложности
  • Абстрактный класс ViewModel и зачем от него наследоваться
  • Биндинг ViewModel к React для вызова методов жизненного цикла

2.16. Роутинг на mobx-route

Инфраструктура роутинга в связке с MobX и lazy loading через Suspense.

  • Инфраструктурный код для роутинга
  • Обзор mobx-route
  • Suspense + lazy для Lazy Loading

2.17. DI через Tsyringe

Как собирать ViewModel через DI-контейнер и держать зависимости явными и тестируемыми.

  • Обзор Tsyringe
  • Сборка ViewModel через DI-контейнер

2.18. Композиция и агрегация

OOP-механика расширения модулей: что создавать внутри, что получать снаружи и как расширять ViewModel без раздувания ответственности.

  • Обзор архитектуры модуля
  • Что такое композиция и агрегация
  • Как расширять ViewModel
  • Что создавать внутри модуля, а что получать снаружи

2.19. Query, Mutation и стратегии кэширования

Инфраструктура над Query и Mutation и осознанный выбор стратегии кэширования под задачу.

  • staleTime vs gcTime
  • Инфраструктура над Query и Mutation
  • Стратегии кэширования: swr, cache-first, networkOnly

2.20. Теория FEOD

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

  • База FEOD: переписываем прошлый проект
  • Вариант без слоя Pages и почему это допустимо
  • Методология как набор инструментов, а не готовый рецепт

2.21. Фича оформления документов: плохая реализация

Антипаттерн на реальной фиче: как попытка «сделать DRY» приводит к плохой архитектуре и сложному коду. Теория и разбор кода.

  • Обзор фичи оформления документов
  • Почему попытка реализовать DRY приводит к плохой архитектуре
  • Разбор кода плохой реализации

2.22. Фича оформления документов: хорошая реализация

Та же фича, собранная правильно: анализ модуля documents-list и работа с ActionButtons.

  • Анализ модуля documents-list
  • Работа с ActionButtons

2.23. Структура ui-kit и сквозные модули FEOD

Как устроены сквозные модули FEOD и чему можно научиться у структуры папок популярных UI-библиотек.

  • Сквозные модули FEOD
  • Структура MUI, Mantine и React Aria

2.24. Act / Contract и StepConfig

Разделение типов и логика формирования шагов: два процесса оформления вместо одного общего «универсального» потока.

  • Структура данных для формирования шагов
  • Разделение типов на Act и Contract
  • Два процесса оформления вместо одного общего

2.25. Архитектура модуля оформления документов

ViewModel процесса, модули-участники и осознанное нарушение REST API ради упрощения Frontend.

  • ViewModel процесса оформления
  • Архитектура модулей, которые участвуют в процессе
  • Нарушение правил REST API для облегчения Frontend — хорошая практика

2.26. Сборка форм и гибкий степпер

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

  • Сборка ViewModel каждой из форм
  • Изменение структуры данных для более гибкого степпера

После модуля ты

  • Проектируешь архитектуру React-приложения с нуля и обосновываешь каждое решение через trade-offs
  • Выбираешь стейт-менеджер под задачу, а не по моде, и понимаешь, как он диктует архитектуру
  • Пишешь чистый код одинаково на Reatom, Effector, Zustand, MobX и голом React - потому что мышление одно
  • Масштабируешь архитектуру под рост сложности проекта без переписывания
  • Доводишь фичи до production: optimistic UI, обработка ошибок, ролевая модель, cross-domain коммуникация
  • Строишь MVVM на MobX: ViewModel, DI через Tsyringe, роутинг, Query/Mutation и стратегии кэширования
  • Внедряешь i18n, feature flags и тему приложения без ломки архитектурных границ
  • Проектируешь сложные процессы через FEOD: Act/Contract, степпер, композицию и агрегацию модулей