Интересный пример использования TypeScript класса в качестве стора через composable

Дает возможность использовать приватные поля, сеттеры и геттеры (без .value), first class type support

Не в качестве рекомендации, но как демонстрация того, что возможно с Composition API

#ts #tip #pinia

Интересная дискуссия по теме "Pinia сторы против глобальных рефов" прошла на Reddit-e.

Плюсы composable сторов на глобальных рефах заявлены как:
1. Простота
2. Нативность по отношению к фреймворку
3. Отсутствие зависимостей означает отсутствие будущей ситуации "RIP Vuex" с переписыванием 50% кодовой базы проекта
4. API Composition выглядит очень зрелым и стабильным и вряд ли сильно изменится в ближайшем будущем (по сравнению с переходом Vue 2 -> Vue 3).
5. Позволяет использовать всю мощь Reactivity API вместо жесткой Reactive обертки для переменных у Pinia. Разница в производительности может быть огромной.

Выводы:

1. Большинство согласилось, что если не нужна поддержка SSR и интеграция с Devtools, то работа с Reactivity API напрямую и инкапсуляция реактивного состояния и бизнес логики в composable функции вполне возможна. Для многих это лучше использования Pinia.
2. Работа с Reactivity API позволяет делать многое, что не позволяет Pinia - например, делать сторы на TypeScript классах, как описано в предыдущем сообщении.
3. Был предложен лайфхак - во время разработки импортировать реактивные данные из composable сторов в Pinia, и тогда возможно использование Devtools. При билде для продакшна Pinia уже нет.
4. Единственный аргумент в пользу Pinia - унификация работы со стором в команде.

#pinia #architecture

Pinia cheatsheet (Option stores)

#pinia #cheatsheet

Pinia Colada появилась и как Nuxt модуль

Сколько в Nuxt уже [неправильных] способов заменить fetch(), включая Tanstack?

#pinia #nuxt

Автор Pinia делится секретом костыля для создания private переменных в сторе

Путем построения еще одного стора

И насколько же легко и естественно все это делается в модульных рефах. Возможность сделать private state - еще один плюс, - и очень жирный - в их копилку.

Private state - это инкапсуляция и возможность использовать принципы ООП

#pinia #oop

Написал статью "Обзор различных методов работы с реактивным стейтом во Vue"

Переделанная вот эта. Исправлены фундаментальные ошибки (автор не понимает, что такое composable функция) и некоторые другие недочеты

Внизу статьи опрос, просьба проголосовать.

Также размещено на Vue-FAQ

#reactivity #pinia #eventbus #article

Зачем Pinia, если можно написать свой стор?

Захотелось ответить на очень однобокий взгляд вот здесь - https://t.me/vuejs_ru_feed/37

Во-первых, это не велосипед, а решение под нужды своего проекта.

1. "Унификация и единый API". А давайте всех побреем и будем ходить строем. Сперва под Options API ходили, под Mixins API, под Vuex API, а теперь под Pinia API. Все, что было раньше и теперь на свалке, очевидно, было сразу плохо и временно, а вот Pinia API - это круто и навсегда, конечно

2. Нет, копию Pinia делать - это глупо. И никто это не делает. Надо решать задачи приложения, и без ограничений "единого API Pinia" они решаются проще, удобней, правильней и намного более функциональней при необходимости

3. Кроме ES модулей реализовать паттерн Singleton можно еще несколькими способами, если в этом есть необходимость по архитектуре приложения.

4. BFF SSR - зло и труп. Оставьте его врагам.

5. Какая-то надуманная проблема. Вы пишете сайты на десятки тысяч DOM элементов, а потом беспокоитесь, очистит ли GC покупательскую корзину, на которую [не] осталось ссылок?

6. А зачем очищать "глобальный стор"? Что под этим имеется ввиду, и как часто это надо делать? user = null; - это очищение стора? Свой стор не очищается при необходимости одной строчкой?

Еще раз, если у тебя в реактивных переменных столько данных, что они съедают значительную часть памяти веб-приложения и тормозят его - значит ты делаешь что-то не так. Эван для этого и придумал Reactivity API, возможности которого Pinia сильно обрезает.

И, нет, память это не освободит, а пометит для GC, который вряд ли на этом сработает в большинстве случаев.

7. Почему они должны быть объединены?

9. Реклама чужих велосипедов, таких же порой неправильных, тормозных и ненужных, как и во VueUse, в попытке сделать из Vue конструктор для вкатунов

10. Такое пишут люди, которые привыкли к Pinia и к её формату. Никаких проблем в работе в DevTools с обычными ("глобальными") реактивными переменными нет.

Ну и определять архитектуру приложения на основе своих предпочтений работы в DevTools - такое.

—

У не-Pinia решений есть плюсы. Ты не ходишь строем, а ходишь, как тебе удобно, используя в полной мере Vue Reactivity API.

—

На самом деле в оригинальном посте пропущен главный пункт, такой же как с Накстом:

11 . Когда в команде много слабо квалифицированных программистов, которые могут написать дичь, удобно всем ходить строем.

Ответ:

11. Повышайте уровень своих джунов до уровня проекта, а не опускайте проект до уровня джунов.

#pinia #reactivity