When to add additional tooling to React projects?
If you look at any reasonably sized React app, you’ll likely notice a number of additional tools and libraries being used alongside. Some examples we’ve used frequently on our projects include Redux, Reselect, React-Router and Redux-Forms. The question for a lot of beginners is when to reach for these additional libraries.
Truth is, you can build an entire application without utilizing any of these tools, and in almost all cases, you should attempt to do this when starting out on your journey with React. Routing/Navigation may be the one tool I’d recommend learning early on if you plan on supporting url routes. Yes, you can avoid React-Router, but I’m not sure the alternative self-implementation is easier to understand and maintain (to start out). I believe React-Router has an approachable API for doing simple routing and shouldn’t be a large cognitive leap for beginners in the way that Redux or Reselect can be.
As you continue to build your projects and skills in React, you’ll notice a recurring theme. You’ll start to wonder if there are “better ways” to solve that particular problem. One of the very first places you’ll start to ask this question is around managing state.
Managing state
This becomes tricky as the number components increase and managing their shared state becomes difficult. The number of callbacks from containers/pages to child components (especially if they are nested several levels deep) becomes fragile and hard to keep in your head. The most popular solution in the React community is to reach for Redux. Redux solves this problem particularly well, but it introduces a set of new problems and decision points.
The first problem is simply the learning curve. Redux (Flux in general) can be conceptually difficult for a lot of newer developers. I personally trained a number of folks on React, Redux and a number of other libraries and can say that Redux was the single most difficult concept for them. This isn’t an issue with Redux as it’s trying to elegantly solve a very complex and critical piece of the application (state management) using a small set of ideas. The alternative is what most applications usually resort to, each developer introducing their own state management mini-patterns spread throughout the application, which is easy in the beginning, but becomes an unmaintainable mess over the long-term. So Redux attempts to consolidate state management into a small set of pattens that make your state more predictable to maintain. Redux is very simple (and very well done), but the concepts, patterns and language are probably foreign to what most developers have used and learned over the years.
The second problem you will run into when adopting Redux is naming and organization (files, action constants, action creators, how to segregate responsibilities and files etc…). When we started our journey into Redux, best practices didn’t really exist yet. You may choose to follow something you’ve seen (like conventions used in Dan Abromov’s free video series on Egghead) or come up with something totally your own. If you’re developing a project solo, then naming probably won’t cause any trouble, but if you’re on a team of developers, this can become frustrating very quickly, so deciding on those conventions early on will save you a lot of confusion and refactoring later.
Our team decided to come up with our own naming conventions and patterns around how we utilize Redux to minimize the number of decision points developers had to make for each new piece of state and reducer logic. These decisions were a compromise between “correctness”, “simplicity”, “productivity” and “ambiguity”. We chose what made sense to us and what we value as software developers.
Summary
Start simple, don’t reach for those external libraries until it hurts. If you’re an experienced developer, you’ll know when that voice in your head starts nagging at you saying “There’s gotta be a better way”. If you’re a new developer, start simple and once you’ve built out a reasonably sized project, go and explore what those tools have to offer. The context of having seen the problem first hand should help you understand the new tool. It’s hard to use a tool that solves a problem you didn’t know you even had. Learning concepts and abstractions without real hands on experience is hard for almost anyone.
