access to the store

[snackycracky]

Hey,
I would like to access the store and it's state inside the async actions (https://rackt.github.io/redux/docs/advanced/AsyncActions.html).
The logic for the params of the server calls are quite complicated for me and need to be calculated with several state properties of the one central store.
Is it better to pass every state property to the async-action or to let this async-actionCreator pull every property from the store by itself?

Here are the differences to make my point clear:

with multiple params and without the store:

import {calc1} from bla
import {calc_a} from blub
import {calc_x} from foo

function asyncAction({prop1, prop2, prop3, prop4, prop5, ...} = {}){
   let params = []
   params.push(calc1(prop1));
   params.push(calc_a(prop2));
   params.push(calc_x(prop1, prop4)); 
  ....   

   return {
    types: [SAVE, SAVE_SUCCESS, SAVE_FAIL],
    id: widget.id,
    promise: (client) => client.post('/api/whatever', {
      params: params
    })
}

with the properties from the store instead of the params :

import {calc1} from bla
import {calc_a} from blub
import {calc_x} from foo

function asyncAction(/*no arguments*/){
   let params = []
   params.push(calc1(store.getState().x.prop2));
   params.push(calc_a(store.getState().y.prop1));
   params.push(calc_x(store.getState().z.prop1, store.getState().z.prop4)); 
  ....   

   return {
    types: [SAVE, SAVE_SUCCESS, SAVE_FAIL],
    promise: (client) => client.post('/api/whatever', {
      params: params
    })
}

The question is now: Why is the store not globally accessible in this project? If it isn't modified (wrote to) without proper actions and just read everywhere then this seems ok to me. On the other hand the async-actionCreator would not be a pure function anymore because it's then dependent on the state in the store.

[trueter]

On the other hand the async-actionCreator would not be a pure function anymore because it's then dependent on the state in the store.

Bingo. Thats probably the reason.

[asaf]

@trueter got it right, Redux by its nature embraces functional programming, unit testing becomes much more complicated when dependencies increases, by definition, Redux action creators are pure functions that should just return the action payload and shell be independent.

[snackycracky]

ok thx. But I am wondering because in this great tutorial it tends more to the other version (with the properties from the store instead of the params) :

http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

...
So, the Redux store ties things together into something we'll be able to use as the central point of our application: It holds the current state, and over time can receive actions that evolve the state from one version to the next, using the core application logic we have written and exposed through the reducer.
Question: How many variables do you need in a Redux application? Answer: One. The one inside the store.
This notion may sound ludicrous at first - at least if you haven't done much functional programming. How can you do anything useful with just one variable?
But the fact is we don't need any more variables than that. The current state tree is the only thing that varies over time in our core application. The rest is all constants and immutable values.
It is quite remarkable just how small the integration surface area between our application code and Redux actually is. Because we have a generic reducer function, that's the only thing we need to let Redux know about. The rest is all in our own, non-framework-speficic, highly portable and purely functional code!
If we now create the index.js entry point for the application, we can have it create and export a store
....

[snackycracky]

also in the redux migration docs it sais:

...
This allows you to gradually rewrite every Flux Store in your app as a reducer, but still export createFluxStore(reducer) so the rest of your app is not aware that this is happening and sees the Flux stores.
...
http://rackt.github.io/redux/docs/recipes/MigratingToRedux.html

which also leads to the other version (with the properties from the store instead of the params)