Improve API for better module composition about vuex

[yyx990803]

In Vuex, the equivalent of a "reducer" is just a collection of mutation handlers that operate on the same sub tree of your state. When creating the store, the mutations option can be an Array of objects. This array is essentially the equivalent of combineReducers.

[blu3gui7ar]

But it becomes tricky for a reusable widget.
Say my widget expose its state/mutation/action for reuse. All of them are developed without the knowledge of the whole SPA. The mutations could only get the state of the widget itself. When reused in the SPA, the state of the widget becomes a subtree of the whole state. But the mutations now get the whole state tree instead of its subtree, which is not defined yet during the widget development.
Another problem might be naming conflicts according to the flat design of mutations/actions array.

It would be great if there is official support to resolve the state of the widget from the whole state tree, and to pass into the mutations/actions. E.g. is it possible to form the mutations/actions array as tree structure which maps to the path of sub state tree, and have the framework resolve the path for mutations?

`
state -> a -> b -> sub state tree of widget A

mutations -> a -> b -> mutations of widget A

actions -> a -> b -> actions of widget A
`

[yyx990803]

@blu3gui7ar that makes sense. Yes, it would be great to have a built-in mechanism to simplify this. I'm open to suggestions! Can you give an example of your current approach?

[blu3gui7ar]

My current approach is verbose. My expectation is that with the help of framework, the widget itself should have no code change. So I tried to make less change inside my widget code.

The main idea currently is a Config created with a resolver (maps whole state to sub state) and a prefix (rename mutations/actions to avoid naming conflicts). It prepends prefix to raw mutations/actions, and wrap the raw mutations with resolver called before pass in the state.
https://github.com/blu3gui7ar/b9-modeler/blob/develop/src/store/index.js

The verbose part is that I need to pass the config object to every components of the widget.
Then, with a little helper class (https://github.com/blu3gui7ar/b9-modeler/blob/develop/src/components/actions.js),

const callables = _.mapValues(rawActions, (func, name) => function (config, ...args) {
    return config.action(name)(...args)
})
export default callables

I could call transformed actions with config as the first arg

import actions from './actions'
const { addNode } = actions

......
addNode(this.config, xxxxxx)
....

Also, state could be referenced with helper class (https://github.com/blu3gui7ar/b9-modeler/blob/develop/src/components/states.js)

export function rootMeta () {
    return this.config.getState().rootMeta
}

And to use it in the SPA state tree:
https://github.com/blu3gui7ar/b9-modeler/blob/develop/src/sample/store.js

//Config for the widget
const b9mConf = new Config({
    resolve: state => state.modeler,
    prefix: 'b9m_'
})

//extract the transformed state/mutations/actions
const {
    state: b9state,
    mutations: b9mutations,
    actions: b9actions
} = b9mConf.customized()

//The whole state tree for SPA
const store = new Vuex.Store({
    state: {
        modeler: b9state
    },
    mutations: b9mutations,
    actions: b9actions
})

//tricky: store the whole state ref
b9mConf.setStore(store)
//export for reference
export { store as default, b9mConf}

[blu3gui7ar]

API in my mind might be something like

const store = Vuex.combine({
  '/': {
      state: xxx,
      mutations: xxxx,
      actions: xxxx
  },
  'a.b.c': {
      state: xxx,
      mutations: xxxx,
      actions: xxxx
  },
  'a.b.d': {
      state: xxx,
      mutations: xxxx,
      actions: xxxx
  }
})

[bradstewart]

I really haven't thought this through, but what if the overall store contained sub-stores, in much the same way Vue components do? The Vuex.Store constructor could take a stores option.

Then you could call something like store.widgetA.actions.awesomeAction(), and access the "sub-state" like store.widgetA.state internally to a widget.

I've been thinking more about the related issue of a Vuex "plugins" which are intended to operate on the entire state tree, but might provide commonly used mutations, actions, middlewares to the app. I ended up subclassing Vuex.Store to add persistence which obviously doesn't work very well for more than one plugin. It's early, and rough, but: https://github.com/bradstewart/vuex-persist/blob/master/index.js .

[fobdy]

I think its also related to #31

[yyx990803]

shipped in 0.4.x