Да, пока компонент жив в pinia будет существовать scoped стор и будет лежать рядом с обычными сторами. В имени scoped стора будет содержаться id скоупа, его сложно будет перепутать с другими модулями
По поводу удаления обсерверов - умирает главный родительский компонент и вместе с ним умирают все его дети и следовательно все обсерверы и рефы в них(так как scoped стор используется только в них). Остается только сам стейт в pinia, его я удаляю уже в onUnmounted
Да, модуль стора удалится, для этого добавлен хук onUnmounted, в котором и происходит очистка
Ваш вариант через компоненты тоже интересный, спасибо за коммент! Единственный момент - думаю не всем может подойти создание функциональных компонентов scoped сторов. Есть риски усложнить код + наружу выносится то, что у меня располагается под капотом(и кажется неплохо под этим капотом себя чувствует)). Также сама идея делать из компонента стор будет выглядит немного странновато, если будет сосуществовать одновременно с классическим стором на pinia или vuex(которые используются в большинстве проектов на Vue)
Также стоит отметить, что я не предлагаю заменить все pinia сторы на pinia scoped сторы. Скорее предлагаю инструмент, который можно использовать там, где классический подход pinia не справляется)
Да, но у provide/inject есть свои недостатки, хорошо это удалось описать Илье Климову(с 10:30 минуты, https://www.youtube.com/watch?v=p3vfmNIjmW4). В доке Vue одно время даже был варнинг по его использованию, с чем я согласен и на что мы уже натыкались сами
Реактивные переменные это же и есть состояния. Да, не все из них можно отнести к состоянию всего модуля, но в нашем случае модуль крупный, используется в нескольких местах, состояние соотвественно тоже довольно большое
Также у нас в модуле оплаты из статьи около 10 уровней вложенности
Честно говоря мы пробовали идти по этому пути и именно из-за недостатков выше были вынуждены от него отказаться
Если мы решаем для этих же целей использовать композабл, то вновь возникает проблема хранения состояния для всех компонентов модуля целиком. Нам необходимо, чтобы доступ к состоянию был на всех уровнях иерархии компонентов.
По сути у нас три варианта:
Инициализируем composable на самом верху и прокидываем состояние пропсами вниз. По сути это отказ от централизованного хранилища. Это решение, и даже более чистое, но как мне кажется, достаточно радикальное и также может повлечь за собой последствия в виде props drilling(особенно больно выглядит при большом количестве уровней в иерархии компонентов) и усложнения логики в компоненте. Думаю не каждый на готов пойти на этот шаг и отказаться от Flux архитектуры
Каждый раз заново инициализировать состояние при использовании composable. Тоже кажется не совсем решает нашу проблему и добавляет кучу усложнении логике компонентов
Вынести состояние за composable. Условно создать реактивную переменную-состояние и обращаться к нему внутри composable. Здесь мы сталкиваемся с аналогичными проблемами Pinia, которые я пытался исправить в моем посте
И как мы видим, у каждого из этих вариантов есть свои недостатки
Отказ от централизованного хранилища состояний - тоже решение, и даже более чистое, но как мне кажется, достаточно радикальное и также может повлечь за собой последствия в виде props drilling и усложнения логики в компоненте
В данной статье главной целью было предложить решение для уже устоявшейся концепции
У pinia есть унрегистер? По-моему это было только у vuex. Или вы про $dispose?
https://github.com/vuejs/pinia/issues/557
По onBeforeUnmount подумаем, спасибо!
Да, пока компонент жив в pinia будет существовать scoped стор и будет лежать рядом с обычными сторами. В имени scoped стора будет содержаться id скоупа, его сложно будет перепутать с другими модулями
По поводу удаления обсерверов - умирает главный родительский компонент и вместе с ним умирают все его дети и следовательно все обсерверы и рефы в них(так как scoped стор используется только в них). Остается только сам стейт в pinia, его я удаляю уже в onUnmounted
Модуль стора не будет доступен глобально из за строчки
Взял из api документации pinia
По исключениям - да, от них в целом трудно застраховаться
Да, модуль стора удалится, для этого добавлен хук onUnmounted, в котором и происходит очистка
Ваш вариант через компоненты тоже интересный, спасибо за коммент! Единственный момент - думаю не всем может подойти создание функциональных компонентов scoped сторов. Есть риски усложнить код + наружу выносится то, что у меня располагается под капотом(и кажется неплохо под этим капотом себя чувствует)). Также сама идея делать из компонента стор будет выглядит немного странновато, если будет сосуществовать одновременно с классическим стором на pinia или vuex(которые используются в большинстве проектов на Vue)
Также стоит отметить, что я не предлагаю заменить все pinia сторы на pinia scoped сторы. Скорее предлагаю инструмент, который можно использовать там, где классический подход pinia не справляется)
Хотел как лучше, а получилось как всегда) Исправил
Да, но у provide/inject есть свои недостатки, хорошо это удалось описать Илье Климову(с 10:30 минуты, https://www.youtube.com/watch?v=p3vfmNIjmW4). В доке Vue одно время даже был варнинг по его использованию, с чем я согласен и на что мы уже натыкались сами
Реактивные переменные это же и есть состояния. Да, не все из них можно отнести к состоянию всего модуля, но в нашем случае модуль крупный, используется в нескольких местах, состояние соотвественно тоже довольно большое
Также у нас в модуле оплаты из статьи около 10 уровней вложенности
Честно говоря мы пробовали идти по этому пути и именно из-за недостатков выше были вынуждены от него отказаться
Если мы решаем для этих же целей использовать композабл, то вновь возникает проблема хранения состояния для всех компонентов модуля целиком. Нам необходимо, чтобы доступ к состоянию был на всех уровнях иерархии компонентов.
По сути у нас три варианта:
Инициализируем composable на самом верху и прокидываем состояние пропсами вниз. По сути это отказ от централизованного хранилища. Это решение, и даже более чистое, но как мне кажется, достаточно радикальное и также может повлечь за собой последствия в виде props drilling(особенно больно выглядит при большом количестве уровней в иерархии компонентов) и усложнения логики в компоненте. Думаю не каждый на готов пойти на этот шаг и отказаться от Flux архитектуры
Каждый раз заново инициализировать состояние при использовании composable. Тоже кажется не совсем решает нашу проблему и добавляет кучу усложнении логике компонентов
Вынести состояние за composable. Условно создать реактивную переменную-состояние и обращаться к нему внутри composable. Здесь мы сталкиваемся с аналогичными проблемами Pinia, которые я пытался исправить в моем посте
И как мы видим, у каждого из этих вариантов есть свои недостатки
Спасибо Вам за комментарий!
Отказ от централизованного хранилища состояний - тоже решение, и даже более чистое, но как мне кажется, достаточно радикальное и также может повлечь за собой последствия в виде props drilling и усложнения логики в компоненте
В данной статье главной целью было предложить решение для уже устоявшейся концепции