Comments 2
Ваш подход хороший, т.е. кейс где Вы сделали на каждый "похожий но немного другой" отдельный компонент который внутри собирает нужный вид с нюансами. Проблемы у такого похода начинаются когда требуется совместить или использовать две и более модели которые вроде как обычно не связаны друг с другом но вот в каком-то одном месте они связаны и друг от друга зависят (внешний вид зависит). Мы можем объединить по этому же принципу в один компонент но он будет принимать уже не одну модель а n моделей что вполне может приводить к ситуации как Выше в статье мы вроде вынесли и собрали в одном месте но пропов (моделей) у него много для его настройки. Эту ситуацию можно допустим решить изменением структуры ответа у бекэнда на содержащую общую модель но не всегда это резонно и возможно, особенно если данные уже есть на стороне фронта смысла допустим получать их еще раз нет. Второе неудобство у данного подхода в том что если допустим я имею десять таких компонентов и что-то меняться фундаментально то в них во всех (или как минимум в большинство) придется зайти и что-то поменять. Я думаю что подход к разделению компонентов не может быть один, надо применять разные в зависимости от разных кейсов для применения компонентов. У нас в команде используется несколько разных подходов в том числе и все которые Вы описали в статье. Помимо них есть например еще подход когда компонент с бизнес логикой выноситься отдельно а компонент с представлением не содержит логики вообще. Вот пример кнопку мы разделили на два компонента один содержащий логику и состояние https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/states/ButtonState.vue и второй содержащий представление https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/views/material/MaterialButtonView.vue Суть такого подхода в том что можно без изменения компонента с бизнес логикой тасовать компоненты с его представлениями коих может быть много. Пример с кнопкой когда у нас логика нажатия и обработчик кнопки одинаковый у всех кнопок но выглядеть она может в разных частях системы по разному и для каждого представления будет свой компонент но без логики. Вот тут можно посмотреть пример как это склеить воедино https://github.com/P-RCollaboration/ProvueCoreComponents/blob/main/src/examples/helloworld/ButtonsDemo.vue Пример для кнопки но его можно натянуть и на бизнес логику.
Feature Sliced Design используем, он, в какой-то мере тоже задаёт определенные рамки для проектирования.
Декомпозиция и интерфейс vue-компонентов