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

Как вы, возможно, знаете, 5–10 лет назад вся бизнес-логика находилась в бэкенде, а фронтенд отвечал только за рендеринг данных. С внедрением SPA в нашу жизнь ответственность за бизнес-логику стала перекладываться на front-end.

Одной из наиболее важных причин, почему мы используем SPA, является базовая структура компонентов, так каким же должен быть компонент?

Компонент

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

Мы также должны учитывать принципы SOLID, которые должен знать каждый разработчик программного обеспечения при разработке компонентов, но как?

  • У компонента должна быть одна и только одна причина для изменения, а это означает, что компонент должен иметь только одно задание.
  • Компоненты должны быть открыты для расширения, но закрыты для модификации.
  • Изменение, которое вы внесли в компонент, не должно влиять на другой компонент.
  • Зависимость между компонентами должна быть как можно меньше.

Мы можем создать компонент, применяя эти принципы, но управлять ими очень сложно, когда увеличивается количество продуктов/команд, количество компонентов и т. д. Мы используем систему проектирования, чтобы предотвратить это.

Дизайн-система

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

Почему дизайн-система?

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

Мы не проектируем страницы, мы проектируем системы компонентов.
– Стивен Хэй

Мы создали компонент с принципами SOLID в системе дизайна, но нам нужно было определить архитектуру для объединения всех компонентов и создания страницы. На этот раз мы воспользуемся Методологией атомарного дизайна, которую разделяет Брэнд Фрост.

Атомный дизайн

Atomic Design позволяет создавать повторно используемые компоненты. Название методологии происходит от наименьшей единицы, на которую можно разделить материю. Он нацелен на разделение наименьшего компонента единицы.

В нем упоминаются 5 основных структур. Атомы, молекулы, организмы, шаблоны, страницы. Я не пишу подробности атомного дизайна.

Почему?

  • Повышает возможность повторного использования компонентов
  • Предотвращает повторение компонента/кода
  • Это позволяет увеличить скорость разработки

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

Чистые классы JavaScript

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

Зачем нам это нужно?

  • В принципе, мы можем использовать объектно-ориентированный подход.
  • Мы можем воспользоваться шаблоном проектирования. Шаблоны решают проблемные части кодовой базы, если мы используем их в нужное время.
  • У нас может быть независимая бизнес-логика от Vue, React, Angular и т. д. Таким образом, мы можем просто переключать некоторые технологии.
  • Мы можем использовать класс бизнес-логики в разных компонентах, потому что он не зависит ни от одного компонента.

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

Если вы хотите узнать больше о следующих темах ниже, я напишу их во втором сообщении в блоге.

  • Блок/интеграция/автоматизация тестирования
  • Обработка ошибок
  • Мониторинг
  • Действия на GitHub
  • Некоторые из библиотек