One of the best things about React is how large and vibrant its ecosystem is: there are robust libraries to help with everything from forms to HTTP requests to state management, making it far easier to build incredibly complex and scalable applications.
Unfortunately, when you’re first starting out with React, it can be incredibly daunting to figure out which libraries you need and how to set them up. It certainly doesn’t help that, when you start Googling how to wire everything together, you’re probably going to read somewhere that you should reach for a boilerplate project. These projects are usually meant to be highly scalable and feature-rich, combining a variety of bleeding-edge technologies in a way that should, in theory, save you hundreds of hours.
However, boilerplate starter projects are the very worst thing that you could use as a React beginner.
When you’re first starting out, your project probably doesn’t need to be isomorphic. You don’t need bundle splitting, you don’t need internationalization support or offline-first, and you don’t need advanced routing. In fact, you probably don’t need Redux at all!
Not familiar with the magic of Redux? Redux is a library that stores the entire state of your React application inside of a single store object instead of setting it on a per-component basis. Learn more about it here as part of our React 101 series.
If you’re not sure whether you’re going to need Redux, especially if you’ve never used it before, you should strongly consider starting with vanilla React. Even if you think your app might get to the size where you could benefit from centralized state management, there’s a lot of benefit in feeling out the architecture you’re going to need without having the additional boilerplate of Redux weighing you down.
So, you might be asking—when should you actually use Redux? You’ll know it’s time to consider adding Redux when some of the following things are happening:
- You’ve got a few large, bloated components at the top of your hierarchy that are keeping track of wildly different pieces of state for the children of their children of their children
- You have components on separate ends of your application that are requiring the same piece of state, such as data fetched via a HTTP GET request, in order to update
- You can't keep track of long chains of
props - You’re having trouble tracking the order of changes for all of your different components, causing race condition bugs
- You are running into situations where components are unmounting before promises are resolved, and you’d rather unsubscribe from a store than try to cancel a promise
Once you get a firm understanding of how to use vanilla React and architect a project—ideally, going through a round or two of refactoring in the process—you'll start to feel the pain of state management when your app gets complex enough. At that point, it might make sense to spend a day or two re-working pieces of your app to use Redux. There is also no rule that says once Redux is in your application, you have to use it for managing every single bit of state; you don't have to tear down your application to the studs in order to implement centralized state management. Refactoring the problematic pieces first is a totally viable solution that should ease some of your state management woes without a huge time investment.
React doesn't have to be complex; it was originally designed to be the View layer in MVC, and it still excels at that. If you have small, discrete components with basic functionality, or a modest single-page application, you probably don't need a ton of bells and whistles. Once you start hitting the limits of vanilla React or the fetch API or client-side rendering, that's the point when you should start looking into adding extra libraries to expand the functionality of your application. At that point, boilerplate projects can be incredibly useful to help figure out how to add another ingredient to the mix—and best of all, once you add it yourself, you'll know exactly how it works.
Don't make front-end development harder than it has to be.
Get our latest insights
in your inbox:
in your inbox:
Hey,
let’s talk.
let’s talk.