Современная архитектура фронтенда 102

Перевод статьи Modern Frontend Architecture 102.
Это перевод второй статьи из трех.

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

Фича представляет собой набор из компонентов, размещенных на одной ветке дерева.

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

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

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

Взаимодействие компонентов внутри фичи

Первая проблема 👊

Разъясним обязанности компонентов, разбив их на две категории:

Презентационный компонент (он же глупый компонент). Как следует из названия, его единственная роль заключается в отображении интерфейса и взаимодействии с пользователями. Он не знает о предметной области (domain) в котором он используется, и в нем нету никакой бизнес-логики, что делает этот компонент переиспользуемым.
Компонент списка является хорошим примером. Он умеет отображать свои элементы списка и взаимодействовать с пользователем, но он не знает ни о том, как были получены данные для списка, ни о том, каким образом обрабатываются события от пользователя (user events).
Контейнерный компонент (он же умный компонент): поскольку у презентационного (глупого) компонента отсутствуют данные, контейнерный компонент служит для него поставщиком данных. Он знает, как передать данные в презентационный компонент, а также же знает о том, как обрабатывать события от пользователя (user events). Это делает его осведомленным о его функциональной предметной области, что делает его идеальным хостом для бизнес-логики, но затрудняет переиспользование.

Связь между компонентом-контейнером и презентационным компонентом

PS: Некоторые фреймворки, такие как React, имеют одностороннюю привязку данных, передавая callback вместе с данными. Это не противоречит тому факту, что контейнерные компоненты будут передавать данные и обрабатывать события от пользователя.

Хотя связь между контейнерным и презентационным компонентами происходит по стандартным шаблонам, поток данных между различными контейнерами или даже фичами все еще остается неявным. Они должны разделять, читать и обновлять данные через App (приложение). Нам этот подход хорошо известен как: "управление состоянием (state management)".

Вторая проблема 🔥

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

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

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

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

Управление состоянием через глобальное состояние

Поток связи между слоями

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

State: Управляет состоянием приложения и гарантирует его согласованность.
Бизнес-логика: содержит бизнес-логику и предоставляет контекст для презентационных компонентов.
Пользовательский интерфейс: отображает пользовательский интерфейс и взаимодействует с пользователями.

Это также влияет на структуру директорий.

AppRepo
-- Overview
---- Components
------ ListComponent
------ ChartComponent
---- State

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

Состояние приложения состоит из состояний фич

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

Послесловие

Подписывайся на нас в социальных сетях:
Vue.js

Nuxt.js

Наши друзья uWebDesign: