Миксины часто используются в проектах для переиспользования какой-то части бизнес-логики, но они имеют неопределённости и некоторые нюансы, которые всё более заметны в процессе разработки проекта. Я сталкивался с ними время от времени, и они вызывали трудности при рефакторинге кодовой базы или разработке новых функций.

Прежде чем описывать мой подход, я хотел бы рассказать о преимуществах и недостатках использования миксинов.

Преимущества:

  • Расширяет принципы DRY повторного использования кода. Мы можем повторно использовать ту же бизнес-логику в другом компоненте;
  • Мы можем использовать миксин как глобальный миксин и делиться контекстом со всеми компонентами;
  • Mixin — отличный инструмент для создания модульной структуры проекта.

Недостатки:

  • Непрозрачная логика компонентов, использующих миксины. Я имею в виду, что сложно увидеть полную картину компонента, состоящего из множества строк кода и нескольких связанных примесей. Особенно это ощущается, когда вы новичок в проекте, и адаптация занимает больше времени;
  • Перезаписываемый контекст. Вы должны обратить внимание на то, чтобы не перезаписывать методы, геттеры или данные каким-либо миксином из-за того же имени;

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

  • Используйте префиксы в начале имен методов, геттеров, значений и реквизитов. Он показывает, к какой функциональности относится миксин. Использование этого совета дает вам возможность легко отделить компонентные реквизиты от миксинов.
    Например: $<mixinName>_<(prop|method|value)>

Как использование props выглядит в родительском компоненте:

  • Я предпочитаю не использовать префикс для глобального миксина. Обычно названия методов и значений понятны, а их функционал не дублируется в других частях проекта, поэтому префикс для них не нужен.

Преимущества подхода:

  • Методы или свойства примесей удобно использовать для автозаполнения IDE.
  • Использование префикса позволяет избежать случайной перезаписи методов и свойств примесей методами компонентов.
  • Прозрачность и удобство чтения кода компонента разработчиками на больших проектах.

Заключение

Mixin — полезный инструмент, но он может сделать ваш проект более сложным, негибким и непрозрачным в больших проектах. Использование этого подхода является хорошей практикой, позволяющей сохранить хороший опыт разработчиков и избежать недостатков.

Пожалуйста, похлопайте 👏, если эта статья была для вас полезной. Кроме того, я могу следить за мной, чтобы быть в курсе моих новых статей.

Для получения дополнительной информации обо мне вы можете посетить мой веб-сайт.