Pinia is made by @posva, a core team member, so we had lot of discussions internally and Vuex 5 is very much inspired by Pinia 👍

@kiaking Then shouldn't You two just connect efforts and work together somehow? ;)

We already do, lol

@posva of course I mean working on single library ;)

I like that @kiaking is contributing on pinia, for two reasons:

1. Vuex has similar name to Flux for a reason: they copy their api from them, so forcing v5 would be confusing
2. Vuex already is compatible with vue 3, no real pressure there.
3. if you release Vuex 5 as a totally different product from Vuex 4 you will have the issue that many other frameworks/libraries have had, like angular with angularjs... they should've simply used a new name

I can see a future where some people will stick to Flux-like Vuex for many years, while others will prefer Pinia. And, releasing Vuex 5 with pinia's concpts would kill any possibility for Vuex 4 to have a future in its own path.

I vote: keep Vuex 4 for people who like it, push Pinia for people who like composition.

Note: I just saw a video in Vue Toronto in Youtube where Even You @yyx990803 recommended Pinia as the official Vue 3 store.

We need to have effectScope implemented in order for Vuex store to work completely! Otherwise, computed reactivity will be lost when a component gets unmounted 👍

Is there a rough timeline already for Vue 3.1 - and also Vuex 5 GA?

Not at the moment, but Vue 3.1 should be not that far. For Vuex 5 GA, not sure 😅 But hoping to make at least alpha release soon enough!

So store is lazy initialized right? When the store first called.

You can use Composition Store if you don't want use this 👍

In Vuex 5 the separate store would be separate Vuex instance I guess. While it's possible to create multiple Vuex instances, currently not expecting to inject multiple Vuex instances into Vue app instance.

Because in Vuex 5, unlike Store in Vuex 3&4, Vuex instance is just a container for multiple stores. And stores are registered under vuex instance, but each store has nothing to do with other stores.

Therefore, unless you have more than 1 vue app instance, I'm not sure if it make sense to have multiple vuex instances.

Can you elaborate a bit more on your use case? Why do you need more than one Store in Vuex 3? And maybe I can think deeper if that also applies to Vuex 5, or not 🙏

I am using Vuex Orm in the background 😉 Now this specific part of the app queries the API for a very speific timeframe (past, present or in the future) but the rest of the app is only in the present. Because these time dependent models should not interfere with the existing present models (they should not override or in any other way manipulate existing models or creating new ones) I have them in a separate Vuex.Store.

I was also thinking about multiples stores of same type when I saw the 'key' attribute inside the store config. I'm not sure how the 'key' relates to everything, but would it make sense to move the key as a first parameter to defineStore() ?

@UncertaintyP Ah I see. I think it wouldn't matter in Vuex 5. Because in Vuex 5, each stores are separate stores. It will registered under same Vuex instance, but Vuex instance has no dispatch or commit that can do something to the registered store. So in your case, I think there's no point of having multiple Vuex instance anymore 👍

@goeh key is unique identifier for the store. For example, when we call useCounter twice, it should retrieve the same store each time. key is used for that.

would it make sense to move the key as a first parameter to defineStore()

Good point. In Composition Store, it's in the 1st argument. For Option Store, technically we can also have it as a 1st argument. But I feel like having it as a key property in object feels a bit more natural because it's similar to name property in Vue Component. But, not I also think it does also make sense to have it as the 1st argument. This might be subjective topic, but indeed tough choice to make 🤔

from a dx experience, if you are passing an object as the second argument and the object is always there, it makes more sense to also group the key with the other options.

// did I have to use a first argument?
defineStore('user', {
  state: () => ({})
})

// only one argument, if any key is missing, errors will be clearer in JS
defineStore({
  key: 'user',
  state: () => ({})
})

For the function syntax that's a different story but having a unified syntax makes sense too I think

Declarative store bindings (actions: ['foo/someAction'] in options root, compared to ...mapActions(['foo/someAction']) in computed.

Is this about you want mapActions in Vuex 5 as well? If yes, it's documented in Alternatives section. https://github.com/kiaking/rfcs/blob/vuex-5/active-rfcs/0000-vuex-5.md#alternatives

But yes, if we have high demand for it, we can implement mapActions or mapGetters helper functions.

Dependency Injection. Right now you'll have to mock imports to unit-test your stores. These dependencies also have no contract which can lead to issues when refactoring.

Good point. Dependency injection, you mean when doing store composition? In that case I think the same best practice for testing generic composition API could work (which I'm not sure if we have at the moment). Do you have any good example code illustrate the dependency injection problem?

I am also not a fan of global mixins on Vuex (called Plugins in RFC), I am not convinced this is needed in Vuex since it adds unnecessary responsibility which should be in its own layer abstracted from Vuex and does not operate on the same level of abstraction as data management (this.foo = await repository.getList() vs this.foo = this.$axios.get('/foo')).

Maybe. But there might be good use case where you want to "inject" some property into Vuex instance. For example injecting axios instance like in RFC example. Because otherwise you must pass those dependency through argument.

// If we don't have global mixin plugin, we must do this.

export default {
  computed: {
    ...mapStores([
      usePost
    ])
  },

  methods: {
    fetchPost() {
      // Pass axios as an argument, because store don't have access without plugin system.
      this.post.fetch(this.$axios)
    }
  }
}

When you do this.foo = await repository.getList() , where is this repository coming from? If you are doing import { repository } from '@/somewhere', in this case, if the repository is stateless object, then it should be fine, but if the respository is stateful object, we can't do this because it might cause state leak in SSR app.

If repository is stateful object, then you must "inject" that object to Vuex, or to Vue app and pass it to Vuex. For example axios is stateful object (you can set like global config), so it make more sense to inject it in the store as a plugin.

What do you think?

Is this about you want mapActions in Vuex 5 as well? If yes, it's documented in Alternatives section.
https://github.com/kiaking/rfcs/blob/vuex-5/active-rfcs/0000-vuex-5.md#alternatives

Quite the opposite, I don't want mapActions, but I want declarative mappings right in components options:

export default {
  actions: ['foo/bar'], // the exact API could vary
  methods: {
    callStoreAction() {
      this.bar();
    }
  }
}

Do you have any good example code illustrate the dependency injection problem?

The problem is that we define exact imports we want to mock, instead of mocking the actual stores in the dependencies.

// bar.js
import fooStore from './foo.js'

export default {
  use: [fooStore],
  getters: {
    foo() {
      return this.foo.value;
    }
  }
};

Then we'd have to test it like that:

import { createVuex, defineStore } from 'vuex';
import fooStore from './foo.js';
import barStore from './bar.js';

jest.mock('./foo.js', () => ({
  default: {
    name: 'foo',
    state: { value: 1 }
  }
}))

it('works', () => {
  const useBarStore = defineStore(barStore);
  const vuex = vuex.store(useBarStore);

  expect(vuex.bar.foo.value).toBe(1);
})

Instead of testing it like this:

import { createVuex, defineStore } from 'vuex';
import barStore from './bar.js';

const fooMock = () => ({
  name: 'foo',
  state: { value: 1 }
});

it('works', () => {
  const useBarStore = defineStore(barStore);
  const vuex = vuex.store(useBarStore, { foo: fooMock() });

  expect(vuex.bar.foo.value).toBe(1);
})

I understand that this requires having an interface which itself is pretty complicated and some simplification might take place.

Maybe. But there might be good use case where you want to "inject" some property into Vuex instance.

I think this can be resolved using functions and arguments (as demonstrated above). Having this.$axios is not something you'd want in your codebase because it's not Vue or Vuex related dependency and I can't think of a reasonable explanation why it should be passed down as a property on global context. I can think of something like $translate for getting translations that depend on current language (which is set using store), but even in that case this should be decoupled from store and using arguments or direct imports with passing language as argument.

Quite the opposite, I don't want mapActions, but I want declarative mappings right in components options:

Ah I see. We did think about that, but unfortunately it can't be typed 😓 If it becomes typable in the future, I would really love to have direct options as this example.

About dependency injection.

The jest.mock example was exactly what I was thinking for testing. I think passing an argument when instantiating a store like vuex.store(useBarStore, { foo: fooMock() }); is not possible for Vuex. Because Vuex store is a global store. It will be called multiple time in multiple component. And every call to vuex.store must return exact same store. Hence we shouldn't be able to pass in argument for store creation.

const counterA = vuex.store(useCounter)
const counterB = vuex.store(useCounter)

// Both counterA and counterB must be same instance.
// If we have argument, something is gonna break.

const counterA = vuex.store(useCounter, { foo: fooStore }) // with argument
const counterB = vuex.store(useCounter) // Without argument. What's going to happen here...?

I think this can be resolved using functions and arguments (as demonstrated above). Having this.$axios is not something you'd want in your codebase because it's not Vue or Vuex related dependency...

Maybe? But if you don't want to use it, you don't have to use plugin that way. You are free to pass those dependencies as an argument. But as of Vue, we do quite often inject things into Vue instance. And again, if you don't like this approach, you don't have to do it 👍

export default {
  actions: ['foo/bar'], // the exact API could vary
  methods: {
    callStoreAction() {
      this.bar();
    }
  }
}

So no more having to specify all the things you want in an array and then destructure to use? 🤯 Sign me up! Can I have it today? lol

Understandable! I agree with many things in the comment such as faster development cycles. But, we've still promised users that Options API will not disappear anytime soon. We would like to avoid forcing options api users to learn Composition API, because that essentially means that if users want to use Vuex, they have to learn composition api.

just recommend Vuex 4 if you want options syntax.

I think Vuex 5 has to huge API change to make users stick to Vuex 4. Also Vuex 4 is not Options API version Vuex 5, it's totally different library 😓

If I'm not mistaken, the long-term goal for Vue is to see options API gradually disappear in favor of composition.

We don't know that yet. Maybe in the future, that's what might happen. I don't know. If it does, for example if Vue 4 drops Options API, then I agree Vuex 6 should also drop options API. But we still need more time to decide.

For example, when it comes to store serialization/hydration, Options Store works much better than composition api. It works without any downside, where Composition Store requires strict developers discipline, such as they have to remember to expose all properties.

So, Options API does have advantage over Composition API. And I believe we're not in the stage where we can decide to drop Options API yet.

That's been said, I do understand your point, and it does make sense too! Thanks for the feedback 🙌

Fair points!

I certainly understand the decision to keep both types of syntax. Hopefully I wasn't coming across as critical, I was just exploring the possibility to having one way of doing things. I also did not know about the promise to users of not removing the options syntax.

Thanks for pointing out the obvious advantage of options when it comes to serialization. Definitely made me realize that composition syntax is not the clear winner yet.

Both proposed composition and options API changes are a huge improvement. Thank you very much for the hard work!

@kiaking is new Vuex treeshakeable? I mean do I need to load Options API part even if i use only Composition API and vice versa?

@jacekkarczmarczyk Not sure yet. It would be cool to have remove the options api code from the production build. But still not sure. If it makes things too complicated or confusing, it might just be better to include it in the bundle because the size should be really small anyway 😳

Making the Options Store a separate plugin will also give some idea of how many people are downloading and using it. In my opinion, if you're using Vue3 and Vuex5 in an application, you're more than likely taking advantage of the Composition API, it just makes logical sense when you're building applications that are more involved.

Actions can be both synchronous and async. In you case you can just create 2 actions 👍

Good point! Actually yea Vuex injects different stuff to Vue component as well so it's possible to use Vuex 4 and Vuex 5 at the same time 👀 Maybe its worth publishing vuex-4 package just for this purpose 😃

2 way you mean Options syntax and Composition syntax? It applies the same for Vue 3 so I think organizations can follow the same rule they have with the Vue Component 👍 That's being said, I do understand your concern, and it's something we need to figure out for whole Vue 3 ecosystem. And for example if Vue core has any movement for this, Vuex should follow the same path.

I think for Vue 3 to keep options API has more good reasons than keeping it in Vuex. With Vue, there is a lot of documentations / blog articles etc out there that uses options API, so it is beneficial to the user as a new learner to be able to use that information and use it regardless of them using v2/v3. That is to Vue 3 being mostly backwards compatible to Vue 2.

With Vuex 5 on the other hand, that logic does not really apply, as the whole logic is different (skipping commits), that old docs/blog articles will not work with the new version.

Still, I think the options API will be easier to understand for newcomers, so that would be for me one reason to keep it in the core.
But I would also question whether it wouldn't be good enough to just make options API a separate package.

Good point. But as long as Vue 3 supports options API, I think Vuex should also follow. Because if we drop Options API from Vuex, people "have to learn Composition API". That's what we want to avoid.

I too think making options API as a separate package makes sense, it aligns with Class Component plugin as well. If for example Vue 4 takes that path, I think Vuex should do the same 👍

Interesting! I think this looks really nice as a plugin. I think it would make more sense to have Options API and Composition API as a core and Class style as a plugin to align with Vue 3 👀

Yes this is something we need to tackle as well. Thanks for the mention! Let's open a discussion when this RFC is more fixed. We do have few ideas (just an idea and not solid yet) but we definitely need more discussion on this topic.

Not sure we have a new discussion or not but I would like to apppend a few my ideas. My main confusion about "mutation vs action" before was around the async capability and access to other modules. So my team have been using only async actions and combined them with server API requests. My sueggestions:

1. Reconsider the change of deprecating mutation but keep action still sync or async same time. It might be trouble for developers, to determine the vuex operation as purely client side or possiblly touch server side, when at component context.
2. As for data hazard issue, it looks like transactions when accessing a database, maybe vuex or addtitional library (i prefered) could add a function for the transaction pattern "do getters and accquire locks for partial state, do server requests, and do mutation as well as release locks", the locks can target to low-level reactive objects and fail or warn the access during ongoing transactions.

P.S. I think the data hazard issue maybe out of vuex scope. Because it is actually rooted in JS single-thread and event-drivent runtime model. And from vue's "progressive enhance" principle, it might complicate vuex itself to deal with this issue.

Defining here is the correct term (like defineComponent and defineStore). Note the RFC is meant to be precise in the detailed section. The vocabulary should be closer to implementation details than it will be in docs

@sylvainpolletvillard

This is very neat compared to the Options API that requires to call vuex.store or mapStores. Could you explain why directly calling the store definition like this is not possible for the Options API ?

useCounter will use inject API to retrieve the vuex instance which is injected in to the Vue app instance, and it's only accessible inside setup hook. So, you could mix it with options API though.

export default {
  setup() {
    return {
      counter: useCounter()
    }
  },

  methods: {
    increment() {
      this.counter.increment()
    }
  }
}

Ah interesting. Thank you for pointing out. Yeah I think this kind of code reuse might be better to be done with Composition API. But this is interesting. I don't know if we want this in the initial release, but if we have high demands for this, we should think about it 👀

1. No, because that wouldn't have automatic types
2. All stores are registered dynamically by design the first time useStore() is called

I see, if so I think maybe a global store which can access to any store or a dispatch function(like the old one) maybe useful at some situation, like if we design a low code system, we didn't define all store at development, cause we don't know what user really needs, so we need to wait to user draw the page prototype, then we can define the new store for the page, but all this operation is online, so we can't import the store we need to use, we may can use newStore = vuex.store({ config }) to create current page's store, but if it needs another store like userInfoStore to provide userinfo, I think we can't do that, cause we can't import another store online, right?

some code as follow:

user define this online 

const userCondfig = {
 state: {
   count: Number
 },
 getters: {
   plus: () => state.count + 1
 },
 action: {
    increment () {
     // some user logic
    }
 }
}

then we can transform to vuex store like

const createStore = defineStore({
  // handle user condfig to match the defineStore'arguments rule

 //  **if we need to use userInfoStore, but we can't import it here**
})

Don't know if I explain this clearly, but this is just my point.

Anyway, thanks for reply and really great work👍.

You could create a global store system if you need to, you could also use dynamic imports, etc. Since it's dynamic by design, it shouldn't be a limitation

Good tips, global store maybe a way(but maybe will make one store too much bigger, I think), and maybe couldn't dynamic imports, because the needed store file may not exist at development if it is a runtime create store(if I understand it right).
It's not a priority thing, we could achieve this in some other way, like dynamic generating the store file then recompiling the system or a global store like you said. just thought if it is a build in api would be better(in my point).
Thanks.

If you want to give the api a try, the easiest way is to use pinia (https://pinia.esm.dev) Whicker has à compatible API and will allow to easily migrate to Vuex if necessary l. It even works with Vue 2

If you want to give the api a try, the easiest way is to use pinia (https://pinia.esm.dev) Whicker has à compatible API and will allow to easily migrate to Vuex if necessary l. It even works with Vue 2

Ty for the hint, I'm just giving a try to Pinia in a new project and I think it's awesome!

Not 100% sure what you mean by state machine, but probably not. Vuex will be as simple as it can be. Any richer feature should be built on top of Vuex as a plugin.

Things like XState or Robot - I guess you‘ll be able to hook them up within the different parts of state handling.

EDIT: Ha, there's already a Pinia plugin for XState 😄 https://github.com/wobsoriano/pinia-xstate

@GavinRay97 Just an idea: if you put your computeds object behind a reactive proxy, it will auto-unwrap all refs on access, making it even easier to use outside templates.

const state = reactive({ users: [] })

const computeds = reactive({
  usersOver18: computed(() => state.users.filter(it => it.age > 18))
})

const adultsCount = computeds.usersOver18.length;  // <- no need for usersOver18.value

What?!

This is super useful -- thank you!

@GavinRay97 If you want predefined structure, I think you can simply use Options API instead 👍

It's safe to chose Pinia at the moment, it has the core same API as Vuex 5 and it aims to stay compatible.

Vuex 4 is more to be able to migrate Vue 2 apps as it still has the old API with mutations. IMO, I wouldn't choose it for new projects.

Thanks, got it 😎