UI Renderer или Representation — следующий слой нашей архитектуры.

Есть ощущение, что всё, что я уже написал, больше подходит для бэкенд-разработки?
Да, это практически так и есть. MATRIX появилась в условиях разработки BFF, а это и есть обычный бэкенд-сервис.

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

😦 Из нового здесь, пожалуй, лишь то, что у нас все компоненты — "глупые".

Надеюсь, все знакомы со статьёй Дэна Абрамова где он описал паттерн разделения React-компонентов на презентационные (глупые) и контейнерные (умные). Презентационные компоненты отвечают только за отображение UI и получают данные через props, а контейнерные управляют логикой и состоянием.

Так вот, чтобы "умные" компоненты не становились слишком "умными", мы вообще от них отказались. "Умный" — значит, много знает про бизнес-логику и доменные сущности, а мы уже решили, что всё, что как-то обрабатывает доменные сущности, к домену и относится.

Поэтому у нас остаются только "глупые" компоненты, для которых мы прописываем свой контракт взаимодействия (пропсы), чтобы они приняли нужные пропсы и отобразили нужный UI. Остаётся только как-то передать эти пропсы в компоненты. Здесь на помощь приходит паттерн composeHooks.

На самом деле, это что-то вроде connect из Redux, который подключает компонент к стору с данными. Только в нашем случае composeHooks подключает компоненты к доменным сущностям в агностик режиме.

React Hooks Compose — композиция хуков для чистой архитектуры 🧩
Библиотека react-hooks-compose позволяет отделить хуки от компонентов, создавая переиспользуемые контейнеры. Она работает по принципу Redux connect, но для хуков — принимает хук и компонент, возвращает компонент с внедрёнными данными. Ключевой момент: хуки не содержат бизнес-логику, а служат адаптерами для подключения доменных сущностей к UI.
#hooks #architecture #composition