Learn React’s fundamentals without the buzzwords

Companies everywhere are moving to React, and for good reason. It makes building real-world apps a breeze!

But React comes with a boatload of buzzwords. Redux and GraphQL and Webpack and JSX and how am I supposed to get anything done when keeping up with the ecosystem is a full time job in itself?

Forget the buzzwords

A few years ago, I’d grown tired of learning new tools every other week. I wanted to make something that’d last, so I created a short guide called Learn Raw React. It teaches you the fundamentals, and completely skips anything that could change – there’s no webpack, no redux, and even no JSX!

Now you might think that you can’t do much with just Raw React. But surprisingly, developers loved it! They found that focusing on Raw React revealed what’s really going on, and it helped them feel more confident with real world code to boot. Even one of Redux’s co-authors chimed in:

But while developers found themselves more confident after learning about elements and reconciliation, React was still in it’s infancy. Many patterns had yet to be discovered. And many APIs were still just sparks in the React team’s imagination.

Raw React is becoming more powerful… and more important.

Fast forward to 2018. React’s API is growing again. Planned features like Time Slicing and Suspense will let you do more with React itself. More people are replacing state management libraries with plain component state… including people within Facebook itself.

New React APIs mean less need for 3rd party tools. More than ever, your career depends on a deep understanding of React itself.

But despite the growing importance of the fundamentals, many still struggle with the same questions:

  • What’s the difference between elements, components and instances?
  • How does JSX actually work?
  • Why should I use key props with arrays?
  • When is it ok to use this.state?

I’ve seen how valuable Raw React can be as a tool to build confidence with the fundamentals. But there’s only so much you can put in a blog post…

Learn the fundamentals without leaving your browser

I believe that to truly master the fundamentals, you need actual experience working with them. I don’t want to waste your time on feel-good bullshit lessons that you just use to pacify your boss. I want to help you truly master React’s fundamentals. And that’s why I’ve put together a new learning platform for React and JavaScript, called Frontend Armory. It launches with a complete course on the fundamentals, called React (without the buzzwords).

This course is composed of 30 lessons, with 55 live examples and exercises. It lets you save your progress through lessons, and automatically saves your exercise answers so you can pick up where you left off. The course is designed to encourage you to learn by doing — the only way to truly learn something back to front. Curious how this works? Take a look a this lesson, which compiles and runs JSX for you as you type:

See what’s really going under all the JSX »

By working through the course, you’ll also gain experience with real-world code – you won’t be stuck building counter components. By the end of the course, you’ll have built a full contact list with form validation, asynchronous storage, and proper structure.

What you'll build in React (without the buzzwords)

Like a book, just better

React (without the buzzwords’) lessons are text and exercise based. There’s not a video in sight.

This has a number of benefits. It’s easier to re-read a paragraph than to rewind a video. It’s easier to skim ahead. And it’s easier to look back and forth between the text and the exercises. This is crucial, because the exercises are how you really learn the fundamentals.

It’s an investment

There are many patterns and APIs that you’ll need to understand to advance through your React career. Frontend Armory can help you learn these! But creating effective courses takes time. This course took months to create.

On the flip side, investments have returns. You will become a better React developer by learning the fundamentals. And you will be able to command a higher salary if you’re a React pro.

React (without the buzzwords) is exclusive to Frontend Armory Pro members. Of course, there’s more benefits to Frontend Armory Pro than just this course. And if they’re not worth far more than the price of the monthly membership, then please send me an e-mail and let me know why! But otherwise…

[bctt tweet=”New React APIs mean less need for 3rd party tools. More than ever, your career depends on a deep understanding of #reactjs itself.”]

Are you ready to invest in a solid foundation for your React career?

Learn React without the buzzwords

Start by trying out the 8 free lessons – just click the link below. There’s no signup required, you can get started immediately!

Learn how elements are just objects »

Want to know if the course matches your level? Not sure if the format suits you? Or maybe you just want to have a look first? Then try out the free lessons – you’ve got nothing to lose!

Or if you’re ready to get started? Great! You’ll get a special launch discount until the 31st of August. So head on over and join now before the launch sale ends:

Join Frontend Armory Pro »

Lastly, I just wanted to say thanks to you for reading this blog! I couldn’t keep going without the support of readers like yourself. So thank you! And stay tuned for more details on Frontend Armory coming soon 🙂

Got any questions about React, Frontend Armory, or JavaScript? I’d love to hear from you! Send me a tweet at @james_k_nelson!

I will send you useful articles, cheatsheets and code.

I won't send you useless inbox filler. No spam, ever.
Unsubscribe at any time.

Smash out React code with skills you learned years ago

The React ecosystem can feel a little overwhelming at times. The countless libraries to keep track of. The ever expanding toolchain. Even the language itself is changing! And the worst thing? The moment that you think you’ve got a grasp on it all, it slips away as a new version changes everything.

It would be so much easier if you could smash out productive code with skills you learned years ago.

Which brings me to a little secret…

React has barely changed in 2 years! In fact, Dan Abramov recently tweeted that the examples in React’s official tutorial used a 2 year old version of React.

Here’s the thing. React’s ecosystem moves fast, which is exactly why you need to focus on the fundamentals. Studying React itself will pay dividends for years.

Skills that last

Let me tell you a little story.

Way back in 2015, I started this blog because I wanted to teach people JavaScript. But I had a problem. Every time I wrote about a new tool or package, my article would be obsolete within months.

So I stopped writing about new stuff.

Instead, I decided to just teach React’s fundamentals. And the result? I started hearing from people how useful the articles were. My newsletter went from 600 to 6000 subscribers in under a year. I even got headhunted for my dream job.

And the best part? The articles I wrote 3 years ago are still useful today.

A new hope

Are you sick and tired of your tools changing underneath you?

Are you ready to put in the hard yards to learn React’s fundamentals, investing in a skill that lasts?

Then I have some good news for you!

exercise from new course

Later this week, I’ll be releasing a new interactive course on React’s fundamentals. It focuses on the essentials, only covering tools that have survived the test of time. And it’s full of exercises, ensuring that your new knowledge translates into experience.

I’ll be announcing it first to my newsletter with a big discount – if you haven’t joined already, then this is your last chance to become a member and get access to the early bird pricing!

I will send you useful articles, cheatsheets and code.

I won't send you useless inbox filler. No spam, ever.
Unsubscribe at any time.

See you soon!

CRUV: Structure React apps in 4 directories and 3 files

So you’re starting a React project. You know what you want to build, and quickly spin up a project with create-react-app. And then you’re confronted with the problem of where.

Where do your components go? Where should you put business logic? Where do higher order components fit in? And even if your structure feels right now, how do you know that it won’t feel wrong later?

If you’ve used other frameworks, you know that it doesn’t have to be this way. Rails gives you structure. So does Angular. What if React also had a system that told you exactly where files go? You could focus on building stuff instead of dicking around with folder structures.

In fact, there is a system that does just this. I’ve been using it for months now. It works great with create-react-app and any router you pick — even no router! And it’s named CRUV, after the 4 directories that you’ll use.

Containers, Routes, Utils, Views

CRUV is inspired by the directory structure from Ruby on Rails. It gives you four standard directories, for the things that you’ll definitely use. Then it lets you add other app-specific folders and subdirectories once you need them.

Creating a CRUV app is simple. All you do is generate an app with create-react-app, and then create 4 folders and 2 files. You can try it out by copying and pasting this into your terminal:

create-react-app myapp
cd myapp/src
mkdir containers routes utils views
touch config.js contexts.js 
mv App.* routes
sed -i '' -e 's/.\/App/.\/routes\/App/g' index.js

See the gist »

But what do the 4 directories and 2 files in this structure actually do? Let me demonstrate with examples from the app that runs my new Raw React course. Shameless plug: join my newsletter at the bottom of this page to keep in the loop when the course is released, and get a massive discount.

CRUV directory structure" width="150" height="150" class="alignnone size-thumbnail wp-image-1201"


This directory contains reusable container components. These components handle business logic, delegate style/markup to view components, and importantly, are used in more than one place.

Container components can also communicate with the server. In larger apps, they may delegate this to a Redux or Apollo store. But in smaller apps, they’ll usually just call the server directly.

Examples include:

  • An <ArticleContainer /> component that loads and wraps MDX documents.
  • A <CourseLessonContainer /> component that loads course access/progress from the server, and handles user requests to mark lessons as complete.
  • An <EditorContainer /> component that handles loading/saving of the students’s answers for exercises.

But what if you have something that looks like a container, but is only used once? Then it probably goes in /routes.


Routes are general purpose components that are only used once. They can handle both business logic and presentation internally, or they can delegate it to containers or presentation components.

Routes often correspond to individual URLs, and that’s where they get their name. But routes can also be independent of URL.

Examples include:

  • An <App /> component that wraps everything else, renders the app header, and decides what to render based on the current URL.
  • A <LandingPage /> component that contains your landing page’s content.
  • A <LoginPage /> component that shows a login form, and handles user input on that form.

So what router should your routes use? Whichever router you’d like, or even none at all! Because even if your app runs from a single URL, you’ll still need an <App> component. Maybe you’ll have other one-off components too.


This is the place to put files that get copied and pasted between many different projects. Things like vanilla JavaScript functions and classes, higher order components, and other utilities.

Some examples include:

  • A formatDate() function that converts JavaScript Date objects into strings.
  • A <Dimensions> component that uses a render prop to make the width and height of its children available.


Put components that render markup and styles here, along with components that receive and display user input. Dan Abramov calls them presentational components. I call them “views”, because it’s faster to type within import statements..

Some examples:

  • Styled <Button> components.
  • A <CourseCard> component that creates a link to a given page, and looks like a “card”.
  • A <Grid> component that is used within route components and other views to handle layout.

I tend to start by creating one .js, .css and .test.js file per component, and putting them directly in the /views directory. So for example, /views/Button.css, /views/Button.js, and /views/Button.test.js. But this isn’t a hard and fast rule; you can also export multiple components from a single file. For example, an Indicators.js file may export both <Spinner /> and <LoadingBar />.


Apps often have configuration that differs depending on the environment. For example, an API_KEY environment variable that differs between development, staging and production. While you can access this kind of configuration directly from process.env, I prefer to export it from a top-level config.js file. For example:

export default {
  server: process.env.REACT_APP_SERVER || 'http://localhost:3000',
  publicURL: process.env.PUBLIC_URL,
  stripeKey: process.env.REACT_APP_STRIPE_KEY,


To use React’s Context API, you’ll frequently need to import <Context.Consumer /> components, which often don’t fit in any of the other categories. I like to keep these components in a single top-level file, making them easy to access, and also discouraging over-use of context. Here’s an example:

import * as React from 'react'

// Current route and methods for interacting with browser history
export const NavContext = React.createContext(undefined)

// Data received from server
export const StoreContext = React.createContext(undefined)

// UI context, including whether the subtree is disabled, is a form, etc.
export const UIContext = React.createContext(undefined)


This is your application’s entry point, as created by create-react-app! Simple, huh?

As your project grows…

As your project grows, your views and routes folders can start to feel a little full. In this case, you might want to add subdirectories for each component, with an extra index.js file that re-exports the components. This let’s you keep the same filenames as before, without having to change any import statements.

For example, a /views/Button/index.js file might look like this:

export * from './Button.js'

You may also find yourself adding subdirectories that group related components. For example, I have a /views/editor subdirectory that groups together all the components involved in my course’s live editor.

Finally, in addition to the standard four CRUV directories, you may also find other useful directories. For example, my app has a /types directory, because it’s written in TypeScript. But I didn’t start with this directory. I only added it once my /utils directory got a little heavy with type definitions.

The reason that the CRUV structure works is that it’s just a starting point. When you’re just starting out, it gives you a simple structure to work with so that you can concentrate on writing actual code. And once your folders get full, all you need to do is find a few similar files, and move them into a new directory. It’s easier to categories files that already exist than to predict the future.

But where do my reducers go?

You may noticed that I haven’t added a directory for Redux reducers. And that brings me to this article by one of the creators of Redux: You Might Not Need Redux. Yes, you read that correctly: one of the creators of Redux is asking you to reconsider using Redux.

The reason that there are no /reducers or /actions directories in the CRUV structure is that Redux is optional. In fact, I write apps without Redux all the time!

But what if you do use Redux? Or MobX? Or Govern? In that case, my recommendation is that you add a /store directory, and put all your store related code in there. Stores hold global state that isn’t tied to a specific component, so they generally shouldn’t be very large.

And if you do have state that needs to be tied to a specific component? Use setState()! That’s what it is there for; component state is a simple, powerful, and underappreciated tool. Raw React can get you a long way.

Where is CRUV used?

If you’ve worked with some React apps before, CRUV may feel familiar. While the names are probably a little different, this pattern is something that often evolves by itself — especially when building on the Presentational and Container Components pattern.

In my case, CRUV is the structure that evolved from an app that I’m building to teach Raw React. I’ll be going into more details on how I built the platform behind the course soon. To get the details, or to be the first to hear about the Raw React course (and get a massive discount), join my newsletter below! I’ll even email you five free PDF cheatsheets to sweeten the deal.

I will send you useful articles, cheatsheets and code.

I won't send you useless inbox filler. No spam, ever.
Unsubscribe at any time.

One more thing – I love hearing your questions, offers and opinions. If you have something to say, leave a comment or send me an e-mail at james@jamesknelson.com. I’m looking forward to hearing from you!