staydecent / atom Goto Github PK

this way the state change can be picked up for redux devtools.

https://github.com/acdlite/flux-standard-action

Potentially include a helper function (without Ramda dependancy):

import merge from 'ramda/src/merge'
import pick from 'ramda/src/pick'
import curryN from 'ramda/src/curryN'

export const createAction = curryN(2, (type, payload, extra) => {
  let action = {type, payload}
  if (extra) {
    return merge(action, pick(['meta', 'error'], extra))
  }
  return action
})

export default createAction

If more functionality is desired then recommend https://github.com/acdlite/redux-actions

this would need to be part of a config type object that is passed to the atom store creator function. enabling this would allow for closer compatibility with redux.

another crazy idea is let the arg order be defined on the reducer's prototype so arg order could be mixed in a single store...

but then maybe any redux based reducer could just be wrapped in a function that flips the args (Ramda.flip)?

https://gist.github.com/HenrikJoreteg/530c1da6a5e0ff9bd9ad

• Can it be an external lib so atom default bundle can remain tiny?

var store = atom(applyMiddleware([someMiddleware], counter), 0)

Could the applyMiddleware just wrap each middleware in a function that returns unchanged state?
Do the middleware functions need a way to halt progress, a la next()?

This avoids any issues with nested arrays and inheritance

Not sure where to post this request, maybe pwa-starter or elements would be better.

In some side projects I've been using a store with get and set functions that I find very useful. With wasmuth naming it would be path and pathSet I think. Anyways it looks like this.

store.get([]) returns entire state
store.get(['nested', 'value']) get nested value
store.set(['nested', 'value'], newValue) sets nested value

I also added a store.setBatch which is used like

store.setBatch(
    [['nested', 'value'], newValue],
    [['nested', 'somewhereElse'], another value],
)

instead of:

dispatch(anEvent)
dispatch(anotherEvent)

Could batch them:

batch(anEvent, anotherEvent)

And subscribers would only be called after all actions in given to batch have run

I like this simple clear implementation, would be great to add ability for middle ware and combining multiple stores or would that be reducers?