How to screw up a React project and possibly even want to give up on the library altogether. As I was wrapping up this post, my six-year-old daughter asked what I was doing. I told her I was writing about how sometimes people build software the wrong way. She gave me a confused look: “Why would anyone want to do that!?” The reality is that no one ever starts a project with the intent to fail, but as I have worked with React for the past several years, I have seen a few common patterns of failure in both myself and those around me. Here they are in no particular order. 1. Learning ____ while learning React React is a fantastic library. It’s not rocket science, but it does take a little bit of effort to start “thinking in React.” The fewer things you learn at one time, the easier it will be to focus on what is React and what is OtherStuff™. thinking in React ™. Please don’t take this as a “no kids at the adults’ table” sort of thing. React is a powerful tool and genuinely deserves your full attention as you get up to speed. The following is a good order of operations to ensure learning one of the most popular UI frameworks will be a productive, fulfilling experience. Start with Javascript Fundamentally, React is a javascript library which is a good thing to remember if you are jumping into frontend programming for the first time. Maybe you are taking a stab at building a web app after a decade of backend work. Perhaps you are just getting into software development for the first time. Regardless of your level of expertise, take the time to understand vanilla Javascript. I recommend picking up a copy of Javascript: The Good Parts. It’s a short read and it’s a great resource for understanding the 20% of the language that will lead to 80% of your success with it. Javascript: The Good Parts Grok the ES6 Syntax Is it possible to use React without ES6? Absolutely. However, most of the examples and tutorials for the library leverage the ES6 syntax. And let’s face it, the new syntax is a genuinely useful addition to the language. Even if you don’t work with React, ES6 is a good thing. Here are a few of the many things that will make a lot more sense if you have a reasonable working knowledge of the syntax: The import/export syntax is the new require syntax: import export import React, { PureComponent} from 'react'; You will see destructuring assignment often. It looks like black magic until you understand what’s going on: destructuring assignment const { title, isActive, onClick } = this.props; And classes are one of the many ways to create components: classes many ways to create components export class MyComponent extends PureComponent {componentDidUpdate(prevProps, prevState){...}render() {...}} export class MyComponent extends PureComponent {componentDidUpdate(prevProps, prevState){...}render() {...}} Consider Typescript Typescript is an extended Javascript syntax and transpiler from Microsoft. For large projects and large teams, it’s a definite value-add. For small personal projects, your mileage may vary. React can indeed be used without Typescript, and some people even recommend not using it. However, if you want to try it, it’s a syntax-level thing, so I recommend becoming familiar with it before picking up React. That way when you are looking through React+Typescript examples, it’s easier to distinguish between the two concepts. some people even recommend not using it Learn React Now that you are familiar with the language- and syntax-level constructs, you’re ready to laser focus on learning React. While you may not use it production, Create React App is a great way to quickly scaffold a new application. Create React App Using a “scaffolded” application lets you focus on jumping right into building components from examples instead of having to reason through folder structures, setting up babel, and many other non-React-proper concerns. Granted, you should learn those things eventually, but they will be more of a distraction than anything else at this point. In addition to reading examples from around the web, I highly recommend reading through ALL of the React docs. An integral part of a powerful library is world-class documentation and React is no exception, so take full advantage of that. React docs Explore the OtherStuff™ Now you’re ready to break out and explore all of the wonderful and terrible parts of the React ecosystem. These includes state management stuff like Redux, component primitives like downshift, various drag-n-drop libraries, and other nifty time- and effort-saving packages. downshift drag-n-drop other nifty time- and effort-saving packages 2. Jumping right into advanced React patterns While we’re on the topic of learning React, don’t be tempted to learn all the fancy tricks first. I can’t overemphasize the value of thinking in React. thinking in React React can do a lot of cool things even without any extra libraries or packages. But as with any ecosystem, there are a few React-idiomatic patterns that can reduce duplication and increase reusability. Kent C Dodds has some fantastic material for learning a bunch of really cool advanced React patterns. Here are but a few of them: Kent C Dodds fantastic material Higher Order Component: a function that takes a component and returns a new component which is a technique for reusing component logic. Higher Order Component: Render Props: a technique for sharing code between React components using a prop whose value is a function. Render Props: State Reducer: the sweet spot between an uncontrolled and a controlled component. State Reducer: State Reducer The main reason that I recommend holding off on learning all of these right off the bat is that by working without them, you start to feel a bit of the pain that makes you want to use them. A solution is a problem minus the reason. If you haven’t really internalized problem, you’re likely to implement the wrong solution. 3. Rebuilding a mission-critical application in React as your first project Part of learning, especially in software, is trying things. Sometimes those things work out for the best, sometimes is only by making mistakes that you learn what the “correct way” is. Stated differently, unless you are a literal genius, your first React project is going to have a few gnarly mistakes. This is normal. But knowing this, don’t make that first project a mission-critical one. It’s best to either work on a team with a few experienced React developers or work on a few smaller behind-the-scenes projects first. An in-production application is always better than a half-finished rebuild using React. It can be tempting to take an existing application and throw React at it to make it better. This is not impossible, but retrofitting an existing application is more complicated than green-fielding a new one. Additionally, when you are working with an application that is already in production, there are a lot more concerns to juggle than just mastering React. All in all, it’s best to only tackle those risky projects once you or your team have accrued a reasonable amount of experience. 4. Using Redux before you really need it Redux is the library that everyone loves to hate. Some of that is just your average everyday ordinary flame wars. Fundamentally, Redux is a tool for managing application state. Other tools do the same thing, including React’s built-in component state and context features. Redux is a trade-off between reasoning about asynchronous mutability and indirection. For smaller projects, the pain of asynchronously modifying state might not be that bad. Are there other ways to manage state for large applications? Absolutely! Using the wrong tool (or at least not the best tool for the job) will leave a bad taste in your mouth. In such a case it’s even easy to blame the tool. This is actually one of the reasons that learning React before Redux is so strongly recommended. If you can successfully build an app without Redux, the cost and complexity of adding it is by no means a value-add. That being said, it is also crucial to understand why the Redux tradeoff provides value. Adding Redux in at the beginning of a project is cheaper than shoehorning it in once “state hits the fan.” It takes a bit of experience to understand the vision for a project and from the outset know whether or not Redux is needed. why 5. Using alpha features in production The React team is working on awesome new stuff all the time. If you have been around React for at least 10 minutes, you have by now heard about React Hooks. As cool as hooks are, you probably shouldn’t be using them in production. Now, it’s not a bad idea to start digging into what the new features are and how they work. As new functionality rolls out, it’s crucial for thought leaders to experiment with the new patterns that shake out. If you want to a seat at that table, by all means, roll up your sleeves an get your hands dirty. But also keep in mind that it took a couple tries to get React Context right. Just because something is new and gets a ton of exposure on social media doesn’t mean that it’s ready for prime time. It doesn’t mean it’s NOT, just use good judgment. All that being said, the React Team does an absolutely fantastic job of ensuring backward compatibility when adding new features. Because of this, it is easy to pull in the latest version of React and then slowly experiment with how new features will work in YOUR application. This strategy keeps risk low and lets you progressively adapt to new things. Do you think that Facebook is going to refactor eleventy billion lines of code to remove class components overnight? I don’t either. 😃 It may be tempting to jump right in and use all of the shiny cool new stuff. Learn the new stuff, but don’t use it in prod. 6. Porting a project directly from _____ to React All languages and frameworks have personalities. They each have their own set of quirks and patterns that lead to idiomatic ways of coding. React has ___ context. Angular has directives. Vue has watched properties. Elm doesn’t have null. null There are a number of valid reasons for porting an application from one UI framework to another. Perhaps you have been experimenting with a few options and are starting to standardize on a standard set of tooling. Maybe you have a new codebase that came in as part of an acquisition. There are a number of valid reasons. Just keep in mind that ports are more complicated than just “build the same thing, just do it in React.” There aren’t one-to-one similarities between any two UI frameworks which means that you cannot simply start porting an Angular project component-by-component to React. Code that might legitimately live an in Angular component might live in a Redux Action Creator in your new codebase. Somethings like RxJS just don’t have a direct analog in (vanilla) React at all. Generally speaking, it is a good practice for the transition team to have a subject matter expert for both the old and new frameworks. By doing so, you will have a better handle on how to translate the semantics and intents, not just naively transliterate the code structure. 7. Ignoring server-side rendering For better or for worse, Javascript also runs on the server. By running a service in NodeJS, you can run React on the server to render pages before they get to the browser. Server-Side Rendering (SSR) isn’t required, but I’ve found that it isn’t leveraged nearly as frequently as it could be. The two main benefits to SRR are: Shorter time to first meaningful paint: The browser can begin rendering the page immediately without having to evaluate any Javascript code or make any further network requests. Shorter time to first meaningful paint: Better SEO: Search engines crawling your app will get an actual page, not a blank document with a massive bundle. Better SEO: But it isn’t all daisies and sunshine. Figuring out how to set up the initial application state during server-side rendering is a nontrivial task. It also requires that you run an actual server (or NodeJS-enabled “serverless” alternative) on which to run your React application. One of the hardest parts of the whole endeavor is ensuring that the server-only code doesn’t contain browser API dependencies and vice-versa. For example, window and document are undefined on the server. If every code path in a component render function depends on document, then that component will break when rendering on the server. If you go into a project only thinking about client-side rendering, then it makes it a lot harder in the future to implement SSR. window document document This is not to say that every site needs to be rendered server-side. There is a lot of value in serving a simple SPA from a CDN. However, it is also worth taking the time to wrap your brain around how SSR works so that you can easily use it when needed. Like what you see? I enjoy helping people win at React, and I hope that you found this information to be useful. If you have seen any other common React mistakes, I’d love to hear about them. And as always, if you enjoyed this article, please feel free to give it a 👏 or two!
