Composables в Vue: как заменить миксины и переиспользовать логику

// formValidation.js
export const formValidationMixin = {
  data() {
    return {
      formData: {
        username: '',
        password: '',
      },
      formErrors: {
        username: '',
        password: '',
      },
    };
  },
  methods: {
    validateForm() {
      this.formErrors = {};

      if (!this.formData.username.trim()) {
        this.formErrors.username = 'Username is required.';
      }

      if (!this.formData.password.trim()) {
        this.formErrors.password = 'Password is required.';
      }

      return Object.keys(this.formErrors).length === 0;
    },
  },
};

// formValidation.js
import { reactive } from 'vue';

export function useFormValidation() {
  const state = reactive({
    formData: {
      username: '',
      password: '',
    },
    formErrors: {
      username: '',
      password: '',
    },
  });

  function validateForm() {
    state.formErrors = {};

    if (!state.formData.username.trim()) {
      state.formErrors.username = 'Username is required.';
    }

    if (!state.formData.password.trim()) {
      state.formErrors.password = 'Password is required.';
    }

    return Object.keys(state.formErrors).length === 0;
  }

  return {
    state,
    validateForm,
  };
}

Почему composables лучше миксинов в большинстве случаев

• Управление областью видимости: state и функции возвращаются явно, а не вливаются в компонент автоматически.
• Прозрачность зависимостей: видно, какие данные нужны composable и что он отдаёт.
• Модульность: composables проще тестировать и составлять из меньших частей.

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

Когда composables не подходят

• Когда логика сильно связана с жизненным циклом конкретного компонента (и не может быть легко абстрагирована). В таких случаях всё ещё имеет смысл использовать локальные хуки или просто методы компонента.
• Когда требуется автоматическая инъекция опций в компонент (миксины давали это «бесплатно»). Если вам нужно именно такое поведение, composables потребуют явного импорта и вызова.
• Когда composable становится монолитным и содержит слишком много обязанностей — это ухудшает повторное использование.

Альтернативные подходы

• Higher-order components (обёртки-компоненты) — полезны для оборачивания визуального поведения.
• Provide / Inject — удобно для передачи зависимостей в глубоко вложенные компоненты.
• Плагины Vue — для глобального поведения и конфигурации.
• Контекстные объекты и отдельные сервисы (например, singleton-сервисы для работы с API).

Выбор зависит от масштаба задачи: composables хороши для повторяемой логики, но для глобальных сервисов лучше использовать явные сервисы или плагины.

Ментальные модели и эвристики

• Single Responsibility: один composable — одна ответственность.
• Явный контракт: возвращайте объект с понятными ключами.
• Минимизируйте побочные эффекты: не меняйте глобальное состояние внутри composable без необходимости.
• Разделяй и властвуй: если composable растёт, разбей его на более мелкие функции.

Плейбук миграции: как перевести миксины в composables

1. Найдите миксины, которые повторяются в нескольких компонентах.
2. Выпишите все состояния, методы и хуки, которые они предоставляют.
3. Создайте функцию useXxx, импортируя необходимые функции из Vue (reactive, ref, watch и т.д.).
4. Верните только те значения и функции, которые нужны внешнему компоненту.
5. Замените подключение mixins на импорт и вызов composable в setup.
6. Запустите тесты и ручные проверки на страницах, где использовался миксин.

Критерии приёмки

• Компонент корректно рендерит предыдущую функциональность.
• Не возникло конфликтов имён или неявных зависимостей.
• Unit-тесты на composable и на компонент прошли.

Роль‑ориентированные чек‑листы

Для разработчика, который переводит миксины:

• Собрал все места использования миксина.
• Создал composable с явным API.
• Написал unit‑тесты для composable.
• Заменил вызовы миксина на вызовы composable.
• Проверил визуальное поведение и сценарии формы.

Для ревьювера кода:

• Composable придерживается принципа единой ответственности.
• Нет скрытых глобальных побочных эффектов.
• Имена возвращаемых свойств понятны и документированы.

Краткий глоссарий

• Composable — экспортируемая функция, использующая Composition API и возвращающая состояние и функции.
• Composition API — набор функций Vue 3 (ref, reactive, computed, watch и т.д.) для декларативной работы со состоянием.
• Миксин — объект с опциями Vue (data, methods, hooks), внедряемый в компоненты.

Примеры, когда composables не дают пользы

• Очень простые компоненты, где логика не повторяется — добавлять отдельный файл composable нечестно с точки зрения сложности.
• Сценарии, требующие автоматической глобальной инъекции свойств — composables требуют явного подключения.

Заключение

Composables — современный, гибкий и тестируемый способ переиспользования логики в приложениях Vue 3. Они устраняют многие проблемы миксинов: неявные зависимости и конфликты имён. При миграции важно разбивать ответственность, писать тесты и не позволять composables становиться монолитными.

Важно

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

Ключевые выводы

• Composables делают зависимости явными и улучшают тестируемость.
• Не превращайте composables в монстры — разбивайте на мелкие функции.
• Миграция от миксинов к composables даёт больше контроля и предсказуемости.