[eropple]

Yeah I get that, but then the application state isn't serialized in a usable form. If you re-load that state, you have half-open, "pending" operations.

If an idea of Redux is that serializable state is a good thing, then redux-thunk seems inimical to that.

[pault]

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

[eropple]

> Why would you serialize a pending network request?

I wouldn't. That's why I wouldn't put anything related to it in my Redux state!

But, like, I'm willing to be convinced. This is just where I'm at right now. Maybe your method would make more sense than redux-thunk does to me; have you written anything in more detail about this? (I'm not scared of middlewares, I've used Redux and middlewares even in non-web contexts, so intuitively this at least sounds more promising.)

[pault]

I agree, I'm pretty strict about keeping UI state out of the store, but when you need to coordinate a bunch of components based on the status of network API requests and you already have a global message bus available...

I've created a gist[1] with some snippets from a current project; it's still alpha, but you can get a general feeling for how the data flow works. I would clean it up a bit if I were officially releasing it to the public, but I'm definitely interested in feedback if anyone thinks I'm doing it ALL WRONG. :)

[1]: https://gist.github.com/parkerault/9dc7e825cc9a62b5efa8a4c1c...

Edit: regarding serializing state; I don't know how others handle it but I subscribe a localStorage writer to the store that only gets called when the store is changed, not when an action dispatches, so if an action creator dispatches a function to redux-thunk, the action doesn't get serialized, just the resulting store after the reducers do their thing. Do you have any examples of actions themselves getting serialized? I believe when Abramov talks about keeping the state serializable in the redux docs he's referring to the store itself; as far as I know anything goes in the actions themselves.

[adamsea]

This is very cool! Thank you for sharing this. We have had a somewhat similar approach, but stored request/response success/error states in request-specific reducers (it may have been better to put that data in the actions).

I think you will find of interest how we've used Immutable.js Maps for reducer state and Immutable.js Records as an easy way to create and pass around (guaranteed immutable) action types.

We were using Immutable.js and functional-style JS a lot in general, so it was a good fit.

https://gist.github.com/adamcee/3191762f2af43ec62a4b335b6695...

[eropple]

I'll look at this tomorrow. Thank you!

When I refer to serializing an action, I mean that, by necessity, the current state of any in-flight asynchronous actions must be recorded and saved--or else I don't think serialization works, its promises fail and you end up with a state whose completeness you can't guarantee. That opinion may change when I look at this tomorrow, of course--you very well may be cleverer than I am!

I use redux-storage for what you describe for persistence, btw. I like it a lot, I can easily select what I'm going to persist, and I don't have to maintain it. I dynamically pick a backend: IndexedDB where supported, LocalStorage where not.

[adamsea]

FYI we used redux thunk