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

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

09.07.2023
В этой статье Роман Сикарев, наш старший инженер-разработчик, делает сравнительный анализ Composition API и Options API, раскрывая неочевидные преимущества и недостатки обоих подходов. Статья будет полезна фронтенд разработчикам, использующим в своей работе Vue.js фреймворк.

С релизом новой версии 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:

Vue Compsition vs Options API, изображение №2

Composition API (без script setup):

Vue Compsition vs Options API, изображение №3

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

  • Components

  • Props

  • Data

  • Methods

  • Computed Properties

  • Lifecycle methods

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

Options API:

Vue Compsition vs Options API, изображение №4

Composition API:

Vue Compsition vs Options API, изображение №5

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

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

Vue Compsition vs Options API, изображение №6

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

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

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

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

Vue Composition vs Options API (часть 2), изображение №1

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

Vue Composition vs Options API (часть 2), изображение №2

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

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

Vue Composition vs Options API (часть 2), изображение №3

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

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

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

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

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



Связаться с нами
ДРУГИЕ ПУБЛИКАЦИИ
Участвуем в Рейтинге работодателей HeadHunter
04
10.24
РЕЛЭКС присоединился к масштабному исследованию от HH.ru. Весь октябрь проходит опрос соискателей Ре...
Подробнее..
Форум Цифроземье
26
09.24
5 сентября состоялось главное ИТ-событие региона — форум Цифроземье.
Подробнее..
Внедрять или не внедрять? Рабочая тетрадь по методам и формулам оценки эффективности цифровых проектов
17
07.24
Оценить, как и в какой степени ваш цифровой проект повлияет на бизнес, — это как разгадать головоломку....
Подробнее..