React.js (or just React, as it’s also called and as it’ll be referred to for the majority of this book) is one of the most popular frontend JavaScript libraries – maybe even the most popular one, according to a 2023 Stack Overflow developer survey. It is currently used by over 5% of the top 1,000 websites and compared to other popular frontend JavaScript libraries and frameworks like Angular, React is leading by a huge margin, when looking at key metrics like weekly package downloads via npm, which is a tool commonly used for downloading and managing JavaScript packages.

Though it is certainly possible to write good React code without fully understanding how React works and why you’re using it, you’ll likely be able to learn advanced concepts quicker and avoid errors when trying to understand the tools you’re working with as well as the reasons for picking a certain tool in the first place.

Therefore, before considering anything about its core concepts and ideas or reviewing example code, you first need to understand what React actually is and why it exists. This will help you understand how React works internally and why it offers the features it does.

If you already know why you’re using React, why solutions like React, in general, are being used instead of vanilla JavaScript (i.e., JavaScript without any frameworks or libraries, more on this in the next section), and what the idea behind React and its syntax is, you may, of course, skip this section and jump ahead to the more practice-oriented chapters later in this book.

But if you only think that you know it and are not 100% certain, you should definitely read this chapter first.

React is a JavaScript library, and if you take a look at the official web page (the official React website and documentation are available at this link: https://react.dev/), you learn that the creators call it “The library for web and native user interfaces.”

But what does this mean?

First, it’s important to understand that React is a JavaScript library. As a reader of this book, you know what JavaScript is and why you use JavaScript in the browser. JavaScript allows you to add interactivity to your website since, with JavaScript, you can react to user events and manipulate the page after it is loaded. This is extremely valuable as it allows you to build highly interactive web user interfaces (UIs).

But what is a “library” and how does React help with building UIs?

While you can have philosophical discussions about what a library is (and how it differs from a framework), the pragmatic definition of a library is that it’s a collection of functionalities that you can use in your code to achieve results that would normally require more code and work from your side. Libraries can help you write more concise and possibly also less error-prone code and enable you to implement certain features more quickly.

React is such a library – one that focuses on providing functionalities that help you create interactive and reactive UIs. Indeed, React deals with more than web interfaces (i.e., websites loaded in browsers). You can also build native apps for mobile devices with React and React Native, which is another library that utilizes React under the hood. The React concepts covered in this book still apply, no matter which target platform is chosen. But examples will focus on React for web browsers. No matter which platform you’re targeting though, creating interactive UIs with just JavaScript can quickly become very complex and overwhelming.

Vanilla JavaScript is a term commonly used in web development to refer to JavaScript without any frameworks or libraries. That means you write all the JavaScript on your own, without falling back to any libraries or frameworks that would provide extra utility functionalities. When working with vanilla JavaScript, you especially don’t use major frontend frameworks or libraries like React or Angular.

Using vanilla JavaScript generally has the advantage that visitors of a website have to download less JavaScript code (as major frameworks and libraries typically are quite sizeable and can quickly add 50+ KB of extra JavaScript code that has to be downloaded).

The downside of relying on vanilla JavaScript is that you, as the developer, must implement all functionalities from the ground up on your own. This can be error prone and highly time consuming. Therefore, especially more complex UIs and websites can quickly become very hard to manage with vanilla JavaScript.

React simplifies the creation and management of such UIs by moving from an imperative to a declarative approach. Though this is a nice sentence, it can be hard to grasp if you haven’t worked with React or similar frameworks before. To understand it, the idea behind “imperative versus declarative approaches,” and why you might want to use React instead of just vanilla JavaScript, it’s helpful to take a step back and evaluate how vanilla JavaScript works.

Let’s look at a short code snippet that shows how you could handle the following UI actions with vanilla JavaScript:

1. Add an event listener to a button to listen for click events.
2. Replace the text of a paragraph with new text once a click on the button occurs.

   const buttonElement = document.querySelector('button');
   const paragraphElement = document.querySelector('p');
   function updateTextHandler() {
     paragraphElement.textContent = 'Text was changed!';
   }
   buttonElement.addEventListener('click', updateTextHandler);
   

This example is deliberately kept simple, so it’s probably not looking too bad or overwhelming. It’s just a basic example to show how code is generally written with vanilla JavaScript (a more complex example will be discussed later). But even though this example is straightforward to digest, working with vanilla JavaScript will quickly reach its limits for feature-rich UIs and the code to handle various user interactions accordingly also becomes more complex. Code can quickly grow significantly, so maintaining it can become a challenge.

In the preceding example, code is written with vanilla JavaScript and, as a consequence, imperatively. This means that you write instruction after instruction, and you describe every step that needs to be taken in detail.

The code shown previously could be translated into these more human-readable instructions:

1. Look for an HTML element of the button type to obtain a reference to the first button on the page.
2. Create a constant (i.e., a data container) named buttonElement that holds that button reference.
3. Repeat Step 1 but get a reference to the first element that is of type of p.
4. Store the paragraph element reference in a constant named paragraphElement.
5. Add an event listener to the buttonElement that listens for click events and triggers the updateTextHandler function whenever such a click event occurs.
6. Inside the updateTextHandler function, use the paragraphElement to set its textContent to "Text was changed!".

Do you see how every step that needs to be taken is clearly defined and written out in the code?

This shouldn’t be too surprising because that is how most programming languages work: you define a series of steps that must be executed in order. It’s an approach that makes a lot of sense because the order of code execution shouldn’t be random or unpredictable.

However, when working with UIs, this imperative approach is not ideal. Indeed, it can quickly become cumbersome because, as a developer, you have to add a lot of instructions that, despite adding little value, cannot simply be omitted. You need to write all the Document Object Model (DOM) instructions that allow your code to interact with elements, add elements, manipulate elements, and so on.

Your core business logic (e.g., deriving and defining the actual text that should be set after a click) therefore often makes up only a small chunk of the overall code. When controlling and manipulating web UIs with JavaScript, a huge chunk (often the majority) of your code is frequently made up of DOM instructions, event listeners, HTML element operations, and UI state management.

As a result, you end up describing all the steps that are required to interact with the UI technically and all the steps that are required to derive the output data (i.e., the desired final state of the UI).

The button-clicking example is not a complex example in general, but the vanilla JavaScript code for implementing such a scenario can be overwhelming. You end up with lots of DOM selection, insertion, and manipulation operations, as well as multiple lines of code that do nothing but manage event listeners. Also, keeping the DOM updated, without introducing bugs or errors, can be a nightmare since you must ensure that you update the right DOM element with the right value at the right time. Here, you will find a screenshot of some example code for the described use case.

If you take a look at the JavaScript code in the screenshot (or in the linked repository), you will probably be able to imagine how a more complex UI is likely to look.

Figure 1.1: An example JavaScript code file that contains over 100 lines of code for a fairly trivial UI

This example JavaScript file already contains roughly 110 lines of code. Even after minifying (“minifying” means that code is shortened automatically, e.g., by replacing long variable names with shorter ones and removing redundant whitespace; in this case, via https://www.toptal.com/developers/javascript-minifier) it and splitting the code across multiple lines thereafter (to count the raw lines of code), it still has around 80 lines of code. That’s a full 80 lines of code for a simple UI with only basic functionality. The actual business logic (i.e., input validation, determining whether and when overlays should be shown, and defining the output text) only makes up a small fraction of the overall code base – around 20 to 30 lines of code, in this case (around 20 after minifying).

That’s roughly 75% of the code spent on pure DOM interaction, DOM state management, and similar boilerplate tasks.

As you can see by these examples and numbers, controlling all the UI elements and their different states (e.g., whether an info box is visible or not) is a challenging task, and trying to create such interfaces with just JavaScript often leads to complex code that might even contain errors.

That’s why the imperative approach, wherein you must define and write down every single step, has its limits in situations like this. This is the reason why React provides utility functionalities that allow you to write code differently: with a declarative approach.

Coming back to the first, simple code snippet from earlier, here’s that same code snippet, this time using React:

import { useState } from 'react';
function App() {
  const [outputText, setOutputText] = useState('Initial text');
  function updateTextHandler() {
    setOutputText('Text was changed!');
  }
  return (
    <>
      <button onClick={updateTextHandler}>
        Click to change text
      </button>
      <p>{outputText}</p>
    </>
  );
}

This snippet performs the same operations as the first did with just vanilla JavaScript:

1. Add an event listener to a button to listen for click events (now with some React-specific syntax: onClick={…}).
2. Replace the text of a paragraph with a new text once the click on the button occurs.

Nonetheless, this code looks totally different – like a mixture of JavaScript and HTML. Indeed, React uses a syntax extension called JSX (i.e., JavaScript extended to include XML-like syntax). For the moment, it’s enough to understand that this JSX code will work because of a pre-processing (or transpilation) step that’s part of the build workflow of every React project.

Pre-processing means that certain tools, which are part of React projects, analyze and transform the code before it is deployed. This allows for development-only syntax like JSX, which would not work in the browser and is for that reason transformed to regular JavaScript before deployment. (You’ll get a thorough introduction to JSX in Chapter 2, Understanding React Components and JSX.)

In addition, the snippet shown previously contains a React-specific feature: State. state will be discussed in greater detail later in the book (Chapter 4, Working with Events and State, will focus on handling events and states with React). For the moment, you can think of this state as a variable that, when changed, will trigger React to update the UI in the browser.

What you see in the preceding example is the “declarative approach” used by React: you write your JavaScript logic (e.g., functions that should eventually be executed), and you combine that logic with the HTML code that should trigger it or that is affected by it. You don’t write the instructions for selecting certain DOM elements or changing the text content of some DOM elements. Instead, with React and JSX, you focus on your JavaScript business logic and define the desired HTML output that should eventually be reached. This output can, and typically will, contain dynamic values that are derived inside of your main JavaScript code.

In the preceding example, outputText is some state managed by React. In the code, the updateTextHandler function is triggered upon a click, and the outputText state value is set to a new string value ('Text was changed!') with the help of the setOutputText function. The exact details of what’s going on here will be explored in Chapter 4.

The general idea, though, is that the state value is changed and, since it’s being referenced in the last paragraph (<p>{outputText}</p>), React outputs the current state value in that place in the actual DOM (and hence, on the actual web page). React will keep the paragraph updated, and therefore, whenever outputText changes, React will select this paragraph element again and update its textContent automatically.

This is the declarative approach in action. As a developer, you don’t need to worry about the technical details (for example, selecting the paragraph and updating its textContent). Instead, you will hand this work off to React. You will only need to focus on the desired end states where the goal simply is to output the current value of outputText in a specific place (i.e., in the second paragraph in this case) on the page. It’s React’s job to do the “behind the scenes” work of getting to that result.

It turns out that this code snippet isn’t shorter than the vanilla JavaScript one; indeed, it’s actually even a bit longer. But that’s only the case because this first snippet was deliberately kept simple and concise. In such cases, React actually adds a bit of overhead code. If that were your entire UI, using React indeed wouldn’t make too much sense. Again, this snippet was chosen because it allows us to see the differences at a glance. Things change if you take a look at the more complex vanilla JavaScript example from before and compare that to its React alternative.

Figure 1.2: The code snippet from before is now implemented via React

It’s still not short because all the JSX code (i.e., the HTML output) is included in the JavaScript file. If you ignore pretty much the entire right side of that screenshot (since HTML was not part of the vanilla JavaScript files either), the React code gets much more concise. However, most importantly, if you take a closer look at all the React code (also in the first, shorter snippet), you will notice that there are absolutely no operations that would select DOM elements, create or insert DOM elements, or edit DOM elements.

This is the core idea of React. You don’t write down all the individual steps and instructions; instead, you focus on the “big picture” and the desired end states of your page content. With React, you can merge your JavaScript and markup code without having to deal with the low-level instructions of interacting with the DOM like selecting elements via document.getElementById() or similar operations.

Using this declarative approach instead of the imperative approach with vanilla JavaScript allows you, the developer, to focus on your core business logic and the different states of your HTML code. You don’t need to define all the individual steps that have to be taken (like “adding an event listener,” “selecting a paragraph,” etc.), and this simplifies the development of complex UIs tremendously.

Looking at React code for the first time, it can look very unfamiliar and strange. It’s not what you’re used to from JavaScript. Still, it is JavaScript – just enhanced with this JSX feature and various React-specific functionalities (like state). It may be less confusing if you remember that you typically define your UI (i.e., your content and its structure) with HTML. You don’t write step-by-step instructions there either but rather create a nested tree structure with HTML tags. You express your content, the meaning of different elements, and the hierarchy of your UI by using different HTML elements and nesting HTML tags.

If you keep this in mind, the “traditional” (vanilla JavaScript) approach of manipulating the UI should seem rather odd. Why would you start defining low-level instructions like “insert a paragraph element below this button and set its text to <some text>” if you don’t do that in HTML at all? React, in the end, brings back that HTML syntax, which is far more convenient when it comes to defining content and structure. With React, you can write dynamic JavaScript code side by side with the UI code (i.e., the HTML code) that is affected by it or related to it.

How React Manipulates the DOM

As mentioned earlier, when writing React code, you typically write it as shown previously: you blend HTML with JavaScript code by using the JSX syntax extension.

It is worth pointing out that JSX code does not run like this in browsers. It instead needs to be pre-processed before deployment. The JSX code must be transformed into regular JavaScript code before being served to browsers. The next chapter will take a closer look at JSX and what it’s transformed into. For the moment, though, simply keep in mind that JSX code must be transformed.

Nonetheless, it is worth knowing that the code to which JSX will be transformed will also not contain any DOM instructions. Instead, the transformed code will execute various utility methods and functions that are built into React (in other words, those that are provided by the React package that need to be added to every React project). Internally, React creates a virtual DOM-like tree structure that reflects the current state of the UI. This book takes a closer look at this abstract, virtual DOM, and how React works in Chapter 10, Behind the Scenes of React and Optimization Opportunities. That’s why React (the library) splits its core logic across two main packages:

• The main react package
• The react-dom package

The main react package is a third-party JavaScript library that needs to be imported into a project to use React’s features (like JSX or state) there. It’s this package that creates this virtual DOM and derives the current UI state. But you also need the react-dom package in your project if you want to manipulate the DOM with React.

The react-dom package, specifically the react-dom/client part of that package, acts as a “translation bridge” between your React code, the internally generated virtual DOM, and the browser with its actual DOM that needs to be updated. It’s the react-dom package that will produce the actual DOM instructions that will select, update, delete, and create DOM elements.

This split exists because you can also use React with other target environments. A very popular and well-known alternative to the DOM (i.e., to the browser) would be React Native, which allows developers to build native mobile apps with the help of React. With React Native, you also include the react package in your project, but in place of react-dom, you would use the react-native package. In this book, “React” refers to both the react package and the “bridge” packages (like react-dom).

React can be used to simplify the creation of complex UIs, and there are two main ways of doing that:

• Manage parts of a website (e.g., a chat box in the bottom left corner).
• Manage the entire page and all user interactions that occur on it.

Both approaches are viable, but the more popular and common scenario is the second one: using React to manage the entire web page, instead of just parts of it. This approach is more popular because most websites that have complex UIs have not just one, but multiple complex elements on their pages. Complexity would actually increase if you were to start using React for some website parts without using it for other areas of the site. For this reason, it’s very common to manage the entire website with React.

This doesn’t even stop after using React on one specific page of the site. Indeed, React can be used to handle URL path changes and update the parts of the page that need to be updated in order to reflect the new page that should be loaded. This functionality is called routing and third-party packages like react-router-dom (see Chapter 13, Multipage Apps with React Router), which integrate with React, allow you to create a website wherein the entire UI is controlled via React.

A website that does not just use React for parts of its pages but instead for all subpages and for routing is often built as a SPA because it’s common to create React projects that contain only one HTML file (typically named index.html), which is used to initially load the React JavaScript code. Thereafter, the React library and your React code take over and control the actual UI. This means that the entire UI is created and managed by JavaScript via React and your React code.

That being said, it’s also becoming more and more popular to build full-stack React apps, where frontend and backend code are merged. Modern React frameworks like Next.js simplify the process of building such web apps. Whilst the core concepts are the same, no matter which kind of application is built, this book will explore full-stack React app development in greater detail in Chapter 15, Server-side Rendering & Building Fullstack Apps with Next.js, Chapter 16, React Server Components and Server Actions and Chapter 17, Understanding React Suspense and the use() Hook.

Ultimately, this book prepares you for working with React on all kinds of React projects since the core building blocks and key concepts are always the same.

Creating a React Project with Vite

To work with React, the first step is the creation of a React project. The official documentation recommends using a framework like Next.js. But while this might make sense for complex web applications, it’s overwhelming for getting started with React and for exploring React concepts. Next.js and other frameworks introduce their own concepts and syntax. As a result, learning React can quickly become frustrating since it can be difficult to tell React features apart from framework features. In addition, not all React apps need to be built as full-stack web apps – consequently, using a framework like Next.js might add unnecessary complexity.

That’s why Vite-based React projects have emerged as a popular alternative. Vite is an open-source development and build tool that can be used to create and run web development projects based on all kinds of libraries and frameworks – React is just one of the many options.

Vite creates projects that come with a built-in, preconfigured build process that, in the case of React projects, takes care of the JSX code transpilation. It also provides a development web server that runs locally on your system and allows you to preview the React app while you’re working on it.

You need a project setup like this because React projects typically use features like JSX, which wouldn’t work in the browser without prior code transformation. Hence, as mentioned earlier, a pre-processing step is required.

To create a project with Vite, you must have Node.js installed – preferably the latest (or latest LTS) version. You can get the official Node.js installer for all operating systems from https://nodejs.org/. Once you have installed Node.js, you will also gain access to the built-in npm command, which you can use to utilize the Vite package to create a new React project.

You can run the following command inside of your command prompt (Windows), bash (Linux), or terminal (macOS) program. Just make sure that you navigate (via cd) into the folder in which you want to create your new project:

npm create vite@latest my-react-project

Once executed, this command will prompt you to choose a framework or library you want to use for this new project. You should choose React and then JavaScript.

This command will create a new subfolder with a basic React project setup (i.e., with various files and folders) in the place where you ran it. You should run it in some path on your system where you have full read and write access and where you’re not conflicting with any system or other project files.

It’s worth noting that the project creation command does not install any required dependencies such as the React library packages. For that reason, you must navigate into the created folder in your system terminal or command prompt (via cd my-react-project) and install these packages by running the following command:

npm install

Once the installation finishes successfully, the project setup process is complete.

To view the created React application, you can start a development server on your machine via this command:

npm run dev

This invokes a script provided by Vite, which will spin up a locally running web server that pre-processes, builds, and hosts your React-powered SPA – by default on localhost:5173. Therefore, while working on the code, you typically have this development server up and running as it allows you to preview and test code changes.

Best of all, this local development server will automatically update the website whenever you save any code changes, hence allowing you to preview your changes almost instantly.

You can quit this server whenever you’re done for the day by pressing Ctrl + C in the terminal or command prompt where you executed npm run dev.

Whenever you’re ready to start working on the project again, you can restart the server via npm run dev.

The exact project structure (that is, the file names and folder names) may vary over time, but generally, every new Vite-based React project contains a couple of key files and folders:

• A src/ folder, which contains the main source code files for the project:
  • A main.jsx file, which is the main entry script file that will be executed first
  • An App.jsx file, which contains the root component of the application (you’ll learn more about components in the next chapter)
  • Various styling (*.css) files, which are imported by the JavaScript files
  • An assets/ folder that can be used to store images or other assets that should be used in your React code
• A public/ folder, which contains static files that will be part of the final website (e.g., a favicon)
• An index.html file, which is the single HTML page of this website
• package.json and package-lock.json are files that list and define the third-party dependencies of your project:
  • Production dependencies like react or react-dom
  • Development dependencies like eslint for automated code quality checks
• Other project configuration files (e.g., .gitignore for managing Git file tracking)
• A node_modules folder, which contains the actual code of the installed third-party packages

It’s worth noting that App.jsx and main.jsx use .jsx as a file extension, not .js. This is a file extension that’s enforced by Vite for files that do not just contain standard JavaScript but also JSX code. When working on a Vite project, most of your project files will consequently use .jsx as an extension.

Almost all of the React-specific code will be written in the App.jsx file or custom component files that will be added to the project. We will explore components in the next chapter.

• React is a library, though it’s actually a combination of two main packages: react and react-dom.
• Though it is possible to build non-trivial UIs without React, simply using vanilla JavaScript to do so can be cumbersome, error prone, and hard to maintain.
• React simplifies the creation of complex UIs by providing a declarative way to define the desired end states of the UI.
• Declarative means that you define the target UI content and structure, combined with different states (e.g., “Is a modal open or closed?”), and you leave it up to React to figure out the appropriate DOM instructions.
• The react package itself derives UI states and manages a virtual DOM. It is a “bridge,” like react-dom or react-native, that translates this virtual DOM into actual UI (DOM) instructions.
• With React, you can build SPAs, meaning that React is used to control the entire UI on all pages as well as the routing between pages.
• You can also use React, in combination with frameworks like Next.js, to build full-stack web applications where server- and client-side code are connected.
• React projects can be created with the help of the Vite package, which provides a readily configured project folder and a live preview development server.

What’s Next?

At this point, you should have a basic understanding of what React is and why you might consider using it, especially for building non-trivial UIs. You learned how to create new React projects with Vite, and you are now ready to dive deeper into React and the actual key features it offers.

In the next chapter, you will learn about a concept called components, which are the fundamental building blocks of React apps. You will learn how components are used to compose UIs and why those components are needed in the first place. The next chapter will also dive deeper into JSX and explore how it is transformed into regular JavaScript code and which kind of code you could write alternatively to JSX.

Test Your Knowledge!

Test your knowledge about the concepts covered in this chapter by answering the following questions. You can then compare your answers to example answers that can be found here: https://github.com/mschwarzmueller/book-react-key-concepts-e2/blob/01-what-is-react/exercises/questions-answers.md.

1. What is React?
2. Which advantage does React offer over vanilla JavaScript projects?
3. What’s the difference between imperative and declarative code?
4. What is a Single-Page-Application (SPA)?
5. How can you create new React projects and why do you need such a complex project setup?

Read this book alongside other users, AI experts, and the author himself.

Ask questions, provide solutions to other readers, chat with the author via Ask Me Anything sessions, and much more.

Scan the QR code or visit the link to join the community.

https://packt.link/ReactKeyConcepts2e