Каков best practice для общего функционала во Vue?

Question

[Алексей Николаев]

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

Для этого я вижу несколько вариантов:
- композиция (предпочтительно, но в мире JS нельзя сделать без костылей, так я бы в конструктор передал абстракцию)
- hoc (тоже весьма неплохо)
- наследование (не очень хорошо, снижает гибкость и вообще)
- миксины (аналог трейтов в php, по-моему, не самая удачная практика и по идее, миксины должны обкидывать помидорами за то, что там можно определить Lifecycle hooks и опции типа data, столько простора для индусов)

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

Comments

[Антон Антон]

Меня интересует то же, но для шаблонов почти похожих (например в одной таблице есть колонка, а в другой - нет). Для кода в одном из случаев выбрал наследование и v-if для шаблонов, но мне не нравится, иногда использовал примеси, в зависимости от нужд. Например для модулей vuex наследование хорошо заходит.

Answer 1

[Alex Wells]

В третей вьюхе будет композиция с помощью нового composition API. Говорят, что они схожи с реактовскими хуками.

Пока что можно юзать https://github.com/vuejs/composition-api - порт того же (или +- того же) АПИ на вторую версию. Важно понимать, что это НЕ полный порт, а лишь compat слой для легкого перехода на третюю версию.

Comments

[gruzdkov-a]

Сomposition api для vue 2 сделан только для демонстрации возможностей и оформления RFC. Не стоит брать этот пакет в продакшн.
Многое можно реализовать с помощью scoped-слотов (гуглить vue renderless components для того чтобы понять общий принцип)
Можно накрутить небольшой DI на provide/inject (в документации почему то пишут что это только для разработки плагинов, но это бред. Ведь это аналог реактовского контекста, используемого повсеместно)
Миксины тоже не стоит сбрасывать со счетов, если их использвать атомарно, а не строить все приложение - они вполне будут уместны.
Также определенную часть логики можно реиспользовать в стиле хуков (см пакет vue-hooks, или писать свои )

[Alex Wells]

notfun, в продакшен можно, как временное решение. Посидеть на этом слое совместимости несколько месяцев, после мигрировать на vue3.

Answer 2

[Алексей Николаев]

В итоге сделал при помощи декораторов. Оказалось одним из самых удобных решений, особенно в контексте того. что я использую vue-class-property декоратор. От классического hoc'a выгодно отличается тем, что не создает под капотом новый компонент, а просто возвращает конструктор, который затем js сам применяет, где надо.

Выглядит при этом тоже очень красиво.

@Filterable // мой декоратор
@Component({
   // options
})
export default class extends Vue {
   // component logic
}

Answer 3

[Vaulter]

Касательно провайдеров данных : их лучше вывести отдельно в сервисы, и передавать в свойства компонентов. Упрощённое подобие DI/RoC. Перед созданием vue app создаём все сервисы и передаём объектом, с полями равными именам сервисов и значениями равными самим объектам сервиса, в свойство App .