Learn Raw React — no JSX, no Flux, no ES6, no Webpack…

Disclaimer: I love JSX, Flux, ES6 and Webpack. I’ll discuss these tools more in another series.


Update August 2018: A newer, more complete introduction to React’s fundamentals is available at my course “React (without the buzzwords)”. It uses the latest version of React, and covers many topics that “Learn Raw React” is missing, including component state, asynchronous data storage, JSX, structure best practices, and more.

“React (without the buzzwords)” 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.

React (without the buzzwords) is exclusive to Frontend Armory Pro members. But you can try these 8 free lessons just by clicking one of the links – no signup required:

Of course, the original “Learn Raw React” guide is still useful today! Here it is:


So you’ve heard all the fuss about React.js – apparently it is the best thing since XMLHttpRequest. But you’ve spent a couple hours investigating, only to find so many buzzwords that it just feels overwhelming. JSX and flux and ES6 and webpack and react-router and all I want is somebody to just tell me how to use React already!

Luckily for you, that’s exactly what this series will do! Don’t believe me? That’s OK – you will after you’ve built your first React app in about 2 minutes time. Without downloading anything. Just by following this exercise:

Continue reading

Structuring React Applications: Higher-Order Components

Do you ever find yourself frustrated with all the boilerplate and repetitive code in React components? Frequent use of patterns make components long-winded, hard to reason about, and difficult to maintain. And with mixins no longer supported in ES6 components, there is no longer any obvious solution!

This became a problem while writing Memamug. Without mixins, the code gradually evolved a bunch of annoying patterns, including:

  • passing unknown props through to child nodes
  • writing out long CSS class names
  • merging internal callbacks with those specified on props

But there is a solution: Higher-Order Components. And seeing how helpful I’ve found them, it is only natural that I want to spread the word!

Continue reading

A system for structuring your React application’s styles

Read the full specification at the GitHub repository.

Have you ever experienced the frustration involved in adding styles to your new component, just to find that some other style, somewhere in the same project, is conflicting with yours? Without structure, stylesheets become confusing and unmaintainable:

  • Styles with global scope end up biting you in the ass months down the track
  • Deeply nested selectors confuse you as to what it is they’re actually supposed to do
  • Just finding the various rules across various files which combine to make one component’s style can be a pain in itself

Styling components doesn’t have to be a nightmare

Things have certainly gotten better in recent years. For example, compile-to-CSS languages like LESS and SASS help facilitate separation of concerns, and React itself does a lot to encourage good structure.

However, better tools present a new problem – we can end up spending more time deciding where to put things than actually making them. And what if you make the wrong decisions? While React, LESS and SASS certainly encourage good structure, they definitely don’t enforce it.

While we’ve come a long way, what we still need is a specification – a set of decisions which do the hard design work for us. And as it happens, the Pacomo project does exactly that!

Continue reading

Building a property passthrough Higher-Order Component for React

Just want the component? Find it at GitHub

Possibly the most frequently re-implemented code across any React component is that used to pass properties through to child components. This stems from the fact that you generally need some sort of input to make the component useful, while you don’t want these component-specific properties polluting the props on your children.

This would be all well and good if it wasn’t for the fact it is so easy to avoid re-implementing this over and over again! I mean, you’re already defining the properties you consume in propTypes – why repeat yourself?

In fact, by passing your React classes through a Higher-Order Component, you can easily add a method which returns all props except the ones specified in propTypes – making writing components that-much-easier (and consistent). I’ll show you how to do it in a moment, but first lets have a look at:

Continue reading

Introducing Memamug, a small open-source app made with React and Rails-api

View the source or see it live

One of the biggest pains I hear from new and old developers alike is that once they’ve learned the basics of a new technology, they struggle to apply them to an actual project.

Actually, this isn’t just a problem I’ve heard about – I’ve experienced it myself. In particular, learning React has been as much about figuring out what to do with it as learning the API itself. So to cut a long story short – I’ve built a single-page app with React and Rails-api. And I’d like to share it with you. And it’s not a todo list!

Memamug is a tiny app to help you remember people you meet. However, putting it together wasn’t a tiny job. It demonstrates a number of patterns and techniques which apply to larger projects, including how to:

Continue reading

Announcing Maxim

tl;dr – Try Maxim by cloning react-black-triangle, it’ll only take two minutes!

One recurring theme lately is that a number of people have found themselves quite attached to flux‘s core idea of unidirectional data flow, while at the same time Facebook’s implementation of it hasn’t really won people’s hearts (and neither have many of the other same-thing-but-not-the-same-thing implementations).

I too have found myself in this position. I’ve been craving something which like flux is easy-to-reason about, but like rails is elegant and has enough well-defined conventions to prevent me from spending a stupid amount of time stuck in decision paralysis.

My first attempt at fixing this was producing a simple react starter kit with a custom Flux implementation, react-black-triangle. However, one thing lead to another, and the result was Maxim.

Continue reading

Rendering React components to the document body

One of React’s best features is the simplicity of it’s API. A component can be as simple as a render method which returns the component’s structure – just write a simple function, and you have a useful, re-usable piece of code. There are times where this can be limiting, however. In particular, the fact that this API gives a component no control over where in the DOM it will be mounted makes popup components (like modals or menus) difficult to implement. Problems arise when a parent element has overflow set to 'hidden', for example, causing something a little like this:

Continue reading