Do any research into current front-end development, and you’ll hit React pretty quickly. As far as modern Javascript frameworks go, React is probably the standard Javascript framework used by startups and other companies that haven’t already heavily invested in another front-end framework. While React does a decent job of packaging up HTML and Javascript into reusable components, there’s been some design decisions around handling application state in React, namely by using a framework called Redux, that make developing applications harder than it has to be, and make it worth your while to look for other options before you start falling into its rabbit hole too.
React, taken in small doses, looks like a very good Javascript framework. It excels at small, self-contained components, and exporting those aforementioned components so everyone can use them. If you have multiple teams each of which may be doing some front-end work, it helps keep your UI consistent. Where it starts to fall apart, is when those components aren’t just self-contained, but start having to interact with each other.
On the surface, Redux solves these problems. It’s basically shared state for all your components. Great, now all you have to do is hook your components to this shared state framework and once again your components can be small and simple and even update based on actions taken elsewhere in the application. Surely the details of of implementing Redux aren’t so complicated that it’d utterly eclipse the benefits of this shared state framework, right? Wrong!
The biggest part of the problem is that linking your component to Redux is an incredibly brittle process. Names have to match exactly across everything. If your property name doesn’t match the name you used in the reducer for Redux, everything breaks, because normal variable scoping doesn’t apply anymore. By the way, mapping reducers to properties makes no sense as a concept. Properties are what I would expect to be the least mutable part of a component. I’m not saying property values should never change, but given that we’re talking about a component’s state, one thing that changes with every keystroke and mouse click, by design. You would think that Redux would be mapped to something intended to be mutable, like a pre-existing state object that can be updated using a standard setState() method.
Part of me wonders if this Redux nonsense is an attempt by front-end engineers to make immutable objects. That was an approach that got a lot of popularity with Scala, but Scala was designed for an entirely different type of programming to solve an entirely different type of problem. Front-end code is literally all about manipulating and changing state, it needs to be mutable. Based on reading about Redux, they aren’t explicitly saying this, but the emphasis on mapping everything to properties generally attributes mapping everything to properties (being famous for being mutable and constantly changing) to being the “React way of doing things,” so it’s definitely deliberate.
As I mentioned earlier, all of this makes Redux easy to break and hard to debug. I’ve wasted hours trying to figure out why my components weren’t synced up only to realize that I broke everything by renaming a variable. And that’s not counting the hours spent trying to figure out how to hook this application-wide state into my component properties, even though I did it the exact same way as another project did and that other project worked. “Fickle” doesn’t even come close to describing how Redux works in practice. In theory you can use it for any front-end framework, but so far only React seems masochistic enough to actually use it.
The good news is that React is trying to fix its reliance on Redux with hooks. From what I’ve seen (because I haven’t had to try them out yet), hooks are what Redux should have been all along – an abstraction that lets you get and modify application state, but without all the “do it your own d*** self” plumbing. In fact, all you’re doing is providing a variable name and the name of a setter function. Everything else is nicely encapsulated behind the scenes so you don’t have to deal with it.
Redux has hurt React development by making it overly complicated and prone to breaking for non-intuitive reasons (and with non-intuitive error messages). Actually implementing it in a project involves coding your front-end in a manner that’s hard to understand and invites problems. Luckily React seems to feel its developers’ pain and has introduced a better way to handle application state. Sadly, it means moving your component from a class to a function, but that seems like the sort of change people who aren’t full-time front-end developers can probably learn to live with. And it results in turning Redux into a thing of the past, then it’s worth it in the end.