Мне обычно как-то спокойнее, когда я сразу вижу жизненный цикл объекта. Пиниа стор живет от старта и до закрытия приложения, а "экземпляр" композабла создается каждый раз, как мы его вызываем (условно скажем - в каждом юзающем его компоненте, коих может быть очень много). Может это мои предпочтения, но для меня кажется логичным и удобным такое разделение на синглтон стор и многоинстансный композабл.
А аргумент в медленности reactive по сравнению с ref выглядит немного искусственным. Поправьте, если я ошибаюсь. Я не отрицаю, что разница огромная, судя по бэнчмарку. Но в бэнчмарке было сделан 1миллион операций записи. И в худшем случае получили 800 миллисекунд. Это медленно, но в рамках терпимого. Но это же 1 миллион записей. В каком фронтенде может потребоваться миллион раз перезаписать поле в прокси? (Напомню, это глобальный стейт, который по своей сути не должен слишком сильно разрастаться). В реальном приложении я бы ожидал увидеть десятки, может сотни записей в стор за раз. Но поправьте, если я в этом ошибаюсь.
Плюс pinia над композаблом с глобальным рефом еще и в том, что у пинии явная семантика глобального хранилища, а у композабла это скрыто в реализации. Т.е. никогда не знаешь, этот композабл юзает глобальный стейт или нет. Я как-то решил эту проблему разделением композаблов по папкам: в этой папке композаблы с глобальным стейтом, а в этой с локальным.
А т.к. pinia - это широко известное решение проблемы глобального стейта, то и выглядит оно привлекательней. Меньше шансов нагородить ерунды.
Если приложение маленькое, то можно и на глобальных рефах сделать. Но для большого приложения я бы пожалел тех, кто будет поддерживать код и заюзал бы pinia.
Мне обычно как-то спокойнее, когда я сразу вижу жизненный цикл объекта. Пиниа стор живет от старта и до закрытия приложения, а "экземпляр" композабла создается каждый раз, как мы его вызываем (условно скажем - в каждом юзающем его компоненте, коих может быть очень много). Может это мои предпочтения, но для меня кажется логичным и удобным такое разделение на синглтон стор и многоинстансный композабл.
А аргумент в медленности reactive по сравнению с ref выглядит немного искусственным. Поправьте, если я ошибаюсь. Я не отрицаю, что разница огромная, судя по бэнчмарку. Но в бэнчмарке было сделан 1миллион операций записи. И в худшем случае получили 800 миллисекунд. Это медленно, но в рамках терпимого. Но это же 1 миллион записей. В каком фронтенде может потребоваться миллион раз перезаписать поле в прокси? (Напомню, это глобальный стейт, который по своей сути не должен слишком сильно разрастаться). В реальном приложении я бы ожидал увидеть десятки, может сотни записей в стор за раз. Но поправьте, если я в этом ошибаюсь.
Плюс pinia над композаблом с глобальным рефом еще и в том, что у пинии явная семантика глобального хранилища, а у композабла это скрыто в реализации. Т.е. никогда не знаешь, этот композабл юзает глобальный стейт или нет. Я как-то решил эту проблему разделением композаблов по папкам: в этой папке композаблы с глобальным стейтом, а в этой с локальным.
А т.к. pinia - это широко известное решение проблемы глобального стейта, то и выглядит оно привлекательней. Меньше шансов нагородить ерунды.
Если приложение маленькое, то можно и на глобальных рефах сделать. Но для большого приложения я бы пожалел тех, кто будет поддерживать код и заюзал бы pinia.