The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

TrueWill (22) [Avatar] Offline
In section 4.7 (Error Handling), you suggest using a catch block in the async action creator (such as listing 4.22). The Redux documentation specifically recommends against this:

// Do not use catch, because that will also catch
// any errors in the dispatch and resulting render,
// causing a loop of 'Unexpected batch number' errors.

Instead Dan Abramov recommends using the second argument to then():

In most cases it probably won't matter, and I think the error message was improved, but it may still be good practice.

Explicitly rejecting a promise in then() (as in listing 4.22) will not work when using the second argument. This acts like an error in dispatch(), which we don't want to catch. Instead, to simulate an error, it's easiest to simply stop json-server.
Will Faurot (8) [Avatar] Offline
This is a great catch, thanks! I hadn't seen this issue specifically before, and I actually have been bitten by this, though in my case it was catch swallowing/obscuring errors in a reducer.

Dan's suggestion seems like the spirit of what we're going for in the book (and with our own code) when it comes to error handling anyways, which is specifically to pick up network errors, not things like syntax errors in other parts of the code.

I like the idea of trying to capture as many best practices as possible so I'll put this on the list for the next update.