Всем привет!
Я тут готовлю материалы для курса и освежил в памяти некоторые принципы архитектуры из книжки «Чистая архитектура».
Напомнил себе супер классный, но совершенно неизвестный принцип хорошей архитектуры. Он запрятан в середине книги, и, видимо, мало кто до туда дочитывает.
Называется он: Принцип устойчивых зависимостей
Хочу рассказать вам, так как нарушение этого принципа очень часто встречается именно в наших фронтовых приложениях
В каждом приложении есть компоненты, из которых оно состоит. В React приложении это могут быть React компоненты, хуки, сервисы. И все эти компоненты как-то связаны друг с другом. Связи в самом простом случае выражаются в импортах.
Так вот, в чём сам принцип:
Зависимости должны быть направлены в сторону устойчивости.
Что это значит для нас, как разработчиков? В любом приложении есть часто меняющиеся модули и редко меняющиеся модули.
Например, хук useDebounce или UiSelectField – это стабильные компоненты. А вот все компоненты страниц, особенно дажборды - это ооооооочень часто меняющиеся компоненты. Просто потому что на любой чих бизнеса нам нужно вносить туда изменения.
И, как раз, правило говорит: Пожалуйста, не надо, чтобы ваш UiSelectField зависел на всякие запросы к серверу, на роутинг и так далее. (вообще, с селектами очень часто разные костыли подобные видел)
Был случай, когда прямо в UiSelectField использовался Redux, из которого доставались нужные опции. При чём без этих опций компонент не работал, и его просто было не возможно использовать в другом месте (это было не абы где, а в uikit всеросийского телекоммуникационного монополиста)
А однажды, просто внутри селекта сидела обработка "особенного значения", при клике на которое открывалась новая страница, вместо вызова onChange 🙂
Бывали и менее критичные нарушения этих правил. Когда какие-то типы из компонентов страниц использовались в бизнес логике.
Ну и самое классическое нарушение этого принципа — использования api сервера по всему приложению.
Api сервера – это просто дико меняющаяся вещь. Каждая новая фича может потребовать кардинальных изменений.
Пожалуйста, когда используйте api:
1. Старайтесь его использовать в гибких компонентах. И отправляйте данные вниз пропсами или в стм. (или просто обмажьтесь фасадами)
2. Не используйте типы api напрямую в стабильных компонентах, лучше скопируйте по месту использования (в дочерних компонентах и СТМ)
Когда из-за новой фичи половина api сервера вашего приложения поменяется, большое спасибо мне скажете
Я тут готовлю материалы для курса и освежил в памяти некоторые принципы архитектуры из книжки «Чистая архитектура».
Напомнил себе супер классный, но совершенно неизвестный принцип хорошей архитектуры. Он запрятан в середине книги, и, видимо, мало кто до туда дочитывает.
Называется он: Принцип устойчивых зависимостей
Хочу рассказать вам, так как нарушение этого принципа очень часто встречается именно в наших фронтовых приложениях
В каждом приложении есть компоненты, из которых оно состоит. В React приложении это могут быть React компоненты, хуки, сервисы. И все эти компоненты как-то связаны друг с другом. Связи в самом простом случае выражаются в импортах.
Так вот, в чём сам принцип:
Зависимости должны быть направлены в сторону устойчивости.
Что это значит для нас, как разработчиков? В любом приложении есть часто меняющиеся модули и редко меняющиеся модули.
Например, хук useDebounce или UiSelectField – это стабильные компоненты. А вот все компоненты страниц, особенно дажборды - это ооооооочень часто меняющиеся компоненты. Просто потому что на любой чих бизнеса нам нужно вносить туда изменения.
И, как раз, правило говорит: Пожалуйста, не надо, чтобы ваш UiSelectField зависел на всякие запросы к серверу, на роутинг и так далее. (вообще, с селектами очень часто разные костыли подобные видел)
Был случай, когда прямо в UiSelectField использовался Redux, из которого доставались нужные опции. При чём без этих опций компонент не работал, и его просто было не возможно использовать в другом месте (это было не абы где, а в uikit всеросийского телекоммуникационного монополиста)
А однажды, просто внутри селекта сидела обработка "особенного значения", при клике на которое открывалась новая страница, вместо вызова onChange 🙂
Бывали и менее критичные нарушения этих правил. Когда какие-то типы из компонентов страниц использовались в бизнес логике.
Ну и самое классическое нарушение этого принципа — использования api сервера по всему приложению.
Api сервера – это просто дико меняющаяся вещь. Каждая новая фича может потребовать кардинальных изменений.
Пожалуйста, когда используйте api:
1. Старайтесь его использовать в гибких компонентах. И отправляйте данные вниз пропсами или в стм. (или просто обмажьтесь фасадами)
2. Не используйте типы api напрямую в стабильных компонентах, лучше скопируйте по месту использования (в дочерних компонентах и СТМ)
Когда из-за новой фичи половина api сервера вашего приложения поменяется, большое спасибо мне скажете