[Vuex] Vuex 5 #270
Replies: 46 comments 121 replies
-
|
I can see some similarities between this RFC and https://github.com/posva/pinia. Are them somehow related? |
Beta Was this translation helpful? Give feedback.
-
|
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 👍 |
Beta Was this translation helpful? Give feedback.
-
|
@kiaking Then shouldn't You two just connect efforts and work together somehow? ;) |
Beta Was this translation helpful? Give feedback.
-
|
We already do, lol |
Beta Was this translation helpful? Give feedback.
-
|
@posva of course I mean working on single library ;) |
Beta Was this translation helpful? Give feedback.
-
|
I like that @kiaking is contributing on pinia, for two reasons:
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. |
Beta Was this translation helpful? Give feedback.
-
|
As a first skim through it seems that it covers most of use cases and concerns. Great work on the proposal. Question: Why are we targeting Vue 3.1 release? |
Beta Was this translation helpful? Give feedback.
-
|
We need to have effectScope implemented in order for Vuex store to work completely! Otherwise, |
Beta Was this translation helpful? Give feedback.
-
|
Is there a rough timeline already for Vue 3.1 - and also Vuex 5 GA? |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
So store is lazy initialized right? When the store first called. |
Beta Was this translation helpful? Give feedback.
-
|
Please avoid using |
Beta Was this translation helpful? Give feedback.
-
|
You can use Composition Store if you don't want use |
Beta Was this translation helpful? Give feedback.
-
|
In one of my projects a specific part of the app uses a separate, second store (as in |
Beta Was this translation helpful? Give feedback.
-
|
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 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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() ? |
Beta Was this translation helpful? Give feedback.
-
|
@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 @goeh
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
I am missing two key things compared to Vuex 3:
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 ( |
Beta Was this translation helpful? Give feedback.
-
Is this about you want But yes, if we have high demand for it, we can implement
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?
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 If What do you think? |
Beta Was this translation helpful? Give feedback.
-
Quite the opposite, I don't want export default {
actions: ['foo/bar'], // the exact API could vary
methods: {
callStoreAction() {
this.bar();
}
}
}
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.
I think this can be resolved using functions and arguments (as demonstrated above). Having |
Beta Was this translation helpful? Give feedback.
-
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.
The 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...?
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 👍 |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
|
Great work, I am really excited to see this RFC. In my humble opinion, because Vuex 5 represents so much "new code" and represents a major shift in API, we should simplify to just composition stores. Git rid of all options-based API, and let there be one way to do things. People will already have to do major refactors when going from 3/4 to 5, so why not switch to composition style stores while we have the opportunity? Sure options syntax appears more familiar right now, but having a single way to do things going forward has major benefits. To help ease the transition, code mods or adapters could be created, or maybe just recommend Vuex 4 if you want options syntax. For those using the options syntax for their Vue components, there is no real disadvantage. This would have no bearing on their decision to use composition or options API in Vue components. They can still use options syntax to their hearts content. I don't believe Vuex 5 needs to be part of the dilemma of options vs. composition API, because component definition is not the same domain as global state definition. If I'm not mistaken, the long-term goal for Vue is to see options API gradually disappear in favor of composition. Perhaps Vuex 5 could be a little more future-oriented, and sort of help introduce composition to devs still using options syntax. In this way, should they choose to switch Vue components from options to composition API, they will be able to rely on some previous knowledge of how setup functions/refs, etc. work. In addition, dropping the options API would also allow for faster development cycles, fewer edge case bugs, smaller bundle sizes, and easier contribution. |
Beta Was this translation helpful? Give feedback.
-
|
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.
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 😓
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 🙌 |
Beta Was this translation helpful? Give 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! |
Beta Was this translation helpful? Give feedback.
-
|
@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? |
Beta Was this translation helpful? Give feedback.
-
|
@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 😳 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
I am confused on why we want to get rid of mutations. Some processes need to run synchronously don’t they? E.g. A person should pay before placing the order. The createVuex is a good idea because it follows the same canonical as creating VueJs 3 app. |
Beta Was this translation helpful? Give feedback.
-
|
Actions can be both synchronous and async. In you case you can just create 2 actions 👍 |
Beta Was this translation helpful? Give feedback.
-
|
RE the migration. It seems that this proposal is fully opt in. It it so different it is actually simple to migrate in user land progressivelu. Alias old Vuex to something like This would all the use of Vuex 5, allowing apps to progressively migrate and use the new version without hassle. This will also allow existing stores do be migrated 1 by 1. The reason I mention this is to avoid the need for a migration strategy other than use A or B version. Yes there will be a minor overhead of dependencies included at runtime but Vuex isn't a huge dependency. In big applications Vuex modules / stores will be code split also helping reduce that burden |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
One benefit of Vuex was a single way if doing things, the only thing I don't like about this proposal is that there is now two ways to do something and an increased surface area of knowledge to share. In larger organisations I can imagine it'll be hard to enforce this, would there be a way to split this into multiple packages. This way we could enforce a single way to do things at application level and reduce the surface area of functionality depending on the package imported. If the package doesn't exist in the dependency chain it'll make it much more difficult to use the alternative API. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 👍 |
Beta Was this translation helpful? Give feedback.
-
|
I wonder if we are redesigning const useCounter = defineStore({
key: 'counter',
state: () => ({
count: 1
}),
getters: {
double() {
return this.count * 2
}
},
actions: {
increment() {
this.count++
}
}
})
// equivalent composition store
import { ref, computed } from 'vue'
import { defineStore } from 'vuex'
const useCounter = defineStore('counter', () => {
const count = ref(1)
const double = computed(() => count.value * 2)
function increment() {
count.value++
}
return {
count,
double,
increment
}
})Looks like the same as class CounterStore {
count = 1
get double {
return this.count * 2
}
increment() {
this.count++
}
// advanced usage
storeB = useStoreB()
constructor(context) {
// access vuex plugin in context
const {$axios} = context
}
get crossStoreGetter() {
return this.storeB.fooB
}
}Implementation-wise, I would argue that class API is quite similar to composition API. State inspection, mutation logging and time-travel can be implemented by proxy. Arguably the benefit of using class is:
Downside:
|
Beta Was this translation helpful? Give feedback.
-
|
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 👀 |
Beta Was this translation helpful? Give feedback.
-
|
Now that mutations are gone, how will the ordering between actions (e.g. for time-travelling purposes) work? Ordering sync actions, or actions that otherwise mutate all data in the same tick, is safe. But, otherwise, there could be data hazards in considering actions as atomic changes, like mutations in current Vuex. Consider the following async action: // ...
async myAction () {
this.a = something()
this.b = await somethingVerySlow(this.a)
const x = await anotherSlowOperation()
this.c = anotherThing(this.b, x)
},Another component could dispatch a sync action (and, therefore, mutate state) between the time In that hypothetical scenario, there could be problems in ordering the async action and the posterior sync action, specially if the latter read and/or write I can see two paths:
It have some cons, like the extra noise and the risk of causing a data inconsistency during a partial rollback. Pinia can solve those cons, as far as I know, with the Data changes caused by the same action during the same tick could be grouped by some heuristics -- it'd probably require running something like
I think this is worse than the original problem. The text suggests that a separate RFC can be opened for discussing devtools support for Vuex v5. I can pause discussing this topic for now, but I'd like to mention it because it involves some key changes in v5 (the absence of mutations). |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This is probably more a vocabulary issue, but I got confused by the fact that the store instanciation is now done in component code, and that despite it is done in several components, the store is instanciated only once, as explained in the Automatic store registration part. As an end-user and not a Vuex contributor, I would find it easier to understand if we use the words "create → register" instead of "define → instanciate". <script setup>
import { useCounter } from '@/stores/counter'
const counter = useCounter()
</script>This is very neat compared to the Options API that requires to call |
Beta Was this translation helpful? Give feedback.
-
|
Defining here is the correct term (like |
Beta Was this translation helpful? Give feedback.
-
export default {
setup() {
return {
counter: useCounter()
}
},
methods: {
increment() {
this.counter.increment()
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
I really like that we keep the support for Options API for those of us who are not yet ready to learn the Composition API and want to stay productive with their projects. In a year or two, I'll sit down with a lot of coffee, and although I understand the changes, the motivations and how things in the Composition API work, I'll then nonetheless get out of my way to learn it in practice and ensure that I can work with it productively. Right now it would just cause me unnecessary stress. Thank you guys! |
Beta Was this translation helpful? Give feedback.
-
|
I actually really like this RFC! It is fully TS compatible, which is awesome. Tho, my concern is about code splitting. In large Vue projects, Vuex single module can get quite big, so in my team, we split Potentially, you could work around this in composition API manually. In Options API, we could have potentailly const state = { counter: 0 }
const getters = defineGetters(state, {
biggerCounter() {
return this.counter + 10
}
})
const actions = defineActions(state, getters, {
increment() {
this.counter += 1
}
})But that's just my concerns, that could be solved with some kind of 'per project' wrapper. Anyway, great job guys! I think it's good direction! ^^ |
Beta Was this translation helpful? Give feedback.
-
|
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 👀 |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the great work. some questions:
import { useCounter } from '@/stores/Counter'
export default {
setup() {
const counter = useCounter()
counter.count // <- 1
}
}
// useStore
import { useStore } from 'vuex'
export default {
setup() {
const counterStore = useStore('counter')
counterStore.count // <- 1
}
}
const vuex = createVuex()
vuex.store({
// some dynamic config
})Thanks & Thumps up! |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
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 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👍. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
Is there an estimated timeline when feedbacks will be consolidated and an alpha build of this RFC will be out? I believe many of us are willing to try such build on our side project(s) and provide real-world usage feedback, which might be useful in moving discussion forward. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Ty for the hint, I'm just giving a try to Pinia in a new project and I think it's awesome! |
Beta Was this translation helpful? Give feedback.
-
|
Is vuex going to support state machines in the future. Or will you create your own mechanism |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Dropping my $0.02 here, though nobody asked. Vuex was the first time I used a state management library and things just felt "perfect." I was in love. It's gotten even better over time. I would say that Pinia (with some small tradeoffs) improved on Vuex, and we've seen a taste of that incorporated in Vuex 4 with more to come in Vuex 5. The only thing I'd like to ask, is if there's an API option that keeps a boundary between "data" and "not-data". const useCounter = defineStore('counter', () => {
const count = ref(1)
const double = computed(() => count.value * 2)
function increment() {
count.value++
}
return {
count,
double,
increment
}
})It's hard to visually distinguish what is Personally, I've taken to doing this in my Vue apps: const state = reactive({
users: [],
loading: false,
error: false
})
const computeds = {
usersOver18: computed(() => state.users.filter(it => it.age > 18))
}
function doSomething() {
console.log("foo")
}
return { state, computeds, doSomething }Because it's less cognitive overhead to figure out which things are plain state, which things are computed, which things are methods, etc. In your template, you press Compared to using
const users = ref([])
const loading = ref(false)
const error = ref(false)
const usersOver18 = computed(() => users.value.filter(it => it.age > 18))
function doSomething() {
console.log("foo")
}
return { users, loading, error, usersOver18, doSomething } |
Beta Was this translation helpful? Give feedback.
-
|
@GavinRay97 Just an idea: if you put your 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 |
Beta Was this translation helpful? Give feedback.
-
|
What?! This is super useful -- thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@GavinRay97 If you want predefined structure, I think you can simply use Options API instead 👍 |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm confused about how long can we use vuex5? How should I choose Pinia2 and vuex4 in my new vue3 project? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, got it 😎 |
Beta Was this translation helpful? Give feedback.
-
|
Could this RFC be updated to reflect pinia@2.0.0 ? I think pinia pretty much nailed what Vuex 5 should be, and it's kind of weird that this RFC is out of sync. Also, one feature that I don't like (and that is not part of pinia) is the const storeA = useStoreA();
storeA.storeB.valueFromStoreB // Will this work?If it does leak, then to me this feature has more cons than pros. It creates a lot of unnecessary coupling and bloats store A for no good reason. If you need store B, then just use it. If it does not leak, then I guess it's an "ok" feature but again, to me this adds unnecessary complexity. Just the fact that the name is inferred (useGreeter -> greeter) makes it weird to me. I have never needed that feature in pinia, and unless people are actually asking for it, I'm not sure it should be part of Vuex 5. Also, completely different topic: Since Vuex 5 will be so much different from Vuex 4, why not put Vuex end of life and just use Pinia instead? Migrating from vuex 4 to 5 will feel like using a brand new library anyway. |
Beta Was this translation helpful? Give feedback.
-
|
Any update on GA or alpha/beta release ? |
Beta Was this translation helpful? Give feedback.
-
|
Evan You: "Pinia is de facto Vuex 5! At this point it’s really a naming/branding issue." |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the info; I'm using Pinia for now, after reading all about it. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this RFC! After read the RFC and discussions, I wonder why not direct return store instance in defineStore function? Just like this: // singleton store registry
const vuex = createVuex()
// define and register the store
const counter = vuex.defineStore(...)
// direct use counter store
counter.count // 1
counter.double // 2And I see Vuex 4 provide an import store from '@/my-app-store/index'
export default {
setup () {
// direct use store example
return {
count: computed(() => store.state.count),
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Both your examples have a problem - they introduce a stateful singleton. This is unacceptable when using SSR |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! the link is very useful. |
Beta Was this translation helpful? Give feedback.
-
|
I create a extension for pinia, maybe can add to this RFC? pinia-di: DI(dependency-injection) for pinia, work with vue@3. Why?
For example, i have ten same components in my page, they have the same data structure but independent state, it is very cumbersome to manage them in an array of a common store. Another problem, for large project, i want to release the memory of state(auto unmount store) after the component unmount. If we manage that manually, it is cumbersome too. Based on my previous project experience, i take the Core Concepts
InjectionContext:
|
Beta Was this translation helpful? Give feedback.
-
|
I know it's too soon to talk about the release of Vuex 5 but since there hasn't been any recent announcements I was looking for new updates and I come across to some tweets from Evan You on Vuex and Pinia that seem confusing |
Beta Was this translation helpful? Give feedback.
-
|
From what I’ve recently seen and read, it seems so. Apparently new vue docs are about to roll out in January with vue 3 being the main version on GitHub and npm, new final release of vue devtools, and pinia being the recommended successor to vuex. |
Beta Was this translation helpful? Give feedback.
-
|
I design a lib based on Vuex, and has similar usage as Pinia (or even simpler). It use "stateful singletons" by default, but can fully avoids "stateful singletons" by switch to advanced usage if necessary. export const counterStore = hamiVuex.store({
// unique name of the store, will appear in devtools
$name: 'counter',
// define the state with a function that returns a fresh state
$state() {
return { count: 0 }
}
// define a getter, similar to Vue computed
get double() {
return this.count * 2
},
// define an action, similar to Vuex action
increment() {
// $patch is builtin Vuex mutation, used for update state
this.$patch(state => {
state.count = this.count + 1
})
},
})Why use "stateful singleton"? Stateful singletons are simpler and more convenient to use, and only perform poorly in terms of Vue SSR. Vue SSR is not required for most single-page applications, so you can use "stateful singleton" with confidence and switch to advanced usage if necessary. Repo / Document / Design considerations: Thanks all ideas in this RFC discussion which bringing me a lot of inspiration! |
Beta Was this translation helpful? Give feedback.
-
|
Nice approach, since we're considering a reserved prefix and an alternative API, I thought about how minimal it could get: const useCounter = defineStore('myStore', () => ({
$: () => ({ count: 1 }), // state
$double: s => s.count * 2, // getter
increment: s => { s.count++ } // action
}))If the property starts with $, it will be turned into a getter/computed, except "$" itself, which is the state object. Could easily support const useCounter = defineStore('myStore', s => ({
$: () => ({ count: 1 }),
$double() { return this.count * 2 }, // or s.count * 2
increment() { this.count++ } // or s.count++
}))I still think the name should be either the first argument or (optionally) be inferred from the function.name: const myStore = () => ({ /* ... */ })
const useCounter = defineStore(myStore) // uses myStore.name to set name = 'myStore'
const useCounter = defineStore(function myStore() { return { /* ... */ } }) // this would also work
// or any of these approaches (supports more settings than name):
const useCounter = defineStore(() => ({ /* ... */ }), opts) // where opts.name = 'myStore'
useCounter.__opts__.name = 'myStore' // reserve a keyword for additional settings/optionsI think this lib can be written as a simple abstraction, so this What do you think? :) |
Beta Was this translation helpful? Give feedback.
-
|
just suggest Pinia officially or merge Vuex 5 with Pinia in one project |
Beta Was this translation helpful? Give feedback.
-
|
Pinia is already the official recommendation. The new docs show this: they are currently in beta here and are set to be published on Feb 7 2022. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, as vuex5 is based on Pinia, will it handle splitting store in different files ? |
Beta Was this translation helpful? Give feedback.
-
|
Is this proposal still an active one @kiaking ? @posva you may also know the status here. I think it would be great if the Vuex docs mentioned if it was being sunset for Pinia going forward as well, if all the energy for state management is going into Pinia as a first party library |
Beta Was this translation helpful? Give feedback.
-
|
There will be no Vuex 5 https://www.youtube.com/watch?v=BUUupT4zfA0&t=1041s |
Beta Was this translation helpful? Give feedback.
-
|
We're closing the RFC due to Pinia becoming the next official state management lib for Vue. Pinia has almost the exact same or enhanced API as Vuex 5, described in this RFC. You could simply consider Pinia as Vuex 5 with a different name. |
Beta Was this translation helpful? Give feedback.
-
|
thank you @kiaking, that increases clarity! |
Beta Was this translation helpful? Give feedback.
-
|
Definitely the right move. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks |
Beta Was this translation helpful? Give feedback.
and others
-
UPDATE
We're closing the RFC due to Pinia becoming the next official state management lib for Vue.
Pinia has almost the exact same or enhanced API as Vuex 5, described in this RFC. You could simply consider Pinia as Vuex 5 with a different name.
This is the discussion thread for the new Vuex 5 RFC.
Beta Was this translation helpful? Give feedback.
All reactions