Global store support

[pi0]

With the introduction of composition-API, it makes less sense of using classic vuex store patterns. In the meantime, having a global state (SSR/SPA) is usually required by the projects and with nuxt, we need to provide a built-in integration layer.

While in vue2 ecosystem, vuex was the only option, now we have at least two undergoing projects:

• Pinia (by @posva): https://github.com/posva/pinia (nuxt module: https://github.com/posva/pinia/tree/v2/packages/nuxt)
• Vuex (https://next.vuex.vuejs.org/) and Vuex@5 POC by @kiaking with example nuxt 3 plugin
• Possibility of introducing useStore and more serialize/retrieval utilities into vue 3 core (back portable via @vue/composition-api?) useState

As currently there are not enough data to pick one approach, it makes sense to not directly choose one library but help to make all different store implementations working nicely with nuxt 3 via each own's module and adding examples, docs for them to the framework. This way, store/ support can be added with @pinia/nuxt or @nuxtjs/vuex modules)

When we have a better idea of vue 3's take on the store, we can start drafting built-in store support. Hopefully core, Pinia and Vuex 5 will have almost identical API that we can use it for nuxt 3 layer and allow to switch provider by users.

[AndreyYolkin]

So, some modules like @nuxtjs/auth and @nuxtjs/auth-next require vuex store. It causes some difficulties with migration, even in bridge

[thibautSchmutz]

@pi0 Great idea ! By the way, the doc shows us how to initialize the state but how can we update it ? Also, is the state reactive by default ?

[danielroe]

useState returns a ref that can be mutated. It is reactive. Example:

const myState = useState('myState', () => ({}))
myState.value.test = true

[wobsoriano]

useState returns a ref that can be mutated. It is reactive. Example:

const myState = useState('myState', () => ({}))
myState.value.test = true

Do we type it like how we type a normal ref?

const user = useState<User>('user')

[danielroe]

Yes. 👍

[midblue]

Regarding typing, it seems like typed state elements' types sometimes transfer between components/pages in the app and sometimes don't, which makes sense because it's not always clear which will initialize/access it first. Is there any best practice for declaring state element types in a place that will be guaranteed to communicate their types to other elements of the app?

[mxlpitelik]

Agreed, al my project use Vuex as business logic layer, it super important, but if you add posibility of different stores adding - it will be super!

Because type difinition in vuex is HELL :(((

P.S. - MobX with proxies superfast now....

[wobsoriano]

er important, but if you add posibility of di

well there's pinia if type defs is ur problem

[maximilianmikus]

Having clear goto solutions is a big plus for the vue/nuxt ecosystem. I think its better to support one standard solution everywhere. This creates more synergies with other projects/modules (e.g. with vuex used basically everywhere). It would also be easier to migrate v2 apps hopefully.

[jmroon]

Considering Pinia is becoming the official recommendation in the new vue docs, I believe that should be the supported standard at a minimum:
https://staging.vuejs.org/guide/scaling-up/state-management.html#simple-state-management-with-reactivity-api

[Lycoon]

Is there any update regarding this for its replacement into Nuxt?

[woutercouvaras]

I found this thread asking the similar questions - looks like it's pretty easy to set up and get going: https://pinia.vuejs.org/ssr/nuxt.html#installation

It might not be the default, but in the world of riding the "bleeding edge" wave of tech, this seems like a low barrier to entry.

[danielroe]

This is a PR to follow: vuejs/pinia#791

[mpietrucha]

When I started build first app with nuxt3 I discovered that keeping store modules in composables directory will be very messy in the future. So I created very small package that add auto imports from store directory. Works well with pinia.

https://github.com/mpietrucha/nuxt3-store-autoimport

[richardeschloss]

FWIW, if anyone is looking for Vuex support, I just released a module: https://github.com/richardeschloss/nuxt3-vuex . This will let you keep using your Nuxt2 "store" folder in Nuxt 3 (with some added features). This may come in handy if you have a massive Nuxt2 project (with a massive store) you wish to migrate to Nuxt 3 🚀 🚀 🚀

[MartinX3]

Thanks, but vuex is deprecated by pinia.
Pinia works just fine with nuxt2/bridge/3.

[richardeschloss]

@MartinX3 Pinia is great but there are some breaking changes that wouldn't allow existing Vuex-based store folders in a Nuxt2 project to work. This module was created to support those [very large] legacy projects which may have many files in their store folder which consist of mutations. Upgrading to Pinia would require all existing code that depends on mutations to be updated (i.e., all $store.commit calls, potentially 100s of them). I'm not sure how many of those projects want to risk changing their existing global store all at once, even if the change is for the better.

This module would help make a migration easier and risk-free by allowing a Nuxt2's existing store to work, and at the same time, by referencing this discussion thread (in the project's readme), suggest how to incrementally upgrade their state management out of Vuex.

[vedmant]

@richardeschloss Hey, did you delete your repository?

[vedmant]

If someone needs this, I restored this repo https://github.com/vedmant/nuxt3-vuex also added SSR support and nested stores support

[richardeschloss]

@richardeschloss Hey, did you delete your repository?

Github: yes, npm: no (with a deprecation note).