5 ms·
Redux is for state management - that could be your data store but many people use it manage their app's UI state as well. Dan Abramov himself has said many time
by azundo 9y ago
Redux is for state management - that could be your data store but many people use it manage their app's UI state as well. Dan Abramov himself has said many times that redux isn't strictly necessary and using local state is fine, but there are some benefits to having a full, serializable application state. You can capture and include it with a bug report/runtime exception for example. Having redux actions dispatched when users interact with your app can also be useful since you get an implicit global event bus. For things like analytics instead of littering calls to your analytics provider in all of your components' click handlers you can write middleware and keep all of that code outside of your presentation/behavior layer.
- eropple 9y ago> full, serializable application state Perhaps I'm dense, but you can serialize the current running state of a Promise in redux-thunk?
- adamsea 9y agoOne 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 9y agoI 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 https://github.com/redux-utilities/flux-standard-action
- adamsea 9y agoAgreed. 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 9y agoAlso, 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 9y agoYeah 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 9y agoWhy 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 9y ago> 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.)
- adamsea 9y agoFYI we used redux thunk