I like clean code. I like code that makes sense and is easy to navigate. I like code that has no surprises. I also like code that is small; small methods, small parameter lists, small classes. I also like testable code with the tests also adhering to my desire for clean, small code. When I learn new languages and frameworks, I want to learn how to create clean code and tests.
What does this have to do with React.js? Mostly that, in my experience, this has been missing from the React.js code bases I have worked on. Now, I really like the ideas behind React.js; its use of callbacks, params, and state. It creates a very nice unidirectional method of passing and modifying data. What I don’t like is the implementations I have seen of those ideas.
Most React code that I have seen consists of very long chains of components nested inside one another that make following the flow of data incredibly complex. Adding to the complexity is that invariably somewhere in that chain params and callbacks will be renamed.
In addition, the code I have worked with usually consist of very large components. Hundreds of lines of code is not unusual. With the view and data manipulation all munged together in the same file. This means that it is very hard to reason about any one component as you have to read the entire file to understand what it is doing.
My last complaint about React.js is the flattening of data structures. Instead of passing objects around, each component expects a long list of params and then treats each param as an individual bit of data instead of grouping them together into logical, understandable units.
I know it can be done better, what I don’t understand is why the code is this way to begin with. I don’t see anything inherent in React.js that causes developers to create unclean, unmaintainable code. These are just observations and, hopefully, do not reflect the React.js community as a whole. So far though, I am still not sure if I would champion the use of React.js for a new project.