Comment by lioeters
20 hours ago
This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related. In retrospect, over-engineered React code can be worse than decently organized jQuery code, but some jQuery mess was worse than any React code. So I guess I'm saying, React did raise the bar and standard of quality - but it can get to be too much, sometimes a judicious use of old familiar tool gets the job done.
You reminded me of a time where one of my clients asked me to add a feature on a file uploader written in react/redux. This was early 2021.
I kid you not, there were 30+ redux actions chaining in the most incomprehensible ways, the form literally had a textual input, a button to open the file explorer and a submit button.
It took few weeks one of their Romanian team to build it and apparently that team was reassigned and nobody could touch it without them.
I remember writing pages and pages of notes to understand how this all tied up in those extremely complex chains and claiming progress after few hours when I achieved to simplify the flow by removing a handful of these actions. Hooray.
Then it suddenly dawned on me that...I could just rewrite it from scratch.
Nuked the entirety of that nonsense and replaced it with a single useState in a matter of few hours also implemented the newly requested features.
The client could not believe my progress and the fact I also removed many of their previous issues.
Then I had a second realization: React was useless too and it got dropped for native HTML forms and a handful of JS callbacks.
> 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.
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.
2 replies →
> 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
7 replies →
I hear you saying that React raised the floor but also lowered the ceiling.
React made complex interactive UIs a lot easier to manage than jQuery, but that resulted in many developers adding a lot more complexity just because they could.
>> This brought me flashbacks of jQuery spaghetti monsters from years ago, some were Backbone related.
To be fair, jQuery was a response to the the IE and JS variant mess of the early 2000s. jQuery made development possible without debugging across three browser varients.
Standardized selectors was the big use case for me