I prototype React apps rediculously quickly. Here are my 5 key tricks.

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

_{^{Photo by Warren Wong on Unsplash}}

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:

{
  "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!).

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 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.

_{^{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.}}

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...

Comments

[Carl Barrdahl]

Good article, totally agree on the importance of getting started quickly by using npx create-react-app is-awesome and prettier to skip manual formatting. Gatsby is even better in some situations because of their plugins and large ecosystem. Next.js if you're doing server-side things because of their api routes.

Styled-components is great and I would look into theme-ui.com for even more abstractions and allow you to write design tokens inside the elements, eg:

/** @jsx jsx */
import { jsx } from 'theme-ui'
export default props => (
  <h1
    sx={{
      color: 'primary',
      fontFamily: 'heading',
    }}>
    Hello
  </h1>
)

Be sure to check out more of Brent Jacksons [github.com/jxnblk] things!

If anyone looking for more pre-built components I would suggest chakra-ui.com.

Your point about intentionally suspending best pracites is spot on for me. The most important thing for rapid prototyping is the feedback loop. You want to keep it as fast as possible for as long as possible. By adhering too strictly, you might find yourself spending time on things that doesn't bring you closer to results.

Seperate the writing (creating) from the editing.

Once again, good job and thanks for sharing.

[Waylon Walker]

5 is good. I do this often. I still do not sacrifice quality or back myself into a corner that requires a lot of work to back out of. As you describe it all you need to do when you are ready to clean up is move components to their own directory, not rewrite them.

These are small calculated shortcuts that you can easily back out.

I have seen 5 taken the wrong way and bad code was written to get the job done quickly, and honestly sometimes it so bad that its harder to deconstruct what they were trying to achieve and refactor than it would be to rewrite whole components. The right abstraction may not have been discovered and patterns get pasted in 10's of times.

[Mike Bybee]

5 is good so long as you set a limit. If you're hitting, say, 100 lines consistently (with just components, not state or handlers), it's probably time to start breaking up a little sooner.

[Xavier Brinon]

create snowpack app (CSA) is compiling and building faster than create react app (CRA), you might want to have a look at that.

I found that a basic global css file is faster than messing around with css-in-js.
What gets a prototype built quickly is a good design system, like antD, materialui (without the css templates) or any design system that you master.

another way of building quickly is using andybrewer.github.io/mvp/ where the css in integrated in the semantic html.

[Stephan Arenswald]

"It's also about how quickly you can get feedback that'll save you hours of building the wrong features." is the main point here. I got lost in ideas and prototypes so often without focussing on feedback at all. This is bound to fail.

After publishing on gh-pages. How do you drive traffic there to get feedback? Do you ask friends/colleagues/...? Do you have many followers that will try out your newest project and give feedback automatically? ...

[Nico S___]

Very pragmatic, I like it