Статьи серии
В данной статье мы подведем некоторые итоги по вопросу повторного использования кода, который освещался с разных сторон на протяжении нескольких статей. Вспомним более давние статьи на эту тему. Также на основе этой информации определим есть ли во Vue.js наследование.
Содержание
- Почему именно наследование?
- Mixin и Extends
- Composition API
- Слоты
- Свойства
- Итоги
- В следующих статьях
Почему именно наследование?
Когда мы хотим повторно использовать наш код в несколько иной ситуации, первое, что приходит в голову, обычно, – наследование. Поэтому программисты, которые используют Vue, часто хотят найти именно наследование, когда им нужно переиспользование. Но по факту это не единственный и не всегда самый подходящий способ достичь озвученной цели.
Mixin и Extends
Какое-то время назад в статьях обсуждались миксины (mixin), которые позволяют пользоваться наследованием. При этом наследование может быть множественным. Это полезно, так как в реальности какая-либо сущность обычно состоит не в одной группе, а в сразу в целом ряде.
Однако миксины не идеально решают задачу повторного использования.
Во-первых у них есть недостатки:
- коллизии имен методов и свойств. Когда разные миксины имеют части с совпадающими именами.
- неявные зависимости. Методы миксинов могут зависеть от переменных, которые должен предоставить компонент.
Во-вторых за счет миксинов мы не можем немного видоизменять шаблон. Миксины не дают, сами по себе, способа унаследовать большую часть шаблона немного изменив частности.
Стоит упомянуть также extends. С помощью него мы делаем миксин из готового компонента. Он также будет иметь все недостатки миксинов.
Composition API
С приходом Vue 3 появился способ включать в компонент совокупности методов и реактивных переменных. По факту мы получаем то, что нам давали миксины, но с решением озвученных недостатков. Здесь мы не используем наследование. Мы используем композицию. Подробнее в отдельной статье о Composition API.
Слоты
Однако остается вопрос повторного использования шаблона. Если большая часть шаблона годится для группы компонентов, но небольшие кусочки могут отличаться, то как поступить в этом случае?
В этом случае шаблоне можно было бы предусмотреть точки расширения с помощью слотов (scoped slots). Имея их мы могли бы оборачивать наш компонент другим, передавая ему недостающие фрагменты шаблона. Это будет очень похоже на наследование. Такой принцип описан в статье Таблица на Vue 3. Добавляем Scoped Slots. В ней мы расширяем базовую функциональность компонента-таблицы за счет слотов.
Слоты можно использовать и когда компоненты вложены друг в друга несколько раз. То есть когда мы имеем более двух уровней в иерархии. Подробнее рассказано в статье о продвинутой работе со слотами.
С помощью слотов работает и прием Renderless Component (компонент без отображения). Но имея в арсенале Composition API вы вряд ли прибегните к первому.
Свойства
Если вспоминать инструменты, которые нам помогают в повторном использовании кода, то, конечно, свойства – один из них. Через свойства можно передавать данные для отображения, настройки компонента, функции, а также простые шаблоны. Это детально разбиралось в статье про улучшение возможностей повторного использования компонентов. Это, пожалуй, – база. Стоит в этом разобраться.
Итоги
И так, как мы видим, наследование в Vue есть. Это – mixins и extends. Но использовать его как есть – проблематично.
В нашем распоряжении есть гораздо более широкий инструментарий, в который включает Composition API и Scoped slots.
С помощью Composition API мы можем внедрять в компоненты нужные методы и связанные с ними реактивные переменные.
С помощью Scoped slots мы можем использовать как базу шаблон компонента и добавлять в него дополнительные блоки делая компоненты-обертки для данного. Последнее будет очень похоже на наследование (но не является им).
В следующих статьях
Тема повторного использования кода, как всегда, актуальна. Она, на мой взгляд, в данный момент, уже неплохо раскрыта в серии статей. До появления новых мыслей эту тему поставим на паузу. Жду ваших комментариев, если есть вопросы и возражения.
В следующих статьях я бы хотел обсудить передачу данных в иерархии компонентов на несколько уровней. Кода у нас более чем два уровня, данные передавать через события и свойства становится все сложнее. Здесь пригодятся другие подходы и мы их рассмотрим.