Комментарии 5
Смысла в этой копипасте я так и не увидел. Вы и себе жизнь усложнили, и разработчику, которому теперь придётся создавать 3 разных компонента, которые выглядят и ведут себя идентично. Ну, умный разраб, конечно создаст один компонент, но ему придётся сперва поиграть в игру "найди 10 отличий".
Разделять нормальная идея.
Во-первых, да, становится более определенным нейминг. Берем с панели компонент Dropdown — и получаем дропадун, а не «нечто инпутообразное, доработать напильником».
Во-вторых, боремся с комбинаторным взрывом. Если всё объединить, то получим в Фигме компонент с 10-15 свойствами и сотнями вариантов, которые страшно даже трогать. Ну и на фронте компонент с 10-15 пропсами.
Разделение, кстати, не запрещает использовать под капотом какие-то общие компоненты/миксины вложенного уровня.
Ну вот на картинках всё именно идентично, а не похоже.
Один вид, разное поведение. Вместо выделения общего кода/разметки (или, что ещё хуже, заталкивания if-ов в один компонент) автор предлагает не тратить время на декомпозицию и просто нарисовать одинаковую разметку в отдельных компонентах.
Подход имеет право на жизнь, ибо часто, действительно, компоненты могут развиваться отдельно, а визуально одинаковые изменения нетрудно произвести и в паре несвязанных компонентов. И это будет проще и быстрее, чем напрягаться с декомпозицией (и дальнейшей поддержкой этой декомпозиции). DRY-принцип часто применяют автоматически, как культ карго, без оценки стоимости декомпозиции, и на ровном месте повышают связанность (coupling) кода (повышают хрупкость изменений и когнитивную нагрузку на программиста). "Не слишком увлекайтесь игрой в архитектора" - я бы так расшифровал основную мысль статьи :).
Спасибо за Ваш ответ. К сожалению, в статье не удалось раскрыть некоторые тонкости. Решил тезисно уточнить некоторые моменты здесь.
— Наша Дизайн-система состоит не только из макета компонентов, но и их программной реализации.
— Узконаправленное использование программных компонентов удешевляет, как их использование, так и сопровождение с доработками.
— View мы используем для конечных форм с необходимостью переключения контента, Menu - для верхнеуровневых навигаций.
— При разработке ДС мы отталкивались от библиотеки PrimeFaces. Комопненты TabView и TabMenu в ней визуально похожи. Собственно, оттуда и появилась эта похожесть.
TabView https://www.primefaces.org/primeng/showcase/#/tabview
TabMenu https://www.primefaces.org/primeng/showcase/#/tabmenu
— Сейчас мы работаем над системой шаблонов и правил использования компонентов для того, чтобы таких недоумений у коллег возникало меньше.
Однако с Вашим ответом я также согласен. Вполне хорошая и обоснованная точка зрения. Спасибо :)
Похожие компоненты — разная специализация