В прошлом месяце я опубликовал спорную статью, в которой обсуждал множество недостатков написания и масштабирования веб-приложения с использованием Vue.

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

Сначала это казалось многообещающим. Composition API, разработанный для упрощения повторного использования логики и улучшения поддержки TypeScript, концептуально напомнил мне React Hooks. Действительно, команда Vue говорит, что хуки были большим источником вдохновения для Composition API.

Я был уверен, что его сходство с хуками означает, что я смогу быстро изучить новый API и полюбить его так же сильно, как я люблю хуки. Я ошибался в обоих случаях.

Но прежде чем обсуждать эти проблемы, я попытаюсь защитить Composition API и его мотивы.

Миксины… грязные

В старых версиях Vue единственным способом повторного использования логики между компонентами был миксин. Миксины позволяли вам определять методы, вычисляемые свойства и другие повторно используемые фрагменты кода, которые вы могли вызывать из любых компонентов с помощью простого импорта.

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

Чтобы решить проблему повторного использования логики, вместо миксинов React представил функциональные компоненты и API-интерфейс Hooks, которые сразу же подхватило сообщество React.

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

Я был очень оптимистичен, что этот новый API решит основные проблемы Vue. По большей части это так… но это также создает их больше.

Учиться нелегко

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

Мой первый час изучения Composition API был полон замешательства и разочарования. Я быстро понял, что, поскольку у Vue есть настоящая реактивность — чего нет у React — этот новый API требует радикально отличной от хуков ментальной модели.

И что еще более важно, в то время как в React есть только несколько фундаментальных хуков, Composition API представляет множество различных служебных функций для создания реактивных переменных, наблюдения за этими переменными, вычислений на основе этих переменных и для запуска кода в разных точках жизненного цикла компонента.

Например, есть два способа создать реактивную переменную: ref и reactive. Какая разница? reactive не может содержать примитивы, в то время как ref тоже может, но ref не является глубоко реактивным. Кроме того, вы несете ответственность за отслеживание того, какие переменные являются реактивными и являются ли они глубоко реактивными.

React, с другой стороны, имеет только один хук с очень простым API для этой цели: useState. (useReducer тоже существует, но useState — это все, что вам нужно в большинстве случаев.)

Что делать, если вы хотите посмотреть реактивную переменную в Composition API? Вы можете использовать watch, который может отслеживать ссылки, реактивные объекты или геттерную (вычисляемую) функцию, но для просмотра свойства реактивного объекта вам нужно использовать геттерную функцию. Если вы хотите запустить побочный эффект немедленно, ипри изменении реактивной переменной, вам нужно использовать watchEffect .

Аналог React — useEffect, который также имеет некоторые запутанные особенности, но предоставляет гораздо более простой API.

Теперь также есть три совершенно разных способа определения компонента Vue: API параметров, API композиции с функцией setup() и API композиции с волшебным сокращением <script setup>. Это означает, что вы должны принять больше решений, которые могут привести к непоследовательности или вызвать сожаление в будущем.

Таким образом, хотя Composition API предлагает большую гибкость и полезность, он также вводит сложность и крутую кривую обучения.

Но некоторые будут — и многие уже — открыто приняли этот новый API. И это нормально. Я уверен, что после освоения он будет таким же мощным, как и хуки.

Большую озабоченность здесь вызывает то, что все это означает для будущего Vue.

Дом разделен

Composition API в значительной степени решает многие проблемы, для решения которых он был предназначен. И все же многие разработчики Vue по-прежнему отказываются его принимать. Они утверждают, что для их вариантов использования его преимущества просто не стоят затрат на обучение и дополнительную сложность. Те, кто принимает его, часто делают это лишь частично, оставляя многие из своих компонентов с помощью API параметров.

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

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

И оба хотят использовать одну и ту же библиотеку.

Пока и в обозримом будущем это возможно. Оба API поддерживаются и совместимы в рамках одного проекта.

Но разделенный дом не может устоять. Когда React выпустил Hooks, стало ясно, что команда React хотела, чтобы библиотека двигалась именно в этом направлении, и (почти) всем это нравилось. Те, кто не просто ушел из React в пользу других библиотек, таких как Vue.

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

Конечно, все это не означает, что Vue обречен на провал. Напротив, это прекрасная возможность для Эвана Ю и компании написать новый путь развития Vue. Но трудно представить то, что не расстроило бы многих людей.

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter и LinkedIn. Посетите наш Community Discord и присоединитесь к нашему Коллективу талантов.