Vuex: Decoupling Vuex from Vue

[Vheissu]

What problem does this feature solve?

I do not work with Vue.js as my primary day-to-day library of choice, however, when I have and have used the VueX state management library with it, it was fantastic. As someone who has worked with Redux before, I appreciated just how much more simple VueX was in comparison to the over-engineered and complicated Redux library.

As it currently stands, VueX is tightly coupled to Vue. This means VueX cannot be used with any other framework or library. Would it ever be a consideration to make VueX a standalone library and remove the Vue dependency?

At the end of the day, VueX allows the user to work with a bunch of data inside of a single object tree. I have not done the investigative work just yet to see how much VueX relies on Vue, but I would love to know if the team are open to making it a standalone state management solution? It's one of the best state management libraries I have ever used.

What does the proposed API look like?

The proposed API would resemble that of the current plugin. In-fact, the only thing I could see being different is that you do not register the plugin using Vue.use(Vuex) and just instantiate it directly and assign the result to a variable/constant called store or whatever.

You would then configure your state management using the same syntax.

import Vuex from 'vuex'

const store = new Vuex.Store({
  state: {
    counter: 0
  },
  getters: {
    counter: state => state.counter * 2
  },
  mutations: {
    increment: state => state.counter  
  }
});

// Usage

console.log(store.getters.counter);
store.commit('increment');

[andreiglingeanu]

Vuex uses Vue's reactivity system internally, which means it is coupled with Vue by design. Decoupling Vuex from Vue will require duplicating reactivity, which would lead to runtime overheads in most cases (everyone's using Vuex with Vue). Just give MobX a try or other state management solutions out there, most of them are already library-agnostic.

[ktsn]

@Vheissu
I just curious why you want to use Vuex without Vue.js.
Because if we would decouple Vuex with Vue, it no longer has a reactive state. That means you need to subscribe mutations and manually bind the state with components. Also Vuex takes mutation-based state update strategy, it would be harder to detect which sub-state tree is updated without reactivity system.
So decoupling Vuex from Vue.js would not make so much benefit, IMO.

[dennybiasiolli]

I'm using Vuex with React and I've created react-vuex package in order to have higher order components reacting to Vuex store changes, like react-redux package.
Having Vuex without Vue would allow to remove Vue from my peerDependencies.

[yordis]

Vuex uses Vue's reactivity system internally,

@andreiglingeanu what do you mean by that?

I don't believe that the Store itself it coupled from Vue at all, if you take a look to the Vuex Store internals, Store is just a Observer pattern in a nutshell, nothing related to Vue.

Now, mixins.js helpers.js are definitely coupled to Vue but that is not the core of the package anyway.

@dennybiasiolli did an amazing job of putting the pieces together, now, we could try to extract the package into two packages vuex and vuex-store.

The first one should be as it is right now without any changes for Vue folks, vuex-store could decouple the code for be framework agnostic code.

[andreiglingeanu]

@yordis I mean this is how Vuex implements state reactivity and dynamically computed getters. This part uses Vue and I think there's no way to decouple from that

[yordis]

@andreiglingeanu if you take a look to most of the Unit test of the store https://github.com/vuejs/vuex/blob/dev/test/unit/store.spec.js you will find that most of the use cases listed there do not require Vue itself.

Vuex is a Observer pattern under the hood.

You subscribe to changes on the store which it will allow you to know when things happen.

Now,

Vue would probably take advantage of Vuex on how it was layout and React will require a little of more code (like using state for mimic the reactive side of it) but from architecture and implementation, the store (the store only because is what people likes) doesn't have to depend of Vue.

All the actions are made throw commit and dispatch (you do not mutate directly) because this way you know when to dispatch a message to the subscribed list.

Either that or use Proxies so you can mutate directly the store values if you want.

But,

Vuex implements state reactivity and dynamically computed getters.

Could you elaborate on that please? I can be missing something for sure and I want to make sure that I am not talking non-sense.

[LinusBorg]

@yordis

Could you elaborate on that please? I can be missing something for sure and I want to make sure that I am not talking non-sense.

Well, Vuex uses a Vue instance to store its state inside. And it adds computed properties to it, which are the getters. Getters don't work like computed properties on a Vue instance, they are computed properties on a Vue instance.

See, for example, the following lines in src/index.js (You can find more instances where Vuex uses Vue):

https://github.com/vuejs/vuex/blob/dev/src/store.js#L37

https://github.com/vuejs/vuex/blob/dev/src/store.js#L241-L252

So Vuex is indeed tightly coupled to Vue, because its core functionality depends on Vue's reactivity system.