What is React: A Visual Introduction For Beginners

Linton Ye

Last Updated: 2021-02-02

简体中文日本語

Introduction

React is a JavaScript library for building user interfaces.

This is the official definition of React. But what if you are not familiar with JavaScript? What if you are not a developer? Would you still be able to make sense of (and learn) React?

My answer is a firm YES. That's why I wrote this article: what is React exactly? What is React.js (or ReactJS)? What is React used for? Why is React so popular? What problems does it solve?

This article is an introduction to React for beginners. It's the first post you'd want to read before learning the specifics of React. I'll explain the core ideas of React in plain English (and doodles 🌴). No JavaScript experience? No problem! As long as you have some basic HTML knowledge (e.g. the format of an HTML tag), you should be able to enjoy this article.

This is a bird's-eye view 🦅 but I'll also equip you with a pair of binoculars . You'll not only see the big picture of what makes React special, but also zoom in to get some hands-on experience of writing an actual React component. And yes, no JS knowledge required!

Remember: You don't need to be an experienced developer to understand the core ideas of React!

Ready to start the journey?

A few things about the Web

Let's get started with something you might have heard many times, the DOM.

What is the DOM?

When you enter the address of your favorite website into a browser, your computer starts a conversation with another computer far away, commonly referred to as server. Typically your computer makes a request for some information and the server responds:

Your computer: Yo, what's good about this random site learnreact.design?

The server: Hang on, let me grab something for you. Beep. Boop.

The main part of the server's response usually includes three items: HTML, CSS and JavaScript.

HTML lists the content of a web page and describes its structure. How many headings and paragraphs are there? What images should a user see? Are this button and that textbox contained in the same box?

Using this information, the browser creates something called... the DOM!

Wait a second, the DOM is a ... tree? Yup, a tree! Oddly enough, a lot of things in our computer look like a tree. Let's give our tree friend a nickname... hmm what about Domo?

Domo works as a model at the prestigious art studio "Web Browser". His job is to pose in front of the artist who paints a portrait (or perhaps millions of portraits).

In real life, DOM stands for Document Object Model. It's indeed a model -- a model of the document (aka the web page). It strikes a pose. The browser paints a portrait. The portraits are what we see on a web page: the textboxes, the paragraphs, the images and so on. A developer's job is like that of a director who tells Domo what to wear and what pose to strike. This determines what those portraits look like in the end.

To check out what the DOM looks like, if you are using a desktop browser, right-click on this very page and choose "Inspect". Can you make sense of what's in the Elements tab?

The DOM API

We often want a web page to be dynamic and interactive -- that means its content changes from time to time: adding or removing text here and there, showing a modal, or updating a chart based on some new data coming from the server.

Remember, in order to change what's on a web page, we need to update the DOM. The artist isn't able to paint new portraits until Domo changes to a new pose.

How would we get Domo to change to a new pose?

We just talk to him. He listens. Interestingly, Domo's ears happen to have a name: DOM API.

To manipulate the DOM, a developer would write code in JavaScript which talks to the DOM API, and in turn, updates the content of the web page.

The increasing complexity

Directly talking to Domo has been the standard approach of web development for years, especially when the web content was mostly static. A developer would sprinkle some interactivity on top of the static pages by writing small amount of JavaScript code.

However, with the emergence of SPAs (Single Page Application) such as Gmail and Google Maps, people started to expect a lot more. Instead of mostly static web pages, they want web apps that are interactive, fast and responsive.

The code required to build web apps becomes increasingly large and complex. It often requires the collaboration of many team members.

The traditional approach stopped working. It becomes chaotic and inefficient to always directly talk to Domo.

The Core Ideas of React

Let me introduce you to the superhero, React:

With React, developers no longer directly talk to Domo. React acts as an agent between a developer and Domo. He smoothens the communication and streamlines the process of portrait creation.

React is also referred to as "ReactJS" or "React.js", but "React" is the official name.

React is made up of JavaScript code. It's built in a way that we no longer need to directly work with the DOM API in most cases. Instead, we write simpler code while React handles the conversation with the DOM under the hood.

React has a few superpowers to tackle the ever-growing complexity of web development:

• Components
• Declarative UI
• Reactive DOM updates

If these terms sound scary to you, don't be intimidated! As promised, I'll use plain English and doodles to help you make sense of them. Trust me, it's not that hard!

Just read on!

Components

Components are the flagship feature of React. The core idea is based on a simple strategy: divide-and-conquer. If it's difficult to grok a problem all at once, we break it into smaller problems, solve them one at a time and then combine the results.

Building an app in React is almost all about working with components: breaking the app into components, finding the best components for the job, fitting one with another, creating new components from existing ones etc.

Nowadays, design tools such as Framer and Figma have components too (and symbols in Sketch). They are a lot like React components, except that the latter are more flexible and powerful. In fact, the inspiration of components in design tools came directly from components in software engineering. Once a component is created, we can create multiple instances of it. We can use it to construct other components. If we change a component, everything that includes this component will be updated automatically.

Components in React have two important properties:

1. Components are composable. They are made for reuse. We can make a new component with other components.
2. Components are independent of each other. If we change the code in one place, other parts don't break.

If this sounds abstract to you, don't worry! I'll show you some examples and explain these properties in details soon.

Declarative UI

Imperative vs. declarative

When directly working with the DOM API, we'd have to specify what element to change at the right time, in the right order. This is equivalent to describing to Domo how to position his head, arms and legs step by step, for each and every portrait.

Heck, this sounds tedious and error-prone! Why can't we just tell Domo what we want instead of how to pose? In fact, this is exactly how to build a UI in React. A developer draws a quick sketch of what he or she wants. React explains it to Domo how to pose.

Because the apps we build are dynamic, we often want Domo to change poses fairly quickly. We draw many sketches and hand them to React in a big pile. React stacks these sketches together and flips them like a flipbook. A dynamic UI comes live!

In tech terms, if the code defines how we want it to be done, it's imperative; if it defines what we want, it's declarative. The traditional way of directly working with the DOM API is imperative, and the React way is declarative.

Imperative programming emerged from the day when the computers were primitive. People had to instruct them in detail: where to store the numbers, how to multiply etc. But this eventually got unmanageable, people wrote smart software that convert definition of problems into detailed instructions. Declarative programming was born.

Virtual DOM

Besides making the life of a developer easier, declarative programming in React also offers opportunities for performance optimization.

When React has all the sketches beforehand, he can sort through them, remove any duplication and make sure that Domo and the artist do as little work as possible.

These sketches are called Virtual DOM. Virtual DOM is much faster to manipulate than the DOM. Developers work with Virtual DOM most of the time instead of directly managing the DOM. React handles the dirty work of managing the slow DOM.

Reactive DOM updates

Even cooler, imagine if we can leave placeholders in our sketches to represent different variations of a same pose. This way, when somebody asks for portraits of Domo wearing a different hat, we don't have to talk to React again. We can just sit back and let React change it for us.

The hat here is the data that determine the dynamic content of the UI. We just need to associate UI elements with their corresponding data. When the data change, React automatically updates the related DOM elements for us. It appears that the DOM "reacts" to any changes to the underlying data. No need to track the data. No need to worry about when to update the DOM. It just gets updated automatically (by React).

This trick is how React got its name. The UI built with React is reactive. The idea of reactive UI greatly simplifies UI development.

Write your first React component

Now let's review what we have learned so far and get our hands dirty on a few real React components. To make it easy for you to understand, I left out some details in the code (notedly JavaScript). The goal is to let the core ideas shine through without being bogged down by JS syntax. If you are comfortable with reading JavaScript code, feel free to check out the real source code.

Alright. Let's say we want to help Domo build an online hat store 🧢 .

Components are composable

We can break the UI into a few parts:

• Header: the header on the top
• Main: the main content area
• Footer: the footer on the bottom

This decomposition can be written in code like so:

// DomoHatShopHome
<div>
  <Header />
  <Main />
  <Footer />
</div>

This looks like HTML, right? Except for those tags that start with capital letters: <Header>, <Content> and <Footer>. They are not standard HTML tags. They are custom tags.

What are these custom tags actually? How would we tell React that the Header consists of a header tag, a bunch of list items and a search bar?

We write the Header component!

// Header
<header>
  <nav>
    <ul>
      <li>Home</li>
      <li>
        <SearchBar />
      </li>
      <li>Account</li>
      <li>Return &amp; Orders</li>
      <li>
        <ShoppingCart />
      </li>
    </ul>
  </nav>
</header>

Now in this Header component, it includes two custom tags <SearchBar> and <ShoppingCart>. What's in there?

// SearchBar
<form>
  <input type="string" />
  <button>Search</button>
</form>

// ShoppingCart
<div>
  <FiShoppingCart size={20} />
  <div>
    2
  </div>
</div>

Remember the first important property of React components? They are composable. This means that we can use components to build other components -- exactly what we have just done.

Now here's an exercise for you (open this page in a desktop browser for the best experience):

✍️ Let's say we want to add the SearchBar into the Footer as well. What would you do? Edit the code below:

<footer> <div>© 2021 Domo's Hat Shop</div> </footer>

<footer>
  <div>© 2021 Domo's Hat Shop</div>
</footer>

Hints:

• Make sure to put tags inside <footer>
• Scroll up to check the code of Header
• Try adding some other tags

Did you get two search bars? You get the idea!

Components are made for reuse

"Composable" means being able to create a component using other components as its building blocks. This sounds very similar to how nature works, except for one important difference: in React, once we use a component in another component, it still "attaches" to the original component. When the original changes, all instances update along with it.

✍️ Change the text on the button in the code of SearchBar below:

<form> <input type="string" /> <button>Search</button> </form>

<form>
  <input type="string" />
  <button>Search</button>
</form>

What did you see? The SearchBar on both Header and Footer updates. Right? This works very similarly to components in design tools such as Framer and Figma.

React components are made for reuse. Once a component is defined, we can use it as a custom tag in other components, as many times as we want. If we change the component, all components that include it will change accordingly.

Components are independent

Remember? React components are also independent. This means if we change one component, other components (that don't include it) still behave the same way as before.

When we change the SearchBar component above, only the Header and Footer change. This may sound very straightforward (perhaps too obvious). But it's a fundamental idea in software engineering and it goes a long way to keep software development manageable.

Declarative & Reactive

Now let's move on to the other two superpowers of React: declarative UI and reactive DOM updates.

Have you choosen a hat for Domo yet? If not, just click one of the hats in the table. The hat on Domo's head will change, right?

In this UI, clicking an item in the table would update the data "selected hat". Because we have associated DomoWithHat with "selected hat", the hat on Domo would automatically change. Remember? Reactive DOM updates.

Here's the code for the component DomoWithHat.

// DomoWithHat
<div>
  <Hat type={hat} />
  <Domo />
</div>

In the code above, we just need to define what we want (Domo and a hat in a div), and "wire up" the data ("type = {hat}"). When the data item hat changes (user selects a hat), the UI updates automatically. We don't need to worry about when and how to update the DOM. We don't even need to keep track of the data. What we need is just to draw a quick sketch, i.e. the code above. Here we go, the other two superpowers of React: Declarative UI, plus Reactive DOM updates.

• Home
• Search
• Account
• 2

Cap

$50

A covering for the head usually having a shaped crown and brim.

Add To Cart

© 2021 Domo's Hat Shop

Conclusion

Congrats! You've finished the first important lesson of React! It's about the big picture: why do we need React at all? Here are the three core ideas that make React powerful: Components, Declarative UI and Reactive DOM updates.

In fact, I bet even some experienced React developers (for example, myself!) are not super clear about these concepts. When I wrote the first version of this article a few years ago, I put focus on the wrong things. Hopefully this revision is more accurate!

Here's a list of terms covered in the post:

• The DOM (Document Object Model)
• The DOM API
• React components
• Components are composable and independent
• Imperative vs. declarative programming
• Virtual DOM
• Reactive DOM updates

I hope you find this article useful!

One of my 2021 goals is to write more posts that are useful, interactive and entertaining. Want to receive early previews of future posts? Sign up below. No spam, unsubscribe anytime.

Subscribe