Hi! I would love to read your articles and discuss this further but right now your blog is not viewable by Chrome, Firefox, or Edge. Firefox gives the most descriptive error string as SSL_ERROR_RX_RECORD_TOO_LONG.

Multiplexing two models together to my mind just constructs a new model whose values are tuples of the existing models and which subscribes to both of those models in order to notify its own subscribers whenever either side of those tuples change. If you do this, you can have a bunch of local stores and still say "this component's value changes whenever either of those values change." The key is that "normal" models accept a set(value) message to set their value to something, and you might play around with "dict" models which accept insert(key, value), deleteAt(key) messages, but a multiplex model would not be easily able to abstract over all the different possible messages to send upstream and so the easiest approach is just to make multiplexes nonresponsive -- you can't "dispatch" to them, in Redux terms.

redux-thunk is nice in that it helps keep people from making the mistake of sending otherwise-no-op actions to the store which then, inside a reducer as side-effects, do a bunch of async I/O to compute events that eventually make it back to the store. I would broadly agree with that.

My basic beef with redux-thunk is that it's unnecessary and complicates what would otherwise be a type signature that has no reference to I/O, which I regard as a good thing. Developers ought to know that, to quote one of the Austin Powers movies, "you had the mojo all along." It's a sort of talisman that you are using for purely psychological reasons to reassure developers and to coax them to doing updates outside of the reducers, but it's OK because "it's in `dispatch()` so it must be a Redux thing so we'll make it work." But such a talisman is unnecessary.

Like, here's what you've got (in the readme):

    function makeASandwichWithSecretSauce(forPerson) {
      return function (dispatch) {
        return fetchSecretSauce().then(
          sauce => dispatch(makeASandwich(forPerson, sauce)),
          error => dispatch(apologize('The Sandwich Shop', forPerson, error))
        );
      };
    }
    store.dispatch(
      makeASandwichWithSecretSauce('Me')
    );

Here it is with simpler type signatures:

    function makeASandwichWithSecretSauce(forPerson, dispatch) {
      return fetchSecretSauce().then(
        sauce => dispatch(makeASandwich(forPerson, sauce)),
        error => dispatch(apologize('The Sandwich Shop', forPerson, error))
      );
    }
    makeASandwichWithSecretSauce('Me', msg => store.dispatch(msg));

The indirection here wouldn't even be necessary if Redux core just preventatively declared when creating a store that

    store.dispatch = Store.prototype.dispatch.bind(store);
    store.getState = Store.prototype.getState.bind(store);

which I mean maybe you do; I don't know.

Erm.... that's bizarre. Should be a normal Let's Encrypt cert as far as I know. Are you accessing it through some kind of corporate proxy that's blocking it or something? Does that happen on any other machines?

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 can try to clarify what you're saying about "type signatures" and binding the methods from the store, I'd appreciate it. (Actually, that bit about binding the store methods doesn't make any sense, because a Redux store isn't a class - it's a closure, so there's no `this`.)

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 ).

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.