Декомпозиция компонентов в UI

Обновлено:

Сегодня мой ученик задал вот такой хороший вопрос:

Вопрос

Может кто-нибудь сталкивался с такой ситуацией в командной разработке.

Один фронт создал компонент. Второму фронту понадобился этот же компонент, но ему нужно изменить логику его работы, но если он её изменит, то у функционал первого фронта сломается?

Что в таком случае делать второму фронту?

Пытаться сделать компонент более переиспользуемым увеличивая количество логики внутри или создавать копию этого компонента с другой логикой?

Командными усилиями учеников мы пришли к двум вариантов ответов:

Длинный ответ

Есть несколько подходов, которые можно рассмотреть:

  1. Переиспользование с параметрами или настройками: Попробуйте сделать компонент более гибким и параметризуемым. Разработайте его таким образом, чтобы части логики можно было настраивать снаружи компонента, например, через передачу параметров или использование свойств.

  2. Создание расширенной версии: Если новая логика сильно отличается от оригинала и может привести к различному поведению, может быть разумным создать новую версию компонента. Основная идея останется, но внутренняя реализация будет подстроена под новые требования.

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

  4. Разделение на отдельные компоненты: Если изменения слишком существенны и концептуально отличаются, может быть лучше создать два отдельных компонента с разной логикой. Это поможет избежать путаницы и сохранит чистоту и понятность кода.

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

Короткий ответ

У вас ранее был компонент А, и вам нужно получить в результате работы компоненты А1 Б В, где:

  • А1 - компонент отвечающий за общую или базовую логику
  • Б - А1 + описание логики присущее А
  • В - А1 + описание новой бизнес логики

Обычно А1 описывают в максимально простом виде