Мы все знаем Vuex. Это отличное дополнение к экосистеме Vue с самого начала. Это помогло управлять состоянием в десятках проектов. Он очень многогранен и обширен. Однако для небольших приложений он может быть слишком большим и сложным, а общий поток слишком запутанным и сложным. В то время не было хороших альтернатив. Так что мы привыкли к этому, каждый раз, когда возникала необходимость поделиться некоторыми данными в приложении, мы использовали Vuex.

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

Однако многие разработчики решили пойти по новому пути и использовать компонуемые элементы для совместного использования небольших и реактивных состояний в своих проектах. Оказывается, этот подход довольно удобен и удобен, он может вызвать — из-за глобально открытых объектов данных — некоторые проблемы с безопасностью, а также утечки памяти с/на SSR.

Из-за этого и желания создать что-то менее сложное, как Vuex, без мутаций, коммитов и диспетчеризации данных, родилась идея создания Pinia. Итак, Pinia — это новый, встроенный в Vue 3 (Composition API) механизм управления состоянием экосистемы. Он предоставляет довольно простой API, который может быть похож на прием других решений с шаблонами на основе состояний. Pinia может безболезненно управлять состоянием в вашем приложении, она обеспечивает универсальный и простой поток данных, путешествующих/обменивающихся в вашем проекте. Просто проверьте это… и читайте дальше.

Хотя Pinia великолепна и проста, она добавляет новую абстракцию в ваш процесс разработки — новые хранилища, методы, потоки. И если вы создаете небольшое приложение, оно может быть (все еще) слишком зрелым и слишком сложным для него. Это также индивидуальное решение, которое работает с различными сценариями и весами.

Поэтому, поскольку я большой поклонник Composition API и избавления от этой сложности Vuex, я также был недоволен этим подходом отказа от концепции малых состояний, основанной на компоновке. И вдобавок к этому возникла идея этой библиотеки (составной).

Короче говоря 😏 — Vue Composition API предоставляет что-то под названием EffectScope, которое может записывать все эффекты, созданные во время существования текущего экземпляра. Например, вы найдете там вычисляемые свойства. Что еще более важно, эта область эффектов может быть разделена по всей области приложения. Затем, согласно оригинальному RFC этой функции, мы можем прикрепить к ней любые дополнительные данные.

Вот как и почему была создана библиотека vue-use-state-effect. С его помощью ваш компонуемый объект в любой форме, которой вы хотите поделиться, может быть обернут и соединен. Позже используется в других компонентах. Наконец, без какой-либо дополнительной абстракции вы можете использовать его для создания разделяемых состояний/хранилищ внутри вашего приложения, обрабатывая их с помощью составных объектов с собственной пользовательской логикой. Тем не менее, сохранил родной поток разработки. Потрясающе, верно? В конце концов, чтобы избежать накопления данных, у вас есть утилита destroy, которую вы можете использовать вместе с ней в любое время. Настолько компонуемый, что использует Effect Scope для создания состояния — Vue Use State Effect. ✨

Теперь давайте проверим, как это работает, на реальном примере.

Во-первых, вам нужно — конечно же — установить его, тогда мы сможем создать наш первый компонуемый объект, связанный с данными, с некоторым состоянием и функцией, которая будет его обновлять.

Хорошо, мы можем импортировать vue-use-state-effect и использовать его с нашим вновь созданным компонуемым. Вот так... Обратите внимание, что это один и тот же файл/компонент, я просто повторяю его (фрагмент), чтобы показать следующий шаг импорта компонуемого.

Фантастика. Мы только что создали общий компонуемый объект, который можно использовать вместе с нашими компонентами. Давайте создадим его и проверим, как мы можем его использовать.

Здесь вы можете видеть, что мы получили данные состояния/хранилища из компонуемого. Ключ родительского объекта определяется поверх name, который мы предоставили в составе компонуемой установки. Мы используем вычисляемое свойство для создания реактивного, чтобы отразить его в шаблоне. Кроме того, мы передали метод обновления с помощью, который мы можем использовать вместе с кнопкой для обновления состояния из пользовательского интерфейса. Теперь мы можем создать новую страницу для просмотра/использования сохраненного или обновленного состояния. Как это.

И у нас это есть. Вот и все. Теперь вы можете пойти и использовать свое общее состояние (компонуемое) в своем приложении. В конце концов, если вы хотите очистить эти данные, чтобы не хранить их в жизненном цикле приложения, вы можете использовать опцию destroy для их обработки. Небольшой совет — из-за асинхронного рендеринга компонентов (особенно в Nuxt), если вам это нужно, вы можете получить восстановленное состояние с помощью хука onMounted. Так.

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

Недостатки? Ага. Это просто, поэтому вы не получите структурную форму и плавность, как с Pinia или даже с Vuex. Вы также не проверите это в devtools, но у вас есть режим отладки, который может быть достаточной заменой (надеюсь). Возможно, вы найдете больше, но это не для всех и не для каждого проекта. Это метр определения баланса. 😋

Вы можете загрузить его из реестра npm. Вы можете найти его репозиторий на GitHub. А с демо-версией StackBlitz Nuxt 3 вы можете опробовать его в действии, даже не устанавливая его. Хотите помочь или внести свой вклад, пожалуйста, создайте для этого новый GitHub Issue. Спасибо за поддержку заранее.

Ура и наслаждайтесь. Может, подумайте о том, чтобы купить мне кофе.