[adamsea]

One approach is to write a reducer which has `isWaiting`, `error`, `finished` bools (in addition to whatever data said promise eventually modifies), or something similar, and programmatically update them in your actions/thunks. This effectively tracks the state of the promise (resolved/not resolved, error).I think the Flux "standard action" puts something similar in the action object - not sure what they do with it then.

[pault]

I always put a `pending` property on the `meta` object, and any component that needs to show network status can just check that property on every render cycle. Aside from requiring some extra utility functions in the reducers to prevent having to updating `pending` for every state of the request it's rock solid and I haven't ever encountered a situation where it wouldn't work. You can get a _lot_ of mileage out of conforming to the FSA standard[1]; network status goes in meta, and errors are always handled the same way.

[1] https://github.com/redux-utilities/flux-standard-action

[adamsea]

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.

[adamsea]

Also, this conversation got me thinking about the difference between application state, state of an asynchronous request, and Redux actions as events (I'm thinking of the request/response events in node.js), and using them as such - to pass data throughout the application (in addition to the payload). Which I guess is what FSA is all about? So, thank you!

[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