Vue Composition vs Options API. Сравниваем два подхода к написанию кода

С релизом новой версии Vue создатели фреймворка добавили возможность писать код в новом синтаксисе Composition API, благодаря чему у разработчиков появился выбор между двумя различными способами написания кода.

На сегодняшний день Composition API используется преимущественно вместе с script setup – это синтаксический сахар для использования Composition API вместе с SFC (single file component). Примеры кода Composition API далее будут представлены в обоих стилях, но преимущественно без использования script setup. Script setup является следующим этапом в развития Composition API и рассказ о его преимуществах выходит за рамки этой статьи. Тем не менее, ознакомимся с этим инструментом, поскольку он расширяет возможности Composition API и является рекомендованным стандартом для разработки на Vue.

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

Options API:

Composition API (без script setup):

В Composition API область видимости функции setup может содержать в себе всё, что в Options API выносилось в отдельное поле:

• Components

• Props

• Data

• Methods

• Computed Properties

• Lifecycle methods

Пример на методах и реактивных данных:

Options API:

Composition API:

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

Здесь одним цветом выделены взаимосвязанные части кода, которые по смыслу логично группировать вместе. Если шаблонный Options API нас строго в этом ограничивал, то Composition API даёт нам прямое решение этой проблемы: разработчик сам решает, в какой последовательности группировать данные. Увидев количество «разрывов» во взаимосвязанных частях кода на картинке слева, можно сделать вывод о сложной читаемости кода, ведь программисту придётся перепрыгивать от строки к строке, чтобы прочитать одну логически связанную часть кода. На правом участке кода видно, что порядок расположения всех частей компонента полностью совпадает с их логической взаимосвязанностью.

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

Что такое Composable?
Composable - это функция, которая с помощью Composition API инкапсулирует в себе логику состояния (state) для переиспользования в местах, где это может потребоваться.

Допустим, нам нужно реализовать отслеживание координат мыши внутри компонента.

Но что делать, если нам потребуется та же логика в другом компоненте? Чтобы избежать дублирования кода, мы можем инкапсулировать всю логику в composable (пример c официального сайта vue js):

и использовать её в нужном нам компоненте:

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

А как решалась проблема переиспользования логики в Vue 2? Там используются миксины (mixins). Пример:

У старого подхода есть ряд недостатков:

• Неясный источник свойств: при использовании многих миксинов становится неясным, какое свойство экземпляра внедряется каким миксином, что затрудняет отслеживание реализации и понимание поведения компонента. По этой же причине разработчики Vue рекомендуют использовать шаблон деструктурирования (прим: const { x, y } = useMouse()) для composable функций. Это делает источник свойства понятным при использовании внутри компонента.

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

• Неявная связь между миксинами: несколько миксинов, которые должны взаимодействовать друг с другом, должны полагаться на общие ключи свойств (methods, computed, и т.д.), что делает их неявно связанными. При использовании composable значения, возвращаемые из одного composable, могут быть переданы в другой в качестве аргументов, как и в обычных функциях.

На сегодняшний день Composition API прошёл испытание временем и прочно закрепился в качестве современного стандарта разработки на Vue за счёт указанных преимуществ. Разработчик должен уметь писать код в этом стиле, чтобы иметь актуальные знания об этом фреймворке.