Модуль 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
Этот блок дает понимание, откуда вообще берется разделение на слои и роли. После него React, Vue и Angular перестают восприниматься как принципиально разные миры и собираются в единую архитектурную картину.
- Mvc и mvp: теория, презентация и разбор реализации на практическом проекте
- Mvvm: теория, excalidraw-схема и реализация на практическом проекте
- Роли и связи между слоями: view, model, presenter, viewmodel
- Data-binding через proxy: как реактивность работает под капотом
Флагманское видео модуля, где все идеи соединяются в работающую архитектуру на React. Здесь теория перестает быть теорией и собирается в цельную систему, пригодную для реального проекта.
- Dip и dependency injection на практике
- Composition root
- Архитектурные роли во frontend
- Инфраструктурный код
- Di через props и React.Context
- Основы тестируемости архитектуры
- Репозиторий с кодом, excalidraw-доска, разбор render props и обзор структуры папок
- Проектируешь компоненты, которые переживают смену стейт-менеджера и источника данных без переписывания
- Видишь архитектуру фреймворков через общие роли и слои, а не через синтаксис конкретной технологии
- Понимаешь, почему архитектурные методологии устроены именно так, и где от них можно осознанно отступать
В этом модуле ты разрабатываешь одно приложение в нескольких архитектурных итерациях. Каждая итерация решает конкретную проблему предыдущей и сравнивает подходы, технологии и стейт-менеджеры. Главная мысль модуля: архитектура важнее стека. Любой инструмент вторичен, если выстроены слои, границы и направление зависимостей.
2.1. Архитектурный скелет: от чистого React к слоистой системе
Базовая итерация приложения, на которой ставятся слои и направление зависимостей. Здесь становится видно, что чистый React при правильной архитектуре не уступает решениям с тяжелым стеком.
- Рефакторинг стартового приложения: структура папок, инфраструктурный код, di
- Слои service / model / viewmodel / view / composition root
- Архитектурные границы через роутинг
- Инфраструктурный код, который держит чистоту даже на голом React + context
- Contract-first api и автогенерация dto (orval)
- Визуализация связей модулей на excalidraw
Стейт-менеджер здесь рассматривается не как центр приложения, а как инструмент синхронизации 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
Отдельный блок про то, когда паттерны действительно нужны, а когда только усложняют систему. Все решения привязываются к реальным проблемам сложности, а не к моде на конкретный подход.
- Эволюция структуры папок и data flow по мере роста проекта
- Как я реально использую fsd на боевых проектах
- Bounded context на практике
- Когда внедрять микрофронтенды, а когда нет
- Общение между модулями через event emitter
- Module federation для vite и контроль зависимостей в host-приложении
- Метрики сложности модуля
Реалистичный сценарий про выбор уровня архитектуры под задачу и сроки. Одна и та же фича проходит путь от быстрого mvp до переиспользуемого решения для ui-kit.
- Быстрое решение: когда "хорошо сейчас" важнее "идеально потом"
- Модульная сборка зависимостей и продвинутый TypeScript для строгих api
- Гибкое решение с привязкой к Reatom: asyncwrapper, renderprop для списков
- Перенос фичи в ui-kit на чистом React + reactuse
- Паттерны slot и renderprop для композиции и подмены
- Отвязка фичи от типов конкретного стейт-менеджера
- Самописный di-container и poor man's di: где он работает, где ломается
Полный разбор стейт-менеджмента как класса задач, а не как набора библиотек. Этот блок помогает видеть общие принципы и понимать, зачем бизнес-логика должна жить вне ui.
- Что такое state и какие виды состояния бывают
- Виды стейт-менеджеров и их различия
- Проблемы экосистемы React
- Главная причина писать бизнес-логику вне ui
- Проблемы технологий, прибитых гвоздями к React (на примере React query)
- Обоснование выбора Reatom для сложных проектов
После архитектурного скелета добавляются вещи, которые отличают учебный проект от боевого: границы, права, обработка ошибок, 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
Реалистичный блок про ситуацию, когда идеальной инфраструктуры нет. На примере tanstack query разбирается, как чистая композиция и разделение бизнес-логики и ui работают даже на хуках.
- Рефакторинг приложения на tanstack query
- Di через самописный контейнер и через React.Context
- Dependency scopes
- Public api модуля
- Переход с классов на функции-фабрики и обоснование выбора синтаксиса
Отдельный блок про формы - место, где архитектура чаще всего разваливается. Разбираем валидацию, auth-поток и разделение логики формы и ui.
- React hook form: api, отличия от formik
- Zod: типобезопасная валидация и гибкие схемы для сложных форм
- Jwt auth: теория и взгляд со стороны бэкенда
- Реализация axios-интерцепторов
- Главная ошибка фронтендеров при работе с формами
- Разделение логики формы и ui
Сборка всего пройденного на боевом проекте, где архитектурные решения связываются в единую систему и проверяются на реальной сложности.
- Feature и widget: что это и как различать
- Page-first подход в проектировании страниц
- Архитектура страницы проектов: атомизация в Reatom, чистая работа с формами через di
- Менеджер модальных окон: архитектурная проблема привязки форм к жизненному циклу React
- Канбан-доска на dnd-kit: high cohesion внутри фичи, отделение типа домена от типа фичи
- Ssot и атомарный стейт-менеджер для построения цепочек производных значений
- Crud для канбана: нормализация данных, проблема синхронизации React router и React
- Undo/redo через паттерн event sourcing
- Local-first как направление развития (референс - архитектура linear)
- Проектируешь архитектуру React-приложения с нуля и обосновываешь каждое решение через trade-offs
- Выбираешь стейт-менеджер под задачу, а не по моде, и понимаешь, как он диктует архитектуру
- Пишешь чистый код одинаково на Reatom, Effector, Zustand и голом React - потому что мышление одно
- Масштабируешь архитектуру под рост сложности проекта без переписывания
- Доводишь фичи до production: optimistic ui, обработка ошибок, ролевая модель, cross-domain коммуникация