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