Anyway. Reading the rest of your comment...
I'll be honest and say that you pretty much lost me in that discussion, as in, I genuinely am confused what you're trying to say. I'll try to give some thoughts here, but I don't know if this is going to answer things because I don't know what point you're actually trying to make.
The point of `redux-thunk` is to allow you to write logic that needs access to `dispatch` and `getState` when it runs, but without binding it to specific references of `dispatch` and `getState` ahead of time.
If you wanted to, you _could_ just directly `import {store} from "./myStore"`, and directly call `store.dispatch(someAction)`. But, A) that doesn't scale well in an actual app, and B) it ties you to that one store instance, making it harder to reuse any of the logic or test it.
In a typical React-Redux app, the actual specific store instance gets injected into the component tree by rendering `<Provider store={store}>` around the root component. As my slides point out, you _could_ still directly grab a reference to `props.dispatch` and do async work in the component, but that's also not generally a good pattern. By moving the async logic into its own function, and ultimately injecting `(dispatch, getState)` into that function, it's more portable and reusable.
Also, have you seen the actual implementation of `redux-thunk`? It's short enough that I'll paste it in here just for emphasis:
return ({ dispatch, getState }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState);
}
return next(action);
};
If you're available to discuss this in a venue that may be better suited for it, please come ping me @acemarke in the Reactiflux chat channels on Discord (invite link: https://reactiflux.com ).