Comments (13)
I like the concept. However with experimentation on how to modularise the store it became more apparent to me that the store shouldn't modularise itself too much. When trying to modularise the concerns of a state to a particular feature/module it gave more inconsistencies. E.g. if an action was to affect multiple sub trees while modularised it could lead to a separation that didn't raise enough needs. This is why actions should be able to infer mutations on any part of the state.
The more we indulge the more we find that modularisation of the state was asking for too much for a flux architecture. I believe the API is correct for a robust state management system, however what could be improved mainly was how to implement solidly to a component. Using this.$state
does add more verboseness, however this comes with benefits. So introducing a full fledged integration like this doesnt completely work for me.
Another great point raised is about SSR, this is difficult to implement with state as this is a natural flaw with SSR as the state is difficult to pass through SSR, especially in large applications. Could you explain more on how your changes will help SSR implementation?
I like Vuex in its current state, as it helps reduce repetitive code, clearly defines the barriers between mutations and actions and it keeps state management simple. Another great point is that the store acts as a single point of dependency. My fear with this API change is that the possibilities of the implementation details will multiply rapidly, creating more questions on how to correctly structure the store.
This is my initial reaction however i will delve further on this to see if i can sway myself into a different point of view.
from vuex.
Slightly tangent, but I've been using similar syntax to interact with redux
:
var actions = require('./actions');
module.exports = {
template: '<span @click="increment">{{ value }}<span>',
redux: {
select: function(state) {
return { value: state.value };
},
actions: {
increment: actions.increment,
},
},
};
Behind the scenes the instance subscribes to the store changes at created
and unsubscribes at beforeDestroy
. Upon changes, state is mapped to a slice using given select
function, and then the slice is merged into vm
(using logic that is similar to Object.assign
). Actions are also getting bound to the store at created
and are added to vm
as if they were methods.
So far it's working great, but there's room for improvements, like using reselect
and protecting store state from being "infected" with reactive getters and setters.
from vuex.
Totally support the new way of module composition.
But as for usage in components, I have a slightly different opinion. I believe a component should explicitly declare what data it uses, it should describe itself. So I'm against injecting a state to each component implicitly. Pieces of a state should be based by properties. However, I think the injection of actions is a very good idea. Currently I have to import actions in each component in order to notify my store about changes.
Still hope you will introduce some kind of namespaces for actions/mutations. It would be very, very helpful.
from vuex.
@simplesmiler ha that looks extremely familiar.
@sunabozu the new syntax does declare what data a component uses. Note the vuex.state
option is declaring the properties to "select" from the state and added to the current instance.
from vuex.
I really like the change to defining actions directly on components, I've got more than a few actions which only make sense for a specific component (e.g. login
related stuff).
from vuex.
I personally would love some sort of ability to automatically bind actions to a vue component. Lately I've been doing something like:
// SomeComponent.vue
<script>
import store from '../store';
const methods = store.actions;
const component = { ... };
// assign vuex actions to component methods
Object.assign(component, {
methods
});
export default component;
</script>
It's just too bad there's no way to bind a decorator to an object.
Another idea is to do something similar to omniscient's component
function and just assign the methods/state to the object that's passed in, then export that out. https://github.com/omniscientjs/omniscient
from vuex.
@rbvea well what you want can be done with mixins:
export default {
mixins: [ { methods: store.actions } ],
...,
};
from vuex.
@simplesmiler cool! didn't know that, could you do the same with a store being passed down as a prop?
from vuex.
I've just started playing with 0.4.0
branch, where there is no more support for store.actions
. My first feeling relates to what @blake-newman said:
Another great point is that the store acts as a single point of dependency. My fear with this API change is that the possibilities of the implementation details will multiply rapidly, creating more questions on how to correctly structure the store.
Yep... Right now, I'm facing the issue of where to put my actions, since they can't belong to the store anymore. I can place them just anywhere now.
I understand this is a good "flexibility" feature. And I've seen the strong "actions" support for usage inside Vue components. In my case, I'm using actions from an Authentication service, which does not belong to any particular Vue component...
...while I was just calling store.actions.something()
, now it seems I will need to create an additional layer... a separated "actions" module, which will import the store, and in my service I will import the actions module instead of the store. This may sound simple but in fact introduces a lot of unnecessary complexity.
Quoting @blake-newman again:
This is my initial reaction however i will delve further on this to see if i can sway myself into a different point of view.
Right now I am facing the "multiplied possibilities" + "questions on how to structure" phase, but maybe it is just a matter of moving forward a bit more...
from vuex.
I'm happy again. 😃 I moved forward towards a nice solution I'm enjoying. I am willing to share it. I hope I can get some free time to do so.
Indeed, we have multiplied possibilities and flexibility on how to structure... I was comfortable with the actions shorthands... I just re-created the little wrapper from 0.3.0...
I basically brought back the old good parts I missed, while I'm already enjoying the benefits of the newly added stuff, from the no-issues with vue-router, up to the new vuex
component configuration option.
Very good, indeed! 👍
from vuex.
@jbruni glad to hear that - this is exactly what is happening: in 0.4.0, actions and getters are just functions that you can organize and import anyway you like. While the docs/guide will recommend a way to organize them, you are free to develop your own organization patterns to fit your mental model better.
from vuex.
@jbruni @yyx990803 I have also been experimenting with 0.4.0 and it feels right. I was more under the illusion that actions were still to be combined like mutations. Which caused complexity with naming, as you had to make sure that they had clear naming even if they did completely different actions but we're modularise to a specific file.
Modularising actions to a file gives flexibility, I enjoyed it so much Ive detached my actions from the store in my current project for my company in preparation to 0.4.0 release but more so that it makes more sense to not combine actions to the store.
from vuex.
Shipped in 0.4.0
from vuex.
Related Issues (20)
- vuex的例子报错
- Add useStore for v3 for vue 2.7 with composition api HOT 5
- Fix type definitions with `moduleResolutions` `nodenext` HOT 3
- The getter is updated, but the associated dom is not updated. HOT 8
- Mutation on nested properties
- vite 创建vue项目,安装vuex后vscode报错,Could not find a declaration file for module 'vuex'. HOT 7
- TypeError: Cannot read properties of undefined (reading 'state') at Proxy.mappedState (vuex.esm-bundler.js:1162:31) HOT 1
- Dynamic module not registered after hot reload
- vuex.esm-bundler.js is missing in the dist folder
- Error in Vuex document link HOT 2
- link pointing errors in docs HOT 1
- Memory increase: Update from 4.0.2 to 4.1.0 HOT 2
- A research for generating PR checklists in Pull Request Template HOT 1
- TypeError: Cannot read properties of undefined (reading '$store')
- Using `vuex` with the latest version of `vue` has a broken hot reload test HOT 1
- Is there way to exclude @vue/devtools-api code from final bundle?
- vuex3.6.2内存泄漏
- 使用mudule,在一个模块中commit另一个模块的mutations报unknown local mutation type
- Vuex Devtools plugins registered on server which increases memory usage
- 官网崩了
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from vuex.