tamb / substate Goto Github PK

When you emit('UPDATE_STATE', {} ), there should be a config option for middleware to access the entire state management instance.

Right before STATE_UPDATED or a custom action is returned, there should option for middleware to fire. So it's a method that fires on EVERY state update.

This will allow for client side storage to be added, and other features.

Essentially a helper that will subscribe and unsubscribe right away???
Maybe functions should register like this:

{
    cbFunc: function,
    callCount: 0,
    futureFields,
}

lodash dependency is big. Cut the size by finding a smaller deep clone util.

https://attacomsian.com/blog/javascript-clone-objects

changeState should revert the state to specified index and change currentState index.

Would be good to add async support through:
dispatch
commit

I can implement those methods to call emit under the hood.

We should implement this without breaking the current API.

__

the reasoning behind this is to support the goal of universal terminology in application state management. Sure it's a more convoluted pub/sub. But it should help teams to get on the same page.

• beforeUpdate & afterUpdate need to show defined params and should be explained
• show demo of async action
• link to substate demo
• explain pubsub portion of this "message bus"

default param to { }

You should be able to export individual instances of Substate and merge them into one for a shared set of stores.

Ala Vuex, I'd like to add module support.
https://vuex.vuejs.org/guide/modules.html

I need to write tests for the middleware functionality to make sure that the functions are fired in the right order.

Show patterns of use:

substate action with payload describing new state 
    --> (state cloning magic) 
            --> callback(s) w/ new state

substate action with payload 
     --> reused logic to consume this action and describe new state 
            --> (state cloning magic) 
                   --> callback(s) w/ new state

infinite actions, infinite data changes, infinite responses

A happens --> do B --> yields C for those who care

ABCD happens --> do E --> yields F for those who care

A happens --> do B2 --> yields C2 for those who care

ABCD happens --> do E2 --> yields F2 for those who care

etc...

Optional configs only for dev mode that will give helpful clues. Emit $type and use colors like:
console.log('%c Oh my heavens! ', 'background: #222; color: #bada55');

This way you can track your messages
Eventually a library should be made

Perhaps this config also allows you to add your store to the window object

Do NOT rely on a polyfill for a feature that doesn't exist. Switch to the byString helper function from the newer version of the library

maybe just suggest encapsulating Actions and Event names within store?

store.register[x]()

store.registerMutations(Function | [Functions])
A mutation should return an object as new state,
This changes the call signature of emit

emit(String, {Function | Object})

store.registerActions

Consider the following state changes scenario

• add 'foo'
• add 'bar'
• add 'fox'
• go back one (current state is 'bar')
• add 'bump'

In the end, our state array will be ['foo', 'bar', 'fox', 'bump']. Should it be ['foo', 'bar', 'bump'] instead?