Given the breackneck pace at which changes happen in the frontend, JS, and React worlds, I found it quite refreshing to find a book that dares to posit best solutions for different problems that React developers face. Given the open, "pick-your-own-adventure" nature of the React ecosystem, I got excited to see someone taking a bolder, opionated approach.
Being opionated myself, it was a near certainty that I would run into takes that I disagree with. While I’ll spend most of my time getting into those differences, I don’t want to minimize how useful I’ve found this book. Even more importantly, given the tendency to want sing kumbaya over meaningful differences in approach in the React community, I appreciate the attempt to make a strong case for certain practices and libraries over others. What follows is not a full review per se, but some discussion about the sections that were the most interesting to me.
State Management
The External Library Question
In general, I consider this overview of state management libraries to be very important reading for any aspiring React developer. It’s well-considered to start from the most local approach to state management possible, to then mention Context once the needs get more sophisticated, and to only after that point bring up the fact that external libraries exist to help with more complex systems.
There is a very important distinction to make that does end up kind of muddled here (perhaps intentionally to avoid burdening the beginning React developer with extra details). The problem of "state management in React" (or really any other library modern frontend UI library) is twofold:
- How to handle and update increasingly complex state
- Where the state should be located
Making this distinction helps to clarify what we are trying to solve for when we reach for a "state management library" and allows us to realize that some commonly marketed solutions only address one of those issues.
This does not have to be a problem if you understand this distinction. In fact, my current approach for a more complex application would be to use a (1) library that makes working with immutable state more reasonable combined with (2) React Context to deal where and how to locate state.
Overmind?
What was probably the most surprising to me in the book was the suggestion of Overmind as the go-to for state management. I confess that I had not heard of this library before reading this book.
I appreciate bucking the tendency to suggest Redux just because that’s what everybody else is doing for state management. From my impressions so far, Overmind does indeed seem more intuitive and less complex than Redux.
But I must begrudgingly admit that it is a bit of a disservice to not mention Redux more than in passing for a book that purports to be a "guide to React." While I am mostly aligned with Sara’s opinion about Redux here, the fact is that most professional React developers will continue to encounter Redux at some point in their careers for the time being. Redux (perhaps aside from React Router) is the most commonly used library in the React ecosystem.
TypeScript
Strong Differences
This section of the book is the main reason I felt compelled to do this writeup. So when does one need TypeScript? According to the book:
When you can’t manage state, and you have no idea wtf is what anymore, and how many isLoggedIn states you have in your store, you need TypeScript when you would rather cry than manage state.
(Opinionated Guide to React, Sara Vieira, p. 15)
I’m not sure I understand the inclination to tie TypeScript to managing complex state. That is definitely one area in which TypeScript will shine in a React app, but merely one.
The benefits of static typing tools like TypeScript are well-documented, particularly (but not only) for larger teams.
More Complex Code?
The point is well-taken that tools such as TypeScript can sometimes "[create] a barrier for people to get into web development in an open and accessible way," as she writes, but I think this goes too far in eliding what the clear benefits are in making codebases more understandable rather than less.
In my post about getting up to speed with React and TypeScript, I outlined two benefits to TypeScript:
- Type Safety: This is what helps prevent you from lying to your code. You can code with the confidence that a value that is supposed to be a number is in fact so.
- Documentation: Self-documenting code is the best code. This is precisely what we achieve with TypeScript usage. It is, all of a sudden, much easier to open a file in a large codebase and at a glance get a sense of what’s going on.
One can perhaps disagree about whether TypeScript actually succeeds on these fronts, but it strikes me as too reductive to say TypeScript === hard and too burdensom for people entering web development.
We Pick Our Complexity
It’s also worth noting that we pick the tools that we use and often make decisions about how "accessible" something is without enough regard to the subjectivity of those assessments.
In another section of the book, Sara strongly endorses Gatsby, a tool especially useful in creating static that itself has somewhat of a learning curve. In particular, it heavily leverages GraphQL, a query language that a lot of frontend developers are not familiar with.
The point is not to cast doubt on the fact that it will be very useful for a React developer to master Gastby, but merely to shine a light on the fact that most powerful tools require some investment upfront.
Nevertheless, I am grateful that she goes over TypeScript in the book with an example to follow along with as well.
Conclusion
A common theme among my reaction to this book is the debate around the idea of whether we should discourage solutions because they are somehow perceived to be "less accessible" than otheres. Progamming is not easy, and while we want everyone to be able to learn it, we should all strive to be experts and constantly be improving our skills.
Admittedly, I also would not suggest that a front-end developer learn TypeScript before they learn JavaScript (does that even make sense?). Or before they learn React.
There is always a tradeoff.
(Opinionated Guide to React, Sara Vieira, p. 19)
Agreed, and this is often the case between the sophistication of tool and its ability to solve complex problems versus accessibility on the other hand.
That being said, overall this book was a very good read from someone that probably as a different perspective than me on a lot of things. It should also be said that this is an impressive undertaking, to go that much into detail on different problems that React can help you solve.
I would love to see a follow-up or perhaps a second edition that goes more into leveraging code structure and design patterns to improve the ease of working with React.
Overall, I’m happy to see a book that reads like a list of first-class recommendations. It’s definitely a book that I’ve been waiting for and I highly recommend it.
Recent Comments