A gentle introduction to React, but visualized.

jQuery was the most popular way to build for the web. It embraced websites for what they truly were, a tree of DOM nodes.

With jQuery, the state of your application lived inside the DOM. Whenever you wanted to update that state, you’d imperatively traverse the DOM, find the node you wanted to update, then update it. Needed to respond to an event? Again, traverse the DOM, find the node, then add an event listener to it.

Backbone.js invented the Model-View-Controller pattern. That’s a joke, but it was the first popular JavaScript framework that embraced the traditional software design pattern and brought it to building for the web.

In just 2,000 lines of code, Backbone allowed you to decouple your application’s state from the DOM. Instead of living in the DOM, Backbone state lived inside of its “Models”. From there, whenever a Model changed, all the Views that cared about that Model’s state would re-render.

AngularJS, for good and for bad, embraced two-way data binding. It was Angular’s way of updating the view whenever the model changed, and updating the model, whenever the view changed.

In theory, this was nice because you didn’t have to worry about doing manual DOM manipulation yourself. In practice, well, implicit state changes usually led to code that is both hard to follow and hard to debug. It also led to performance issues since Angular.js had to constantly scan your app looking for state changes.

One of the core innovations of React was that they made the View a function of your application’s State. Often represented as v = f(s).

All you have to do is worry about how the state in your application changes, and React handles the rest.

But making your view a function of your state was really only half the picture. The real innovation happened when you encapsulated this idea into a proper component based API.

By doing so, the same intuition you have about creating and composing together functions can directly apply to creating and composing components. However, instead of composing functions together to get some value, you can compose components together to get some UI.

To truly embrace a component based API, React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. This is where most of the initial hate for React came from and it had to do with React’s interpretation of the “Separation of Concerns” principle.

Historically the way you adhered to this on the web was to have your HTML separate from your CSS which was separate from your JavaScript.

In React’s opinion, anything that had to do with rendering the View - whether that be state, UI, and in some cases, even styling, was part of its concern.

This approach allows you to collocate concerns, regardless of technologies.

To accomplish this, React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. Well, describing UI is already a solved problem - that’s what HTML is really good at. But you can’t mix HTML and JavaScript, right?

Why not? This thinking led to the creation of JSX - a wonderful lovechild of HTML and JavaScript that allows you to write HTML-ish looking syntax directly inside of JavaScript.

Props are to components what arguments are to functions.

The same intuition you have about functions and passing arguments to functions can be directly applied to components and passing props to components.

Along with passing data to components as attributes, you can also pass data between the opening and closing brackets of an element. When you do this, that data is accessible in the component via props.children.

You can think of a component with a children prop as having a placeholder that can be filled by its parent component.

Because of this, it’s common to utilize children to create Layout type components that encapsulate styling and logic, but leave the content to the consumer of the component.

Because React components are just functions, normal variables won’t persist across different invocations of those functions (which React calls renders). To add state that persists across different renders, you can use React’s useState hook.

Whenever React sees that the state of a component has changed, it will trigger a re-render and update the UI.

The biggest tradeoff with having individual components manage their own state is often you’ll have state that multiple components need to access. Learning to handle these scenarios is one of the most important aspects of properly managing state in React.

Here’s the rule of thumb – whenever you have state that multiple component depend on, you’ll want to lift that state up to the nearest parent component and then pass it down via props.

The only gotcha is how you update that state. Often time when lifting state up, you decouple where the state lives from the event handlers that update that state.

To solve this, you’ll create an updater function in the parent component where the state lives and, via props, invoke that function from the child component(s) where the event handler(s) live.

Here’s what this would look like in a simple Todo app. Instead of having each individual Todo component manage its own state, we’d lift that state up to a parent TodoList component, then pass down a function which gives each individual Todo component the ability to update itself.

But all this talk of state brings up a good question, how exactly does React update its state?

When React renders a component, two things happen.

First, React creates a snapshot of your component which captures everything React needs to update the view at that particular moment in time. Props, state, event handlers, and a description of the UI (based on those props and state) are all captured in this snapshot.

From there, React takes that description of the UI and uses it to update the View.

Now that you know how React renders, the natural next question is when does React render? The answer is surprisingly simple. React will only re-render when the state of a component changes.

Here’s how it works. When an event handler is invoked, that event handler has access to the props and state as they were in the moment in time when the snapshot was created.

From there, if the event handler contains an invocation of useState’s updater function and React sees that the new state is different than the state in the snapshot, React will trigger a re-render of the component – creating a new snapshot and updating the view.

We can see this process in action with this very simple application.

Whenever our button is clicked, our handleClick event handler will run. The state (index) inside of handleClick will be the same as the state in the most recent snapshot. From there, React sees there’s a call to setIndex and that the value passed to it is different than the state in the snapshot – triggering a re-render.

That’s a lot of words. Here’s what it would look like if we visualized it.

One aspect of rendering that may not be quite so intuitive is that whenever state changes, React will re-render the component that owns that state and all of its child components – regardless of whether or not those child components accept any props.

I get this may seem like a strange default. Shouldn’t React only re-render child components if their props change? Anything else seems like a waste.

First, React is very good at rendering.

Second, the assumption that React should only re-render child components if their props change works in a world where React components are always pure functions and props are the only thing these components need to render. The problem, as anyone who has built a real world React app knows, is that isn’t always the case.

And third, if you do have an expensive component and you want that component to opt out of this default behavior and only re-render when its props change, you can use React’s React.memo higher-order component.

We’re still working on the visuals for this section, but here’s a set of rules we follow for managing side effects in React.

useRef creates a value that is preserved across renders, but won’t trigger a re-render when it changes.

Refs are handy for keeping track of non-visual state like timer ids or keeping track of DOM nodes.

Take this scenario, for example. What you’ve been taught is that whenever you have state that multiple component depend on, you’ll want to lift that state up to the nearest parent component and then pass it down via props.

This works… most of the time. But what happens if instead of your app looking like that, it looked like this?

It’s rare, but there are times when passing props through intermediate components can become overly redundant at best, or completely unmanageable at worst.

Because this is such an obvious limitation of a component based architecture, React comes with a built-in API to solve it called Context. You can think of Context as giving you the ability to teleport data anywhere in your component tree, without needing to pass props.

That’s literally all it does – it’s the Wormhole, Einstein-Rosen bridge, TARDIS, Stargate, Portkey, DeLorean of React.