[drostie]

Hm. I will have to retry. You're right that this is my work laptop and sometimes Sophos does weird crap. Sorry for alarming you without checking downforeveryoneorjustme first.

I have read the source; indeed reading the source of redux-thunk was necessary for me to conclude it was pointless. I like everyone else thought that it was doing something more than `go = fn => fn()` does.

The code that I wrote you is logic which needs access to `dispatch` and `getState` when it runs, but it is not bound to specific references of `dispatch` and `getState`. It does not use your hack of importing a store from a global location, so it does not have problems with (A) or (B).

You cannot avoid grabbing that reference to props.dispatch either way. The crux of the argument that redux-thunk is just syntactic sugar, is that dispatch is already in scope whenever it is used and can be passed as an argument or a closure.

I agree somewhat with refactoring async logic into its own component when one wants to reuse it and make it portable. The question is just, should you pass `dispatch` and/or `getState` as an argument to that function? Or should you curry that dependency to a subfunction and pass that function as an argument to `dispatch`?

I opine that the latter is objectively worse than the former. You have `dispatch`: hand it directly to the function, let people know that this function is not an actual action but an asynchronous process. We are talking about a syntactic sugar, in other words, that doesn't make anything sweeter.

I'm actually refreshed to be reminded that the Redux store is a closure, I had forgotten since I first read the Redux code several months ago. So then it's even easier; one never has to bind anything.

I will try to ping you on Discord later tonight; there is a specific reason that I am preferring asynchronous messaging systems at the moment.