Архитектуры интерфейса: «простой модульный» подход

Поймите плюсы и минусы модульной архитектуры внешнего интерфейса

Статья, которую вы читаете, является частью серии, посвященной фронтенд-архитектуре. В этой статье мы рассмотрим простой модульный подход. Основная концепция этой архитектуры заключается в четком разделении модулей приложения.

Хотя этот подход кажется простым для понимания, он может быть очень полезным. Это даст вам некоторые базовые знания о модульных архитектурах и подготовит вас к более сложным темам, которые появятся в ближайшем будущем. Давайте начнем!

Оглавление

• Обзор архитектуры
• Плюсы и минусы архитектуры
• Сравнение с «классической архитектурой (или без архитектуры)»
• Хотите узнать больше?

Обзор архитектуры

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

Давайте начнем изучение этого подхода с изучения его компонентов. В большинстве случаев он состоит всего из четырех частей: страницы, модули, компоненты и пользовательский интерфейс.

• UI — каталог для компонентов пользовательского интерфейса, таких как кнопки, элементы выбора и ввод.
• components — каталог для менее независимых фрагментов кода. Хорошим примером этого может быть ProductCard. Однако элементы в этом каталоге не должны иметь какой-либо конкретной бизнес-логики, поскольку они должны оставаться пригодными для повторного использования.
• modules —каталог для независимых модулей вашего приложения. SignInForm — яркий пример изолированного модуля со своей логикой и задачами.
• pages — каталог, содержащий маршруты приложений.

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

Теперь попробуем разобраться в каждой из этих частей подробнее.

UI

Пользовательский интерфейс должен состоять только из многократно используемых компонентов (проект ui-kit). По сути, это костяк проекта. Он формирует основу, на которой строятся другие уровни, и не должен содержать никакой бизнес-логики. В противном случае использование компонентов из этого модуля станет затруднительным и ненадежным.

Имейте в виду, что запрещено импортировать объекты из других слоев.

Компоненты

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

Имейте в виду, что запрещено импортировать объекты из слоев модулей и страниц.

Модули

Объекты в этом каталоге должны быть очень независимыми и иметь свою собственную зону ответственности. Все необходимые функции, такие как вспомогательные функции, хранилища, константы и взаимодействия с API, должны быть объявлены и использованы в модуле. Это помогает предотвратить разброс функций по всему проекту и упрощает обслуживание. Таким образом, мы сохраняем согласованность и несвязанность вещей, что является нашей глобальной целью.

Один важный момент! Каждый модуль должен иметь и index.js файл, в котором объявлен экспорт для внешнего использования (известный как «Общедоступный API»). Основная цель этого файла — изолировать внутренности модуля. Это помогает установить четкие связи и избежать хаотической связи.

Имейте в виду, что импорт объектов из других модулей и страниц запрещен.

Страницы

По сути, каждый элемент каталога pages представляет собой комбинацию различных модулей. Страницы также могут быть разбиты на более мелкие подкаталоги. Ключевое различие между страницами и модулями — толщина логики. Страницы также могут быть разделены на более мелкие подкаталоги. Основное различие между страницами и модулями заключается в объеме бизнес-логики, которую они содержат. Количество страниц должно быть минимальным, а вся бизнес-логика должна быть размещена в модулях для использования на уровне страницы.

Плюсы и минусы архитектуры

Как и все другие архитектуры, простой модульный подход имеет свои преимущества и недостатки.

Плюсы:

• Выделение функциональности модуля концепцией «публичного API»
• Четкий однонаправленный поток данных (страницы => модули => компоненты => пользовательский интерфейс)
• Высокая возможность повторного использования за счет разделения слоев
• Улучшенное обслуживание и более простая возможность рефакторинга
• Высокая связность внутри модулей и низкая связь между ними

Минусы:

• Определение принадлежности объекта (модули или компоненты) может быть сложной задачей.
• Что делать, если нам нужен один модуль внутри другого?
• Некуда ставить бизнес-компоненты!
• Неясная связь с глобальными состояниями и помощниками

Сравнение с «классическим подходом» (или без архитектуры)

Для справки: «Классический подход» ранее обсуждался в этой статье.

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

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

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

В следующей статье мы обсудим наиболее надежное решение этой проблемы.🌟Ждите следующую статью из серии!)

Хотите узнать больше?

Спасибо, что прочитали!

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

Не забудь подписаться⭐️

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord.

Повысьте узнаваемость и признание вашего технического стартапа с помощью Circuit.