Agreed. And that sounds like a great approach. We didn’t conform exactly to FSA (which I want to try out on future projects). Our isWaiting was equivalent to your pending, I think.

(Edit) FYI we had actions to set isWaiting, etc.

Why would you serialize a pending network request? I use a property whitelist in my serializer that drops any application state not related to the business logic. Also, I don't use redux-thunk, I move all async operations to middleware and action creators are synchronous and declarative. For example, an API request will be defined in an action creator as an endpoint, http method, and request body, and the middleware will intercept this, make the API calls, and dispatch "pending" and "success/failure" actions. It scales extremely well and I don't know why people don't use custom middleware more often. The currying is a little confusing if you've never been exposed to it before, but the concept is no different than middleware in pretty much any http framework. I have yet to run into a problem that can't be solved by a custom middleware chain more cleanly than crazy async action frameworks like saga (I know saga works great for some folks but I think the cognitive overhead makes it of questionable utility when a promise chain in middleware can solve the same problem without requiring everyone on your team learn yet another library).