С нуля: что такое архитектура фронтенда на самом деле
Архитектура фронтенда — это дисциплина перехода от страницы к приложению. Это карта «с нуля» и восемь слов — компонент, состояние, пропсы, ре-рендер, загрузка данных, клиент vs сервер, бандлер, дерево компонентов, — которые каждый следующий юнит считает уже знакомыми.
Ты умеешь писать HTML. Ты добавляешь немного JavaScript на страницу, чтобы кнопка загорелась или меню открылось. Это страница. Теперь представь: нужно отслеживать, какие товары в корзине, какой пользователь авторизован, открыто ли модальное окно, что только что вернул сервер — и всё это одновременно, в десятках интерактивных кусков, пока команда дизайнеров добавляет новые фичи. Это приложение. Разрыв между ними — не больший тег script. Это архитектура: набор решений о том, как устроены части интерфейса, как они обмениваются данными и как твой код добирается из редактора до браузера в любой точке земли. Этот урок — карта перед восхождением.
Один сдвиг, который меняет всё
Веб-страница — это преимущественно статика: пришёл HTML, запустился JS, готово. Приложение — живой организм: оно хранит данные, которые меняются со временем, перерисовывает части себя в ответ на изменения и общается с сервером без перезагрузки страницы. Именно этот переход — от документа к приложению — и решает архитектура фронтенда. Сделаешь правильно — команда из десяти человек добавляет фичи, не мешая друг другу. Сделаешь неправильно — каждая новая фича превращается в игру «кто сломал корзину?»
Когда ты впервые словишь баг, при котором нажатие одной кнопки ломает несвязанный кусок экрана, тебе понадобится ментальная модель — и вот она.
Хорошая новость: вся дисциплина держится на одном уравнении. Интерфейс — это функция от состояния. Всё остальное — детали поверх него.
Восемь слов, которые остальной трек считает знакомыми
Senior-юниты дальше используют эти термины, не останавливаясь на определениях. Вот они, по одному предложению — что это и зачем оно.
| Слово | Что это | Зачем оно |
|---|---|---|
| Компонент (component) | Самодостаточный кусок интерфейса — кнопка, карточка, целая страница, — написанный как функция. | Чтобы один раз написать и переиспользовать везде, а не копировать HTML. |
| Состояние (state) | Данные, которые могут меняться со временем и которые интерфейс должен отражать немедленно. | Чтобы приложение «помнило» вещи — товары в корзине, статус логина, открытые окна — без перезагрузки. |
| Пропсы (props) | Значения, которые родительский компонент передаёт дочернему, как аргументы функции. | Чтобы переиспользуемый компонент рендерился по-разному в зависимости от того, что передал вызывающий. |
| Ре-рендер (re-render) | Повторный запуск функции компонента фреймворком для получения обновлённого интерфейса. | Чтобы экран автоматически синхронизировался с состоянием — без ручной работы с DOM. |
| Загрузка данных (data fetching) | Запрос данных с сервера (или API) и помещение их в состояние. | Чтобы интерфейс показывал живую информацию, а не только то, что было вшито в HTML. |
| Клиент vs сервер | Выполняется ли код в браузере пользователя (клиент) или на твоей машине в дата-центре (сервер). | Чтобы понимать, где должны жить секреты, базы данных и тяжёлая логика — и где им быть нельзя. |
| Бандлер (bundler) | Инструмент (например, Vite, webpack), объединяющий твои исходные файлы в оптимизированные файлы для браузера. | Чтобы в разработке писать чистый модульный код, а в продакшен отдавать быстрые компактные файлы. |
| Дерево компонентов (component tree) | Иерархия родитель–потомок всех компонентов, составляющих страницу. | Чтобы понимать, где живёт состояние, как пропсы текут вниз и что ре-рендерится при изменении. |
Как они складываются вместе
Прочитанные по порядку, слова рассказывают одну историю: ты пишешь компоненты — каждый чистая функция от своих пропсов и состояния — и вкладываешь их в дерево компонентов. Когда пользователь действует, состояние меняется. Фреймворк автоматически ре-рендерит затронутые компоненты. Где-то в дереве компонент делает загрузку данных, затягивая живые данные с сервера в локальное состояние. Бандлер берёт всё это — сотни исходных файлов, библиотек, стилей — и создаёт небольшие оптимизированные бандлы, которые браузер реально может загрузить. Этот абзац — весь трек в миниатюре; каждый следующий юнит увеличивает один из шагов.
▸Почему это работает
Почему нельзя продолжать писать «ванильный JS»? Потому что неструктурированный код не масштабируется. Когда каждая часть страницы напрямую лезет в DOM (Document Object Model — дерево HTML-элементов страницы) и мутирует его, никто не может предсказать, что изменится и когда. Компонентная модель с явным состоянием и однонаправленным потоком данных делает поведение предсказуемым: ты знаешь, что компонент меняет только свой DOM и только в ответ на своё состояние или пропсы от родителя. Эта предсказуемость позволяет команде из двадцати человек добавлять фичи без постоянного тушения пожаров.
Это не нужно зубрить
Две честные ремарки перед восхождением. Первая: никто не держит всё это в голове сразу в первый день — ты встретишь каждое слово снова, в глубину, в своём юните, и тогда оно уляжется. Эта страница — вешалка для деталей, а не экзамен. Вторая: не каждому проекту нужно каждое понятие. Небольшой маркетинговый сайт может иметь почти никакого состояния и никакой конфигурации бандлера. Senior-трек учит полной картине, потому что этого требует продакшен-приложение под нагрузкой, — но «начни просто, добавляй сложность, когда заболит» и есть senior-инстинкт.
Какое ключевое уравнение лежит в основе всей архитектуры фронтенда?
Расставь путь от действия пользователя до обновлённого экрана:
- 1 Пользователь действует (нажимает кнопку, отправляет форму)
- 2 Состояние меняется в компоненте, который его хранит
- 3 Фреймворк ре-рендерит затронутые компоненты в дереве
- 4 Обновлённый интерфейс появляется в браузере
- 01В одном дыхании: какое ключевое уравнение архитектуры фронтенда и что означает каждый термин?
- 02В чём разница между пропсами и состоянием, и почему это важно?
Архитектура фронтенда — это одна идея с кучей навешанной механики: интерфейс есть функция от состояния, и всё остальное — инфраструктура, чтобы это уравнение работало в масштабе. Структурная половина — дерево компонентов: компоненты получают пропсы, хранят состояние и автоматически ре-рендерятся при его изменении, так что ты никогда не трогаешь DOM вручную. Операционная половина — загрузка данных (затягивание живых данных с сервера в состояние) и граница клиент–сервер (понимание, где код может безопасно выполняться). Сборочная половина — бандлер, превращающий твои модульные исходники в быстрые компактные файлы, которые браузер реально загружает. Тебе не нужно держать все восемь слов сразу — у каждого впереди свой юнит. Теперь, когда встретишь в ревью фразу «поднятие состояния вызвало лишние ре-рендеры», ты будешь точно знать, какие три из этих восьми слов достать первыми.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.
Примени это
Примени этот урок в реальном проекте.