Hacker News Reader

Comment by normie3000 | Hacker News Reader

> I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways

I 100% believe this, as it describes all the redux codebases I've seen. The library seems to be an antipattern of indirection.

View on HN

This sounds like an engineering quality problem rather than a tooling problem.

Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.

Redux Toolkit has been a nice batteries-included way to use redux for a while now https://redux-toolkit.js.org/

But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.

I took a look at the quickstart guide at https://redux-toolkit.js.org/tutorials/quick-start and to me it still seems to add a lot of indirection.

"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.

This brought back flashbacks of a brief moment when I was left as the sole maintainer of a “soon-to-be-axed-but-currently-critical” feature in a checkout flow developed by people who A) knew redux and B) were not me. They recently implanted some state updates before departing, and the bugs for that fell to me. I think I spent a few days tracing the code and understanding how they managed their state, and I think I needed to touch about five files to fully encompass the updates for one data point - I felt nuts!

> The library seems to be an antipattern of indirection.

Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).

I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself

Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy.

Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill

https://rxjs.dev/guide/observer

True but rx was even more niche than redux. It was much easier to hire redux devs

you got to the crux of it. Redux became a trend, surfing on its popularity at a time React wasn't providing the reactive piece it needed, plus the time machine demo just amazed everyone. The author got his job at Facebook. It carried millions of developers to use that lib, the author even said it isn't necessarily the go to mechanism, but hiring manager stuck with the idea that all projects redux magicians, since all projects needed React.

For the anecdote, I remember my manager admitting we can't fix the legacy app, but we can put lipstick on the pig with React.

Have some pity for those Senior Expert Architect Full-Stack Developers (fresh out of boot camp) in urgent need of job security.

The original developers weren't bootcampers but engineering graduates.

And in the same way faang is filled with leetcode blackbelt charlatans writing slop, so is Romania apparently.

Great generalization of an entire country's sector workforce.

I'm sure you'd 100% approve of such a statement of your country when based on one anecdotal recount (even if it true).

It's not about Romania or any other country.

I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.

It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.

Reply on news.ycombinator.com