I prototype React apps rediculously quickly. Here are my 5 key tricks.
Tags: react, productivity, github, css
Published: 2020-06-01 20:42:39

Speed with React isn't just about experience. It's helped by tooling, modularity, and strategy. Let's dive in!

<sub><sup>Photo by Warren Wong on Unsplash</sup></sub>

## 1. Use `npx create-react-app my-app-name` to get up and running instantly

(The obvious trick)

## 2. Use `yarn add prettier --dev` to auto-format your code, so you can focus 100% on building rather than syntax/formatting

Steps I follow:
- enable prettier to run when a file is saved in your IDE (google it for your IDE)
- since I hate semicolons and double quotes, so I add this in a `.prettierrc` file in my root directory to override defaults:

```javascript
{
  "singleQuote": true,
  "semi": false
}
```


## 3. Get fast feedback your work via instant Github Pages deployment

Building stuff fast isn't just about your coding speed. **It's also about how quickly you can get feedback that'll save you hours of building the wrong features.** A quick way to share your React app is essential.

Github lets you host a static webpage for free for a given repo. 🎊 By default, it serves whatever `index.html` is on the `gh-pages` branch root directly.

*... which is a pain for `create-react-app`!* 😦 What you store on GitHub is actually just the code that gets transpiled and built *into* a valid web app with an `index.html` etc via `yarn build`.

To get around this, [there's an npm package that automatically builds your app and publishes that built app to `gh-pages` branch when you run the command `yarn deploy` (so easy!)](https://dev.to/yuribenjamin/how-to-deploy-react-app-in-github-pages-2a1f).

## 4. ❌ Delete as the default `index.css` and `App.css` files -- instead use modular `styled-components`

Anyone who's worked with vanilla CSS files (which are applied globally) knows how much time can get lost to unintended side effects as your css grows. It's hard to know what's affecting what. 

And, when building fast, you often use a mix of css files and in-line CSS directly on components (eg `<div style={{color: 'red'}}/>`). This makes locating css code even *more* of a mess. 🙄 

Using [`styled-components`](https://github.com/styled-components/styled-components) means you can assign CSS that gets applied only to a specific React component, and you can write vanilla css directly in Javascript (no file hunting, no camel case such as `backgroundColor: 'blue'`). 

### This hugely speeds up dev time:
1. **It lets you focus on one component at a time**, rather than having to wade through multiple files and correct app-wide style issues
2. **It makes it fast and easy to share components (and styling) across your projects**. Why? You can now paste a styled component and be confident it'll be styled exactly as it was in the previous project. Also, it's easy to locate its styling, if you want to pull a specific piece.
3. **It makes it obvious where and how to re-use components and styling**, increasing efficiency *and* UI consistency.

<sub><sup>To those hesitant about yet another CSS library: I was a `styled-components` skeptic. Ten minutes after using them, I was hooked. I've never looked back, or worked more quickly.</sup></sub>


## 5. 🙈 Intentionally ignore (some) best practices. Code in ways that let you build fast, like with long files with multiple React components in them

When quickly creating an app, **it's helpful to have all the code you're creating and reasoning about directly in front of you**. I usually just do stuff in a few giant files, then decompose them nicely later. Why?

### In coding, focus and energy are usually your limiting resources, not time.

If you spend a lot of thought formatting your code perfectly early on, that drains the focus and energy you could have used to build quickly. Even more, **your codebase is likely to change drastically early on**, so that energy might be completely wasted shortly after.

*But doesn't decomposing your code make it easier to work with?* 

Yes, but generally this payoff comes *after* you finish a prototype and need to scale it or share it with other developers (or your future self). When prototyping, the code is fresh in your mind, so just build in whatever ways is easiest.

----

*Wishing you code speed!*

---- 

Leveling up your React game? Here's a story about [what it feels like to invent React from scratch](https://dev.to/davidnmora/oops-you-accidentally-invented-react-js-35ac)...