Is it the lack of platform API support? Is it the community trying to make everyone a library developer? What's wrong with frontend?
In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded.
I need to update a remote resource. But wait! Sometimes that can fail. I need to capture the failure logic and make appropriate ui changes. There are 4 types of errors and they require doing some library logic to figure out what to display.
But wait! I want to wait 250ms before triggering any state updates, or else the ui transitions will feel buggy.
Oh, and product now wants to make sure we capture some random third party tracking event in between specific state changes. The ui MUST NOT change until the tracking call succeeds.
This and more is trivial in redux saga, and you can write tests around it.
Today, our recommendations are:
- Data fetching: default to using RTK Query, fall back to thunks if needed
- Responding to actions or state changes: use the new RTK "listener" middleware as the main approach
See my recent talk "The Evolution of Redux Async Logic" for details:
- https://blog.isquaredsoftware.com/2022/05/presentations-evol...
as well as my recent presentation going through "Modern Redux with Redux Toolkit":
- https://blog.isquaredsoftware.com/2022/06/presentations-mode...
And now there are multiple deployed production apps with real users, so it’s almost certainly never going to be replaced. The cost would be enormous.
But as I put it in my "Evolution" talk: "Sagas are like a chainsaw. Really powerful, and really dangerous. If you actually _need_ that power, great! But most of the time you don't actually _need_ to use a chainsaw on a daily basis."
As the sibling comment said, a lot of times sagas really do end up as spaghetti code, largely because they are so event-driven, and with all the use of generator functions that can make debugging hard. (Ironically, the original Flux Architecture was created to _avoid_ the problems of Backbone-style event triggers causing events to ricochet around the app without a way to understand how things would update in response, and sagas can end up recreating that problem with Redux apps.)
You can do all of that pretty easily with a vanilla redux.
> In addition, if you want to have your app load as smaller chunks rather than a single large bundle, you need to be careful to ensure that things work even all the backing reducers aren't yet loaded.
In the decade old application we use redux saga in at work, a large portion of our 7MB minified/gzipped main chunk is redux handlers. It'd be nice if there was a relatively simple way to not synchronously load all the reducers up front.
- https://redux.js.org/usage/code-splitting
There have been some different community packages for helping with that process, but some of them seem to have become outdated (only worked with React-Redux v5, etc). I did see a new one at https://github.com/fostyfost/redux-eggs that seemed like it had potential, but I haven't had a chance to try any of them myself.
I also once saw someone play around with the idea of using React's still-not-technically-final Suspense support to help ensure that a lazy-loaded component that relies on a code-split reducer doesn't actually get rendered until that reducer's state is available. Don't have the link handy atm, but if someone wants it ping me and I can go figure out where that was described.
Also, the new RTK "listener" middleware was specifically designed to replace almost all saga usages, and you can dynamically add more listeners at runtime via dispatch an `addListener()` action:
- https://redux-toolkit.js.org/api/createListenerMiddleware
- https://blog.isquaredsoftware.com/2022/05/presentations-evol...
I think the same is true of 3D libraries. The real work of making an app that does 3D is not the 3D engine, it's everything else (UX or GameDev). The 3D part has well known goals and solutions so it feels like you're making a ton of progress, ie, it's fun to make. Much easier than deciding harder things like which features your app should have and how they should work.
How many ways are there to build an API? In Python: Falcon, Flask, Django, FastAPI and so on. Just as many choices in Java, Go, Node, <insert your favorite language>.
"Necessity is the mother of invention" comes to play here. The reality is that the community hypes certain tools, but in practice, they tend to have gotchas buried far beyond the surface level demos and documentation. The problem with that is that you only figure that out after committing to those tools and using them. This leads to tool abandonment, or in some cases, developers taking a swing at their own version. What they come up with is more often than not a rehash of the old ideas but lacking any "why" or long-term vision.
The other one is employability by obscurity. An old grifter trick is to make something far more complicated than it needs to be as a means to guarantee employment (both on the tool developer side and the end-user side). For the tool developer, the more they can twist and turn their tool (introducing novelty and potentially confusion), the more sought-after their services will be. For the end-developer, they can hold a "monopoly on intelligence" and become difficult to replace in a company because they're the only one that understands that thing. Couple this with the conference talk circuit where you see the same people constantly pitching some new-fangled widget every year and you realize the goal isn't to solve the problem, it's to get paid to look like you're solving the problem.
Another problem is inexperience. A developer might have just enough experience to feel confident at the code-level, but they lack the practical experience to let them know why a certain pattern is incorrect. Assuming that they never get that practical experience, they will continue to iterate the tool into an utter mess or deprecation.
This is the age-old question. You're using Redux now, but I'm sure some JQuery/Angular/Knockout/etc dev said the same thing about what you're using back then.
The front-end is crazy and I don't think there's an obvious answer of why it's such a developmental disaster. It's easy to say it's run by script kiddies or the barrier to entry is too easy, but there are a lot of smart devs working on the top libraries. The culture just ended up this way. Whatever is driving it probably will never stop though. Enjoy the ride. lol
The people-software interfaces for many of the commonly used pieces of software will always be complex as we will always demand a lot of our software, up to the limit that can be provided by the available tools for building these apps. As our capabilities for building better software grow, so too will the demands of the users.
If you aren't buying this argument, sit down and map out every single possible state and every possible event (user interactions, etc) of a moderately-sized app that you use regularly. Or even just one page of that app. There's a lot going on. It feels simpler than it is when we are using it because well-designed applications become invisible to the users, especially as we become familiar with them. They "just work".
TL;DR Reality is messy and complicated. And so is the software we build as well.