If that works with your model of the world that's great. Wouldn't kick it out of bed for farting.
For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. That's what it's for. It makes it possible to have a real message based architecture without hacks and (extra) libraries.
Redux is fantastic and it's quite a simple library. The rest is what gets you into trouble.
Hardly anybody has a problem with redux until they have to deal with async actions but all the tutorials use thunks or sagas when the correct way to handle that stuff is to write middlware.
By real messaging I mean CQRS with event mapping/filtering/normalization.
> Redux is fantastic and it's quite a simple library.
... and it's an extra library. You can do without it in React, you know.
> The rest is what gets you into trouble.
Exactly. My biggest beef with Redux (and React, too) has always been that it makes much pomp about things that are relatively easy to solve, like state computation (or rendering). The actually hard things are left unsolved to a various degree, and that is what devs struggle with the most. Things like: how do I take the business logic best expressed in imperative statements (get foo, if it equals to bar, do that, if not, do something else), and express it in React component state transitions, with loading state indication, error handling, and conditional branching?
The most contrived React code I've ever seen was dealing exactly with that: fitting a finite state machine into a React component, which Redux is essentially zero help with. Why do I need Redux if it doesn't solve the hard problems for me?
> Hardly anybody has a problem with redux until they have to deal with async actions
Srsly? So tons of boilerplate, action at a distance as a blessed pattern, reliance on globals, contrived testing, and perf issues are not problems at all?
> the correct way to handle that stuff is to write middlware.
There are as many correct ways to handle that stuff as there are developers. Some ways are just easier to read and follow (also to test, maintain, etc etc).
> By real messaging I mean CQRS with event mapping/filtering/normalization.
Thanks for the explanation. You forgot to answer the second part of my question, which is: why this is important for a front end application. Again no sarcasm, just genuine interest.
I didn’t forget to answer anything, you are just treating this like a debate. While I understand why, it would do you some good to be more humble. You’re pretty junior and you still have a lot to learn.
For me, the easiest way to handle async and effects in Redux is to write custom middleware for each context/entity. That's what it's for. It makes it possible to have a real message based architecture without hacks and (extra) libraries.