Comments 15
Вы могли бы не стесняться и указать, что являетесь автором поста на реддите.
Плюс pinia над композаблом с глобальным рефом еще и в том, что у пинии явная семантика глобального хранилища, а у композабла это скрыто в реализации. Т.е. никогда не знаешь, этот композабл юзает глобальный стейт или нет. Я как-то решил эту проблему разделением композаблов по папкам: в этой папке композаблы с глобальным стейтом, а в этой с локальным.
А т.к. pinia - это широко известное решение проблемы глобального стейта, то и выглядит оно привлекательней. Меньше шансов нагородить ерунды.
Если приложение маленькое, то можно и на глобальных рефах сделать. Но для большого приложения я бы пожалел тех, кто будет поддерживать код и заюзал бы pinia.
А зачем вам знать, что внутри композабла? Это сервис, у которого есть интерфейс (то, что его функция возвращает), есть грубо говоря документация, описывающая его.
SOLID, буква О - программные сущности должны быть открыты для расширения, но закрыты для изменения. Что внутри них и как работает не должно иметь значения для пользователей этой сущности.
Мне обычно как-то спокойнее, когда я сразу вижу жизненный цикл объекта. Пиниа стор живет от старта и до закрытия приложения, а "экземпляр" композабла создается каждый раз, как мы его вызываем (условно скажем - в каждом юзающем его компоненте, коих может быть очень много). Может это мои предпочтения, но для меня кажется логичным и удобным такое разделение на синглтон стор и многоинстансный композабл.
А аргумент в медленности reactive по сравнению с ref выглядит немного искусственным. Поправьте, если я ошибаюсь. Я не отрицаю, что разница огромная, судя по бэнчмарку. Но в бэнчмарке было сделан 1миллион операций записи. И в худшем случае получили 800 миллисекунд. Это медленно, но в рамках терпимого. Но это же 1 миллион записей. В каком фронтенде может потребоваться миллион раз перезаписать поле в прокси? (Напомню, это глобальный стейт, который по своей сути не должен слишком сильно разрастаться). В реальном приложении я бы ожидал увидеть десятки, может сотни записей в стор за раз. Но поправьте, если я в этом ошибаюсь.
Тесты проводились на элементарных данных.
Теперь представим что мы грузим массив из 1000 продуктов в админку, каждый продукт - объект со многими уровнями вложений данных. Далее, зависимостей от этого массива тоже может быть с десяток в приложении, и каждая из них имеет свои зависимости. То есть, при изменении этого массива, грубо говоря, объем кода, который должен исполниться, растет экспоненциально, а с ним и падает в таком же порядке и производительность
С другой стороны, возьмем не мощный смартфон и висящие у него в фоне программы, которые, тоже ощутимо увеличат разницу в производительности.
На Ref, ShallowRef и других фичах Reactivity API наверняка можно сделать более оптимизированное приложение так, что вышеуказанная разница примет весьма ощутимые размеры.
Ну и не забываем, что Vue, Svelte и другие соревнуются между собой на проценты, кто кого быстрее. Так что даже они важны.
Я пока что не дочитал документацию до composable — некогда, нужно проект делать :) Когда всё же удаётся почитать документацию, то в новые части проекта добавляются разные штуки, которых раньше не знал. Просто, когда я устраивался на текущую работу, 3-й Vue не так уж сильно давно появился, а когда я стал работать, то стало не до учебников, но новые проекты изредка нужно начинать, а делать их на второй версии не хочется, надо же и третью понемногу осваивать, а то когда же я её освою?
В продуктовом решении используем пинью и в большом легаси на vue2 - vuex. Но для себя в пет проекте чисто ради эксперимента попробовал юзать композаблы с глобальным стейтом и соглашусь с автором, это бесшовно (refs сразу без приведения) и удобно, можно растащить такие глобальные сторы по функц. модулям, и инициализировать когда чанк первого использующего композабл компонента запустился у клиента(это антипатерн, но как по мне удобно в модульной архитектуре хранить стор внутри модуля). Сразу вспомнилось чем в своё время зацепил, ныне почивший, knockout, там по сути так и реализовывался глобальный стейт ;) Спасибо, тема интересная!
А в связке с Nuxt интересно этот подход кто-то применяет? В доках написано "Never define const state = ref() outside of <script setup> or setup() function.
Such state will be shared across all users visiting your website and can lead to memory leaks!" https://nuxt.com/docs/getting-started/state-management
Vue state management: Pinia stores или composables с глобальными рефами?