NikitaRzm
commented
5 years ago В доке по аритектуре я может не полностью раскрывал все мысли на этот счет (было давно и я имел мало опыта), но выразил это словом декомпозинг - косяк согалсен. Сейчас уже сложно вспомнить все профиты, но я подскажу, куда копать.
Atomic design - в целом как подход для дизайна интерфейсов (и как следствие части дизайна архитектуры представления на фронте).
http://atomicdesign.bradfrost.com/chapter-2/ - это из гугла нашел, там схожие термины с архитектурой, которую используют пацаны в Тинькове. Атомы, молекулы, организмы и т.д. Прежде чем точно отказаться, стоит подумать про усовершенствование. Я в целом всегда за упрощение и вынести все в компоненты выглядит логично и круто. Но обобщив весь фидбэк по модулям, элементам (микрофичам прости господи), призываю изучить эту методологию и взять или не взять лучшее из того что она предлагает. Но при этом не усложнять восприятие при разработке архитектуры и раскладки компонентов дизайна на фронте.
kinda-neat
Мы сейчас разделяем компоненты из shared/view на components и elements. Это течёт отсюда:
но я не вижу в этом смысла.
Декомпозиция на уровни использования между собой не нужна т.к. это не имеет значения при использовании. Нам нужна shared компонента и нам всё равно на каком уровне она находится. Нам приходится об этом думать во время импорта и вспоминать что на каком уровне находится. Делать поиск сначала в components, потом в elements. Думать об этом когда добавляем компоненту, решать на какой уровень добалять. Перемещать эти компоненты между каталогами, когда уровни изменились, править по всем проекту импорты которые зависили от этих уровней.
В моей практике компоненты всегда имели древовидную зависимость и никогда не имели циклическую.
Даже если и возникнет циклическая, то непонятно как это разделение решит проблему.
И в целом, это разделение не сформулировано в полной мере и из него непонятно что куда класть.