Backbone

Backbone was one of the first of these solutions, and it was an elegantly simple solution: it was a library that provided a way to create “models” and “views”. Models were conceptually sources of data, and views were conceptually user interfaces that consumed and rendered that data. Backbone exported comfortable APIs to work with these models and views, and then it provided a way to connect the models and views together. This was a solution that was very powerful and flexible for its time. It was also a solution that was scalable to use and allowed developers to test their code in isolation.

By way of example, here’s our button example from before but this time using Backbone:

const LikeButton = Backbone.View.extend({
  tagName: "button",
  attributes: {
    type: "button",
  },
  events: {
    click: "onClick",
  },
  initialize() {
    this.model.on("change", this.render, this);
  },
  render() {
    this.$el.text(this.model.get("liked") ? "Liked" : "Like");
    return this;
  },
  onClick() {
    fetch("/like", {
      method: "POST",
      body: JSON.stringify({ liked: !this.model.get("liked") }),
    })
      .then(() => {
        this.model.set("liked", !this.model.get("liked"));
      })
      .catch(() => {
        this.model.set("failed", true);
      })
      .finally(() => {
        this.model.set("pending", false);
      });
  },
});

const likeButton = new LikeButton({
  model: new Backbone.Model({
    liked: false,
  }),
});

document.body.appendChild(likeButton.render().el);

Notice how LikeButton is a subclass of Backbone.View and how it has a render method that returns this? We’d go on to see a similar render method in React, but let’s not get ahead of ourselves. Backbone exposed a chainable API that allowed developers to colocate logic as properties on objects. Comparing this to our previous example, we can see that Backbone has made it far more comfortable to create a button that is interactive and that updates the user interface in response to events. It also does this in a more structured way by grouping logic together. Some might also note that Backbone has made it more approachable to test this button in isolation because we can create a LikeButton instance and then call its render method to test it.

We’d test this component like so:

test("LikeButton", () => {
  const likeButton = new LikeButton({
    model: new Backbone.Model({
      liked: false,
    }),
  });
  expect(likeButton.render().el.textContent).toBe("Like");
});

We can even test the button’s behavior after its state changes, as in the case of a click event like so:

test("LikeButton", () => {
  const likeButton = new LikeButton({
    model: new Backbone.Model({
      liked: false,
    }),
  });
  expect(likeButton.render().el.textContent).toBe("Like");
  likeButton.onClick();
  expect(likeButton.render().el.textContent).toBe("Liked");
});

For this reason, Backbone was a very popular solution at the time. The alternative was to write a lot of imperative code that was hard to test and hard to reason about, with no guarantees that the code would work as expected in a reliable way. Therefore, Backbone was a very welcome solution.

KnockoutJS

Let’s compare this approach with another popular solution at the time: KnockoutJS. KnockoutJS was a library that provided a way to create “observables” and “bindings”. Observables were conceptually sources of data, and bindings were conceptually user interfaces that consumed and rendered that data: observables were like models, and bindings were like views. KnockoutJS exported APIs to work with these observables and bindings. Let’s look at how we’d implement this button in KnockoutJS. This will help us understand “why React” a little better. Here’s the KnockoutJS version of our button:

function createViewModel({ liked }) {
  const isPending = ko.observable(false);
  const hasFailed = ko.observable(false);
  const onClick = () => {
    isPending(true);
    fetch("/like", {
      method: "POST",
      body: JSON.stringify({ liked: !liked() }),
    })
      .then(() => {
        liked(!liked());
      })
      .catch(() => {
        hasFailed(true);
      })
      .finally(() => {
        isPending(false);
      });
  };
  return {
    isPending,
    hasFailed,
    onClick,
    liked,
  };
}

ko.applyBindings(createViewModel({ liked: ko.observable(false) }));

In KnockoutJS, a “view model” is a JavaScript object that contains keys and values that we bind to various elements in our page using the data-bind attribute. There are no “components” or “templates” in KnockoutJS, just a view model and a way to bind it to the browser.

Our function createViewModel is how we’d create a view model with Knockout. We then use ko.applyBindings to connect the view model to the host environment (the browser). The ko.applyBindings function takes a view model and then finds all the elements in the browser that have a data-bind attribute, which Knockout uses to bind them to the view model.

A button in our browser would be bound to this view model’s properties like so:

<button
  type="button"
  data-bind="click: onClick, text: liked ? 'Liked' : isPending ? 'Pending...' : hasFailed ? 'Failed' : 'Like'"
></button>

We bind the HTML element to the “view model” we created using our createViewModel function, and the site becomes interactive. As you can imagine, explicitly subscribing to changes in observables and then updating the user interface in response to these changes is a lot of work. KnockoutJS was a great library for its time, but it was also a library that required a lot of boilerplate code to get things done.

Moreover, view models often grew to be very large and complex, which led to increasing uncertainty around refactors and optimizations to code. Eventually, we’d end up with verbose monolithic view models that were hard to test and hard to reason about. Still, KnockoutJS was a very popular solution and it was a great library for its time. It was also relatively easy to test in isolation, which was a big plus.

For posterity, here’s how we’d test this button in KnockoutJS:

test("LikeButton", () => {
  const viewModel = createViewModel({ liked: ko.observable(false) });
  expect(viewModel.liked()).toBe(false);
  viewModel.onClick();
  expect(viewModel.liked()).toBe(true);
});

jQuery

Okay—we’re slowly understanding why React was needed, introduced, and loved. Let’s take a penultimate detour into jQuery to get a full picture of the state of the art at the time and the value that React brought to the table. Here’s our button example from before, but this time using jQuery:

<button type="button" id="like-button">Like</button>

$("#like-button").on("click", function () {
  this.prop("disabled", true);
  fetch("/like", {
    method: "POST",
    body: JSON.stringify({ liked: this.text() === "Like" }),
  })
    .then(() => {
      this.text(this.text() === "Like" ? "Liked" : "Like");
    })
    .catch(() => {
      this.text("Failed");
    })
    .finally(() => {
      this.prop("disabled", false);
    });
});

From this example, we observe a common pattern that previous libraries for building user interfaces implemented: they bound data to the user interface and used this data binding to update the user interface in place. While Knockout and Backbone bound models to views in one way or another, jQuery was far more active in directly manipulating the user interface itself.

jQuery ran in a heavily “side-effectful” way, constantly interacting with and altering state outside of its own control. This was a pattern that was common at the time, and it was a pattern that was difficult to reason about and test because the world around the code was constantly changing. At some point, we’d have to stop and ask ourselves: “what is the state of the browser right now?”—a question that became increasingly difficult to answer as our codebases grew.

This button with jQuery is hard to test because it’s just an event handler. If we were to write a test, it’d look like this:

test("LikeButton", () => {
  const $button = $("#like-button");
  expect($button.text()).toBe("Like");
  $button.trigger("click");
  expect($button.text()).toBe("Liked");
});

The only problem, is $('#like-button') will have returned null in the testing environment because it’s not a real browser. We’d have to mock out the browser environment to test this code, which is a lot of work. This is a common problem with jQuery: it’s hard to test because it’s hard to isolate and depends heavily on the browser environment. Moreover, jQuery shared ownership of the user interface with the browser, which made it difficult to reason about and test: the browser owned the interface, and jQuery was just a guest. This deviation from the “one-way data flow” paradigm was a common problem with libraries at the time.

These factors, combined with jQuery’s large bundle size and performance-intensive DOM manipulation led the web development community to search for better (faster and lighter) alternatives.

AngularJS

AngularJS was developed by Google in 2010. It was a pioneering JavaScript framework that had a significant impact on the web development landscape. It stood in sharp contrast to the libraries and frameworks we’ve been discussing by incorporating several innovative features, the ripples of which can be seen in subsequent libraries, including React. Through a detailed comparison of AngularJS with these other libraries and a look at its pivotal features, let’s try to understand the path it carved for React.

<!DOCTYPE html>
<html>
  <head>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.8.2/angular.min.js"></script>
  </head>
  <body ng-app="">
    <p>Name: <input type="text" ng-model="name" /></p>
    <p ng-if="name">Hello, {{name}}!</p>
  </body>
</html>

var app = angular.module("myApp", []);

app.controller("myController", function ($scope, myService) {
  $scope.greeting = myService.sayHello();
});

app.factory("myService", function () {
  return {
    sayHello: function () {
      return "Hello, World!";
    },
  };
});

var app = angular.module("myApp", [
  "ngRoute",
  "appRoutes",
  "userCtrl",
  "userService",
]);

var userCtrl = angular.module("userCtrl", []);
userCtrl.controller("UserController", function ($scope) {
  $scope.message = "Hello from UserController";
});

var userService = angular.module("userService", []);
userService.factory("User", function ($http) {
  //...
});

Declarative vs. Imperative Updates

React provides a declarative abstraction on the DOM. We’ll talk more about how it does this in more detail later in the book, but essentially it provides us a way to write code that expresses what we want to see, while then taking care of how it happens, ensuring our user interface is created and works in a safe, predictable, and efficient manner.

Let’s consider the list app that we created above. In React, we could rewrite it like this:

function MyList() {
  const [items, setItems] = useState(["I love"]);

  return (
    <div>
      <ul>
        {items.map((i) => (
          <li key={i /* keep items unique */}>{i}</li>
        ))}
      </ul>
      <NewItemForm />
    </div>
  );
}

Notice how in the return, we literally write something that looks like HTML: it looks like what we want to see. I want to see a box with a NewItemForm, and a list. Boom. How does it get there? That’s React’s problem. Do we batch list items to add chunks of them at once? Do we add them sequentially, one-by-one? React deals with how this is done, while we merely describe what we want done. In further chapters, we’ll dive into React and explore how exactly it does this.

Do we then depend on class names to reference HTML elements? Do we getElementById in JavaScript? Nope. React creates unique “React elements” for us under the hood that it uses to detect changes and make incremental updates so we don’t need to read class names and other identifiers from user code whose existence we cannot guarantee: our source of truth becomes exclusively JavaScript with React. We can then write code that is safe, predictable, and efficient.

We export our MyList component to React, and React gets it on the screen for us in a way that is safe, predictable, and performant—no questions asked. It does this by using a “virtual DOM”, which is a clone of the real DOM. It then compares the virtual DOM to the real DOM, and makes incremental updates to the real DOM to make it match the virtual DOM. This is how React is able to make updates to the DOM in a safe, predictable, and efficient manner.

The Virtual DOM

The virtual DOM is a programming concept that represents the real DOM but as a more efficient JavaScript object. If this is a little too in the weeds for now, don’t worry: we have an entire chapter dedicated to this soon that breaks things down in a little more detail. For now, it’s just important to know that the virtual DOM allows developers to update the UI without directly manipulating the actual DOM. React uses the virtual DOM to keep track of changes to a component and re-renders the component only when necessary. This approach is faster and more efficient than updating the entire DOM tree every time there is a change.

In React, the virtual DOM is a lightweight representation of the actual DOM tree. It is a plain JavaScript object that describes the structure and properties of the UI elements. React creates and updates the virtual DOM to match the actual DOM tree, and any changes made to the virtual DOM are applied to the actual DOM using a process called reconciliation.

To understand how the virtual DOM works, let’s consider the example of a like button. We will create a React component that displays a like button and the number of likes. When the user clicks the button, the number of likes should increase by one.

Here is the code for our component:

import React, { useState } from "react";

function LikeButton() {
  const [likes, setLikes] = useState(0);

  function handleLike() {
    setLikes(likes + 1);
  }

  return (
    <div>
      <button onClick={handleLike}>Like</button>
      <p>{likes} Likes</p>
    </div>
  );
}

export default LikeButton;

In this code, we have used the useState hook to create a state variable likes, which holds the number of likes. We have also defined a function handleLike that increases the value of likes by one when the button is clicked. Finally, we render the like button and the number of likes using JSX.

Now, let’s take a closer look at how the virtual DOM works in this example.

{
  type: 'div',
  props: {},
  children: [
    {
      type: 'button',
      props: { onClick: handleLike },
      children: ['Like']
    },
    {
      type: 'p',
      props: {},
      children: [0, ' Likes']
    }
  ]
}

{
  type: 'div',
  props: {},
  children: [
    {
      type: 'button',
      props: { onClick: handleLike },
      children: ['Like']
    },
    {
      type: 'p',
      props: {},
      children: [1, ' Likes']
    }
  ]
}

The Component Model

React revolutionized the web because it highly encouraged “thinking in components”: that is, breaking your app into smaller pieces, and adding them to a larger tree to compose your application. The component model is a key concept in React, and it’s what makes React so powerful. Let’s talk about why.

1. It encourages reusing the same thing everywhere so that if it breaks, you fix it in one place and it’s fixed everywhere. This is called “DRY” (don’t repeat yourself) development and is a key concept in software engineering. It’s also a key concept in React. For example, if we have a Button component, we can use it in many places in our app, and if we need to change the style of the button, we can do it in one place and it’s changed everywhere.
2. React is more easily able to keep track of components and do performance magic like memoization, batching, and other optimizations under the hood if it’s able to identify specific components over and over again and track updates to them over time. This is called “keying”. For example, if we have a Button component, we can give it a key prop and React will be able to keep track of the Button component over time and “know” when to update it, or when to skip updating it and continue making minimal changes to the user interface. Most components have implicit keys, but we can also explicitly provide them if we want to.
3. It helps us separate concerns and colocate logic closer to the parts of the user interface that it affects. For example, if we have a RegisterButton component, we can put the logic for what happens when the button is clicked in the same file as the RegisterButton component, instead of having to jump around to different files to find the logic for what happens when the button is clicked. The RegisterButton component would wrap a more simple Button component, and the RegisterButton component would be responsible for handling the logic for what happens when the button is clicked. This is called “composition”.

React’s component model is a fundamental concept that underpins the framework’s popularity and success. This approach to development has numerous benefits, including increased modularity, easier debugging, and more efficient code reuse.

Let’s explore the advantages of React’s component model in greater depth, using code examples to demonstrate its power. We will begin by examining the concept of modularity and how it is enabled by the component model. We will then move on to discuss how the component model facilitates efficient code reuse, and how it helps developers to debug their applications more easily.

import React from "react";

function InputField(props) {
  return <input type="text" name={props.name} />;
}

function SubmitButton(props) {
  return <button type="submit">{props.label}</button>;
}

import React from "react";

function InputField(props) {
  return <input type="text" name={props.name} />;
}

function SubmitButton(props) {
  return <button type="submit">{props.label}</button>;
}

function Form(props) {
  return (
    <form onSubmit={props.onSubmit}>
      <InputField name="email" />
      <SubmitButton label="Submit" />
    </form>
  );
}

import React, { useState } from "react";

function AccordionItem(props) {
  const [isOpen, setIsOpen] = useState(false);

  const toggleOpen = () => {
    setIsOpen(!isOpen);
  };

  return (
    <div>
      <div onClick={toggleOpen}>{props.title}</div>
      {isOpen && <div>{props.content}</div>}
    </div>
  );
}

function Accordion(props) {
  return (
    <div>
      {props.items.map((item) => (
        <AccordionItem
          key={item.id}
          title={item.title}
          content={item.content}
        />
      ))}
    </div>
  );
}

import React from "react";
import { Accordion } from "./components";

const items = [
  {
    title: "Item 1",
    content: "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
  },
  {
    title: "Item 2",
    content:
      "Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
  },
  {
    title: "Item 3",
    content:
      "Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.",
  },
];

function App() {
  return (
    <div>
      <Accordion items={items} />
    </div>
  );
}

export default App;

import React, { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  const decrement = () => {
    setCount(count - 1);
  };

  return (
    <div>
      <div>{count}</div>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
    </div>
  );
}

const decrement = () => {
  console.log("Before decrement: ", count);
  setCount(count - 1);
  console.log("After decrement: ", count);
};

Before decrement: 1
After decrement: 1
Before decrement: 0
After decrement: 0
Before decrement: -1
After decrement: -1

const decrement = () => {
  setCount((prevCount) => prevCount - 1);
};

Answering the Question “Why is React a Thing?”

React is a thing because it allows developers to build user interfaces with greater ease and reliability by enabling us to declaritively express what we’d like on the screen while React takes care of the how, as it makes incremental updates to the DOM in a safe, predictable, and efficient manner. It also encourages us to think in components, which helps us separate concerns and reuse code more easily. It is battle tested at Facebook, and designed to be used at scale. It’s also open source and free to use.

React also has a vast and active ecosystem, with a wide range of tools, libraries, and resources available to developers. This ecosystem includes tools for testing, debugging, and optimizing React applications, as well as libraries for common tasks such as data management, routing, and state management. Additionally, the React community is highly engaged and supportive, with many online resources, forums, and communities available to help developers learn and grow.

React is platform agnostic, meaning that it can be used to build web applications for a wide range of platforms, including desktop, mobile, and VR. This flexibility makes React an attractive option for developers who need to build applications for multiple platforms, as it allows them to use a single codebase to build applications that run across multiple devices.

Finally, React is backed by Meta, which is one of the largest and most influential technology companies in the world. This backing provides developers with confidence that React is a stable and well-supported technology, with a long-term roadmap for future development. Additionally, Facebook’s backing has helped to promote and popularize React, making it a widely recognized and respected technology in the development community.

To conclude, React’s value proposition is centered around its component-based architecture, declarative programming model, virtual DOM, JSX, extensive ecosystem, platform agnostic nature, and backing by Facebook. Together, these features make React an attractive option for developers who need to build fast, scalable, and maintainable web applications. Whether you’re building a simple website or a complex enterprise application, React can help you achieve your goals more efficiently and effectively than many other technologies. Let’s review.

Review Questions

Let’s make sure you’ve fully grasped the topics we covered. Take a moment to answer the following questions:

1. What was the motivation to create React?
2. What are the advantages of using Virtual DOM over real DOM? Can you think of any potential disadvantages?
3. How is React different from other JavaScript libraries like Knockout, Backbone, and jQuery?
4. What are the benefits of declarative programming abstractions?
5. What is the component model? Why is it so revolutionary?

If you have trouble answering these questions, this chapter may be worth another read. If not, let’s explore the next chapter.

Benefits of JSX

There are several benefits to using JSX in web development:

1. Easy to Read and Write: JSX syntax is easy to read and write, especially for developers who are familiar with HTML.
2. Improved Performance: JSX code can be compiled into more efficient JavaScript code than traditional HTML templates, resulting in improved performance.
3. Strong Typing: JSX allows for strong typing, which can help catch errors before they occur.
4. Encourages Component-Based Architecture: JSX encourages a component-based architecture, which can help make code more modular and easier to maintain.
5. Widely Used: JSX is widely used in the React community, and is also supported by other libraries and frameworks.

Drawbacks of JSX

There are also some drawbacks to using JSX:

1. Learning Curve: Developers who are not familiar with JSX may find it difficult to learn and understand.
2. Requires Compilation: JSX code must be compiled into regular JavaScript code before it can be executed, which adds an extra step to the development process.
3. Mixing of Concerns: Some developers argue that JSX mixes concerns by combining HTML-like code with JavaScript code, making it harder to separate presentation from logic.
4. IDE Support: Some IDEs do not have strong support for JSX, which can make development more difficult.

Despite its drawbacks, JSX has become a popular choice for web developers, particularly those of us working with React. It offers a powerful and flexible way to create components and build user interfaces, and has been embraced by a large and active community. In addition to its use with React, JSX has also been adopted by other libraries and frameworks, including Vue.js, Angular, and Ember.js. This shows that JSX has wider applications beyond just React, and its popularity is likely to continue to grow in the coming years.

Overall, JSX is a powerful and flexible tool that can help us build dynamic and responsive user interfaces. JSX was created with one job: make expressing, presenting, and maintaining the code for React components simple while preserving powerful capabilities such as iteration, computation, and inline execution.

JSX becomes vanilla JavaScript before it makes it to the browser. How does it accomplish this? Let’s take a look under the hood!

How Does Code Work?

The code snippet in the section above is literally just text. How is this interpreted by a computer and then executed? For starters, it’s not a big clever RegExp (Regular Expression) that can identify key words in a text file. I once tried to build a programming language this way and failed miserably, because regular expressions are often hard to get right, harder still to read back and mentally parse, and quite difficult to maintain.

Instead, this code is compiled using a compiler. A compiler is a software tool that translates source code written in a high-level programming language into machine code that can be executed by a computer. The process of compiling involves several steps, including lexical analysis, parsing, semantic analysis, optimization, and code generation. Let’s explore each of these steps in more detail and discuss the role of compilers in the modern software development landscape.

A compiler uses a three-step process (at least in JavaScript anyway) that is in play here. These steps are called tokenization, parsing, and code generation. Let’s look at each of these steps in more detail.

• Tokenization is essentially breaking up a string of characters into meaningful tokens. When a tokenizer is stateful and each token contains state about its parents and/or children, a tokenizer is called a lexer. Lexing is basically stateful tokenization.

  Lexers have lexer rules that, in common cases, use a regular expressions or similar to detect key words in a text string representing a programming language. The lexer then maps these key words to some type of enumerable value. For example,

  • const becomes 0
  • let becomes 1
  • function becomes 2
  • etc.

  Once a string is tokenized or lexed, we move on to the next step.

• Parsing is the process of taking the tokens and converting them into an abstract syntax tree (AST). The syntax tree is a data structure that represents the structure of the code. For example, the code snippet we looked at in the section above would be represented as a syntax tree like this:

  {
  type: "Program",
  body: [
      {
      type: "VariableDeclaration",
      declarations: [
          {
          type: "VariableDeclarator",
          id: {
              type: "Identifier",
              name: "a"
          },
          init: {
              type: "Literal",
              value: 1,
              raw: "1"
          }
          }
      ],
      kind: "const"
      },
      {
      type: "VariableDeclaration",
      declarations: [
          {
          type: "VariableDeclarator",
          id: {
              type: "Identifier",
              name: "b"
          },
          init: {
              type: "Literal",
              value: 2,
              raw: "2"
          }
          }
      ],
      kind: "let"
      },
      {
      type: "ExpressionStatement",
      expression: {
          type: "CallExpression",
          callee: {
          type: "Identifier",
          name: "console"
          },
          arguments: [
          {
              type: "BinaryExpression",
              left: {
              type: "Identifier",
              name: "a"
              },
              right: {
              type: "Identifier",
              name: "b"
              },
              operator: "+"
          }
          ]
      }
      }
  ]
  }
  

  The string, thanks to the parser, becomes effectively a JSON object. As programmers, when we have a data structure like this, we can do some really fun things. Language engines use these data structures to complete the process with the third step,

• Code Generation, where the compiler generates machine code from the AST. This involves translating the code in the AST into a series of instructions that can be executed directly by the computer’s processor. The resulting machine code is then executed by the JavaScript engine. Overall, the process of converting an AST into machine code is complex and involves a lot of different steps. However, modern compilers are highly sophisticated and can produce highly optimized code that runs efficiently on a wide range of hardware architectures.

There are several types of compilers, each with different characteristics and use cases. Some of the most common types of compilers include:

• Native Compilers - These are compilers that produce machine code that can be executed directly by the target platform’s processor. Native compilers are typically used to create standalone applications or system-level software.

• Cross-Compilers - These are compilers that produce machine code for a different platform than the one on which the compiler is running. Cross-compilers are often used in embedded systems development or when targeting specialized hardware.

• Just-In-Time (JIT) Compilers - These are compilers that translate code into machine code at runtime, rather than ahead of time. JIT compilers are commonly used in virtual machines, such as the Java Virtual Machine, and can offer significant performance advantages over traditional interpreters.

• Interpreters - These are programs that execute source code directly, without the need for compilation. Interpreters are typically slower than compilers, but offer greater flexibility and ease of use.

To run JavaScript code in browsers, we use a Just-In-Time (JIT) compiler. In a JIT compiler, the source code is first compiled into an intermediate representation, such as bytecode, which is then translated into machine code as needed. This allows the compiler to optimize the code based on runtime information, such as the values of variables and the execution paths taken by the program. JavaScript engines inside web browsers include a JIT compiler. The JIT compiler translates JavaScript code into machine code on the fly, as the code is executed.

Runtimes usually interface with engines to provide more contextual helpers and features for their specific environment. The most popular JavaScript runtime, by far, is the common web browser; like Google Chrome. This runtime gives JavaScript context like the window object and the document object. Another very popular runtime is Node.js, which is a JavaScript runtime that runs on servers. If you’ve worked with both browsers and Node.js before, you may have noticed Node.js does not have a global window object. This is because it’s a different runtime and, as such, provides different context. Cloudflare created a similar runtime called Workers whose sole responsibility is executing JavaScript on globally distributed edge servers, but we’re digressing. How does this all relate to JavaScript eXtended syntax?

Extending JavaScript Syntax

Now that we understand how one would extend JavaScript syntax, how does JSX work? How would we do it? To extend JavaScript syntax, we’d need to either have a different engine that can understand our new syntax, or deal with our new syntax before it reaches the engine. The former is nearly impossible to do because engines require a lot of thought to create and maintain since they tend to be widely used. If we decided to go with that option, it might take years or decades before we can use our extended syntax! We’d then even have to make sure our “bespoke special engine™” is used everywhere. How would we convince browser vendors et al to switch to our unpopular new thing? This wouldn’t work.

The latter is quicker: let’s explore how we can deal with our new syntax before it reaches the engine. To do this, we’d need to create our own lexer and parser that can understand our extended language: that is, take a text string of code and understand it. Then, instead of generating machine code as is traditional, we can take this syntax tree and instead generate plain old regular vanilla JavaScript that all current engines can understand. This is precisely what Babel in the JavaScript ecosystem does, along with other tools like TypeScript, Traceur, and swc.

Because of this, JSX cannot be used directly in the browser, but instead requires a “build step” where a custom parser runs against it, then compiles it into a syntax tree. This code is then transformed into vanilla JavaScript in a final distributable bundle. This is called “transpilation”: "transformed, then compiled code”.

Whew! What a deep dive! Now that we understand how we can build our own extension of JavaScript, let’s look at what we can do with this specific extension JSX.

Presentational/Container Components

It’s common to see a React design pattern that is a combination of two components: a presentational component and a container component. The presentational component is the one that renders the UI, and the container component is the one that handles the state of the UI. Consider a counter. This is how a counter would look implementing this pattern:

const PresentationalCounter = (props) => {
  return (
    <section>
      <button onClick={props.increment}>+</button>
      <button onClick={props.decrement}>-</button>
      <button onClick={props.reset}>Reset</button>
      <h1>Current Count: {props.count}</h1>
    </section>
  );
};

const ContainerCounter = () => {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1);
  const decrement = () => setCount(count - 1);
  const reset = () => setCount(0);

  return (
    <PresentationalCounter
      count={count}
      increment={increment}
      decrement={decrement}
      reset={reset}
    />
  );
};

In this example, we’ve got two components: a presentational component (PresentationalCounter) and a container component (ContainerCounter). The presentational component is the one that renders the UI, and the container component is the one that handles the state.

Why is this a thing? This pattern is quite useful because of the principle of single responsibility. Instead of having a component be responsible for how it should look and how it should work, we split these concerns. The result? PresentationalCounter can be passed between other stateful containers and preserve the look we want, while ContainerCounter can be replaced with another stateful container and preserve the functionality we want.

We can also unit test ContainerCounter in isolation and instead visually test (using Storybook or similar) PresentationalCounter in isolation. We can also assign engineers or engineering teams more comfortable with visual work to PresentationalCounter while assigning engineers who prefer data structures and algorithms to ContainerCounter.

We have so many more options because of this decoupled approach. For these reasons, the Presentational/Container component pattern has gained quite a lot of popularity and is still in use today.

Higher Order Components (HOC)

From Wikipedia,

In mathematics and computer science, a higher-order function (HOF) is a function that does at least one of the following: takes one or more functions as arguments (i.e. a procedural parameter, which is a parameter of a procedure that is itself a procedure), returns a function as its result.

In the JSX world, an HOC is basically this: a component that takes another component as an argument and returns a new component that is the result of the composition of the two. HOC’s are great for shared behavior across components that we’d rather not repeat.

For example: many web applications need to request data from some data source asynchronously. Loading and error states are often inevitable, but we sometimes forget to account for them in our software. If we manually add loading, data, and error props to our components, the chance we miss a few gets even higher. Let’s consider a basic todo list app:

const App = () => {
  const [data, setData] = useState([]);

  useEffect(() => {
    fetch("https://mytodolist.com/items")
      .then((res) => res.json())
      .then(setData);
  }, []);

  return <BasicTodoList data={data} />;
};

This app has a few problems. We don’t account for loading or error states. Let’s fix this.

const App = () => {
  const [isLoading, setIsLoading] = useState(true);
  const [data, setData] = useState([]);
  const [error, setError] = useState([]);

  useEffect(() => {
    fetch("https://mytodolist.com/items")
      .then((res) => res.json())
      .then((data) => {
        setIsLoading(false);
        setData(data);
      })
      .catch(setError);
  }, []);

  return isLoading ? (
    "Loading..."
  ) : error ? (
    error.message
  ) : (
    <BasicTodoList data={data} />
  );
};

Yikes. This got pretty unruly pretty fast. Moreover, this solves the problem for just one component. Do we need to add these pieces of state (i.e. loading, data, and error) to each component that interacts with a foreign data source? This is a cross-cutting concern, and exactly where higher-order components shine.

Instead of repeating this loading, error, data pattern for each component that talks to a foreign data source asynchronously, we can use a higher-order component factory to deal with these states for us. Let’s consider a withAsync higher-order component factory that remedies this.

const TodoList = withAsync(BasicTodoList);

withAsync will deal with loading and error states, and render any component when data is available. Let’s look at its implementation.

const withAsync = (Component) => (props) => {
  if (props.loading) {
    return "Loading...";
  }

  if (props.error) {
    return error.message;
  }

  return (
    <Component
      // Pass through whatever other props we give `Component`.
      {...props}
    />
  );
};

So now, when any Component is passed into withAsync, we get a new component that renders appropriate pieces of information based on its props. This changes our initial component into something more workable:

const TodoList = withAsync(BasicTodoList);

const App = () => {
  const [isLoading, setIsLoading] = useState(true);
  const [data, setData] = useState([]);
  const [error, setError] = useState([]);

  useEffect(() => {
    fetch("https://mytodolist.com/items")
      .then((res) => res.json())
      .then((data) => {
        setIsLoading(false);
        setData(data);
      })
      .catch(setError);
  }, []);

  return <TodoList loading={isLoading} error={error} data={data} />;
};

No more nested ternaries, and the TodoList itself can show appropriate information depending on whether it’s loading, has an error, or has data. Since the withAsync HOC factory deals with this cross-cutting concern, we can wrap any component that talks to an external data source with it and get back a new component that responds to loading and error props. Consider a blog:

const Post = withAsync(BasicPost);
const Comments = withAsync(BasicComments);

const Blog = ({ req }) => {
  const { loading: isPostLoading, error: postLoadError } = usePost(
    req.query.postId
  );
  const { loading: areCommentsLoading, error: commentLoadError } = useComments({
    postId: req.query.postId,
  });

  return (
    <>
      <Post
        id={req.query.postId}
        loading={isPostLoading}
        error={postLoadError}
      />
      <Comments
        postId={req.query.postId}
        loading={areCommentsLoading}
        error={commentLoadError}
      />
    </>
  );
};

export default Blog;

In this example, both Post and Comments use the withAsync HOC pattern which returns a newer version of BasicPost and BasicComments respectively that now respond to loading and error props. The behavior for this cross-cutting concern is centrally managed in withAsync’s implementation, so we account for loading and error states “for free” just by using the HOC pattern here.

Render Props

Since we’ve talked about JSX expressions above, a common pattern is to have props that are functions that receive component-scoped state as arguments to facilitate code reuse. Here’s a simple example:

<WindowSize
  render={({ width, height }) => (
    <div>
      Your window is {width}x{height}px
    </div>
  )}
/>

Notice how there’s a prop called render that receives a function as a value? This prop even outputs some JSX markup that’s actually rendered. But why? Turns out WindowSize does some magic internally to compute the size of a user’s window, and then calls props.render to return the structure we declare.

Let’s take a look at WindowSize to understand this a bit more:

const WindowSize = (props) => {
  const [size, setSize] = useState({ width: -1, height: -1 });

  useEffect(() => {
    const handleResize = () => {
      setSize({ width: window.innerWidth, height: window.innerHeight });
    };
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return props.render(size);
};

From this example, what we can see is that WindowSize uses an event listener to store some stuff in state on every resize, but the component itself is headless: it has no opinions about what UI to present. Instead, it yields control to whatever parent is rendering it and calls the render prop it’s supplied: effectively inverting control to its parent for the rendering job.

This helps a component that depends on the window size for rendering receive this information without duplicating the useEffect blocks and keeping our code a little bit more DRY (Don’t Repeat Yourself). This pattern is no longer as popular, and has since been effectively replaced with React Hooks (more on them later in the book).

<WindowSize>
  {({ width, height }) => (
    <div>
      Your window is {width}x{height}px
    </div>
  )}
</WindowSize>

Control Props

The Control Props pattern is a powerful way to control multiple components dependent on a common piece of state. React’s own documentation is pretty clear about the concept of controlled components, where a component’s state is controlled by React instead of the component itself, which is called an uncontrolled component.

Here’s an example of an uncontrolled component:

const Form = () => {
  return (
    <form>
      <input type="text" />
      <button type="submit">Submit</button>
    </form>
  );
};

The input’s value is self-contained by the browser, and React doesn’t have access to it nor controls it. This is an uncontrolled component because React does not manage its state. Let’s control it.

const Form = () => {
  const [value, setValue] = useState("");

  return (
    <form>
      <input
        type="text"
        value={value}
        onChange={(e) => setValue(e.target.value)}
      />
      <button type="submit">Submit</button>
    </form>
  );
};

By binding this component’s value prop to the state managed by React, this component is now controlled by React. But you might be wondering, why we’re talking about controlled components instead of control props. The control props pattern is close to this: a control prop is a prop on a child component whose value is state managed by a parent component.

Let’s illustrate this with an example:

const ListPage = ({ items }) => {
  const [filter, setFilter] = useState("");
  return (
    <section>
      <HeaderBar>
        <input
          type="checkbox"
          checked={filter.length > 0} // <- control prop to keep this in sync with `filter` state
        />{" "}
        Filtered by term
        {filter}
        <input
          type="text"
          value={filter} // <- control prop to keep this in sync with `filter` state
          onChange={(e) => setFilter(e.target.value)}
        />
      </HeaderBar>
      <List
        items={items}
        filter={filter} // <- control prop to keep this in sync with `filter` state
      />
    </section>
  );
};

From the above example, we use three control props based on one piece of state to keep our entire component tree in sync with our page’s “filtered” state. Looking at this, we see that the control props pattern helps us manage state and keep it synchronized across our React applications.

Prop Collections

We often need to bundle a whole bunch of props together. For example, when creating drag-and-drop user interfaces, there are quite a few props to manage:

• onDragStart to tell the browser what to do when a user starts dragging an element.
• onDragOver to identify a dropzone.
• onDrop to execute some code when an element is dropped on this element.
• onDragEnd to tell the browser what to do when an element is done being dragged.

Moreover, data/elements cannot be dropped in other elements by default. To allow an element to be dropped on another, we must prevent the default handling of the element. This is done by calling the event.preventDefault method for the onDragOver event for possible drop zone.

Since these props usually go together, and since onDragOver usually defaults to event => { event.preventDefault(); moreStuff(); }, we can collect these props together and reuse them in various components like so:

export const droppableProps = {
  onDragOver: (event) => {
    event.preventDefault();
  },
  onDrop: (event) => {},
};

export const draggableProps = {
  onDragStart: (event) => {},
  onDragEnd: (event) => {},
};

Now, if we have a React component we expect to behave like a dropzone, we can use the prop collection on it like this:

<Dropzone {...droppableProps} />

This is the prop collection pattern, and it makes a number of props reusable. This is often quite widely used in the accessibility space to include a number of aria-* props on accessible components. One problem that’s still present though is that if we write a custom onDragOver prop and override the collection, we lose the event.preventDefault call that we get out of the box using the collection.

This can cause unexpected behavior, removing the ability to drop a component on Dropzone:

<Dropzone
  {...droppableProps}
  onDragOver={() => {
    alert("Dragged!");
  }}
/>

It removes the ability to drop something on Dropzone since we no longer call event.preventDefault on it. Thankfully, we can fix this using prop getters.

export const getDroppableProps = () => {
  return {
    onDragOver: (event) => {
      event.preventDefault();
    },
    onDrop: (event) => {},
  };
};

const compose =
  (...functions) =>
  (...args) =>
    functions.forEach((fn) => fn?.(...args));

export const getDroppableProps = ({
  onDragOver: replacementOnDragOver,
  ...replacementProps
}) => {
  const defaultOnDragOver = (event) => {
    event.preventDefault();
  };

  return {
    onDragOver: compose(replacementOnDragOver, defaultOnDragOver),
    onDrop: (event) => {},
    ...replacementProps,
  };
};

<Dropzone
  {...getDroppableProps({
    onDragOver: () => {
      alert("Dragged!");
    },
  })}
/>

Compound Components

Sometimes, we have accordion components like this:

<Accordion
  items={[
    { label: "One", content: "lorem ipsum for more, see https://one.com" },
    { label: "Two", content: "lorem ipsum for more, see https://two.com" },
    { label: "Three", content: "lorem ipsum for more, see https://three.com" },
  ]}
/>

This component is intended to render a list similar to this, except only one item can be open at a given time.

• One
• Two, or
• Three

The inner workings of this component would look something like this:

export const Accordion = ({ items }) => {
  const [activeItemIndex, setActiveItemIndex] = useState(0);

  return (
    <ul>
      {items.map((item, index) => (
        <li onClick={() => setActiveItemIndex(index)} key={item.id}>
          <strong>{item.label}</strong>
          {index === activeItemIndex && i.content}
        </li>
      ))}
    </ul>
  );
};

But what if we wanted a custom separator in between items Two and Three? What if we wanted the third link to be red or something? We’d probably resort to some type of hack like this:

<Accordion
  items={[
    { label: "One", content: "lorem ipsum for more, see https://one.com" },
    { label: "Two", content: "lorem ipsum for more, see https://two.com" },
    { label: "---" },
    { label: "Three", content: "lorem ipsum for more, see https://three.com" },
  ]}
/>

But that wouldn’t look the way we want. So we’d probably do more hacks on our current hack:

export const Accordion = ({ items }) => {
  const [activeItemIndex, setActiveItemIndex] = useState(0);

  return (
    <ul>
      {items.map((item, index) =>
        item === "---" ? (
          <hr />
        ) : (
          <li onClick={() => setActiveItemIndex(index)} key={item.id}>
            <strong>{item.label}</strong>
            {index === activeItemIndex && i.content}
          </li>
        )
      )}
    </ul>
  );
};

Now is that code we’d be proud of? I’m not sure. This is why we need Compound Components: they allow us to have a grouping of interconnected, distinct components that share state, but are atomically renderable, giving us more control of the element tree.

This accordion, expressed using the compound components pattern, would look like this:

<Accordion>
  <AccordionItem item={{ label: "One" }} />
  <AccordionItem item={{ label: "Two" }} />
  <AccordionItem item={{ label: "Three" }} />
</Accordion>

Let’s explore how this pattern can be implemented in React. First, we’ll start with a context that each part of the accordion can read from:

const AccordionContext = createContext({
  activeItemIndex: 0,
  setActiveItemIndex: () => 0,
});

Then, our Accordion component will just provide context to its children:

export const Accordion = ({ items }) => {
  const [activeItemIndex, setActiveItemIndex] = useState(0);

  return (
    <AccordionContext.Provider value={{ activeItemIndex, setActiveItemIndex }}>
      <ul>{children}</ul>
    </AccordionContext.Provider>
  );
};

Now, let’s create discrete AccordionItem components that consume and respond to this context as well:

export const AccordionItem = ({ item, index }) => {
  // Note we're using the context here, not state!
  const { activeItemIndex, setActiveItemIndex } = useContext(AccordionContext);

  return (
    <li onClick={() => setActiveItemIndex(index)} key={item.id}>
      <strong>{item.label}</strong>
      {index === activeItemIndex && i.content}
    </li>
  );
};

Now that we’ve got multiple parts for our Accordion making it a compound component, our usage of the Accordion goes from this:

<Accordion
  items={[
    { label: "One", content: "lorem ipsum for more, see https://one.com" },
    { label: "Two", content: "lorem ipsum for more, see https://two.com" },
    { label: "Three", content: "lorem ipsum for more, see https://three.com" },
  ]}
/>

to this:

<Accordion>
  {items.map((item, index) => (
    <AccordionItem key={item.id} item={item} index={index} />
  ))}
</Accordion>

The benefit of this that we have far more control, while each AccordionItem is aware of the larger state of Accordion. So now, if we wanted to include a horizontal line between items Two and Three, we could break out of the map and go more manual if we wanted to:

<Accordion>
  <AccordionItem key={items[0].id} item={items[0]} index={0} />
  <AccordionItem key={items[1].id} item={items[1]} index={1} />
  <hr />
  <AccordionItem key={items[2].id} item={items[2]} index={2} />
</Accordion>

Or, we could do something more hybrid like:

<Accordion>
  {items.slice(0, 2).map((item, index) => (
    <AccordionItem key={item.id} item={item} index={index} />
  ))}
  <hr />
  {items.slice(2).map((item, index) => (
    <AccordionItem key={item.id} item={item} index={index} />
  ))}
</Accordion>

This is the benefit of compound components: they invert control of rendering to the parent, while preserving contextual state awareness among children. The same approach could be used for a tab UI, where tabs are aware of the current tab state while having varying levels of element nesting.

Context Module

The context module pattern is a powerful pattern at scale where application state can be fairly complex. In essence, it works by exporting utility functions that mutate state by accepting dispatch functions as arguments in a tree-shakeable and lazy-loadable way.

Here’s a contrived example with a counter, coming full circle from our first pattern which was also a counter. Let’s start by creating a context:

import React from "react";

const CounterContext = React.createContext(null);
CounterContext.displayName = "CounterContext";

Now, let’s create a provider so we can share this context with our React app:

export function CounterProvider({ children }) {
  const [state, dispatch] = useState({ counter: 0 });

  return (
    <CounterContext.Provider value={{ state, dispatch }}>
      {children}
    </CounterContext.Provider>
  );
}

The final step to implement this pattern is to export a few utility functions that can be used to manipulate state:

export const increment = (dispatch, by = 1) =>
  dispatch((oldValue) => oldValue + by);

export const decrement = (dispatch, by = 1) =>
  dispatch((oldValue = oldValue - by));

export const reset = (dispatch) => dispatch(0);

Notice how they accept dispatch as their first argument. This makes them pluggable, and able to run in a higher degree of isolation. Now, we can use these functions in our application, and import them on-demand, reducing bundle size and preserving performance.

const PresentationalCounter = (props) => {
  return (
    <section>
      <button onClick={props.increment}>+</button>
      <button onClick={props.decrement}>-</button>
      <button onClick={props.reset}>Reset</button>
      <h1>Current Count: {props.count}</h1>
    </section>
  );
};

const ContainerCounter = () => {
  const { dispatch } = useContext(CounterContext);

  return (
    <PresentationalCounter
      count={count}
      increment={() => increment(dispatch)}
      decrement={() => decrement(dispatch)}
      reset={() => reset(dispatch)}
    />
  );
};

We can lazy load increment, decrement, and reset using dynamic import in JavaScript, which would mean shipping a smaller amount of first-load JavaScript to our users, and making things faster for them: a UI can render closer to instant, and then immediately become interactive via our context modules shortly after. This is a powerful pattern that can be used to build a large application while shipping a smaller amount of code.

Review Questions

Let’s make sure you’ve fully grasped the topics we covered. Take a moment to answer the following questions:

1. What is JSX?
2. What are some pros and cons of JSX?
3. What is the difference between JSX and HTML?
4. How do programming languages work?
5. What’s the value of design patterns?

If you have trouble answering these questions, this chapter may be worth another read. If not, let’s explore the next chapter.

Pitfalls of the real DOM

The real DOM has several pitfalls that can make it difficult to build high-performance web applications. Some of these pitfalls include performance issues, cross-browser compatibility, and complexity.

<!DOCTYPE html>
<html>
  <head>
    <title>Reading offsetWidth example</title>
    <style>
      #my-div {
        width: 100px;
        height: 100px;
        background-color: red;
      }
    </style>
  </head>
  <body>
    <div id="my-div"></div>
    <script>
      var div = document.getElementById("my-div");
      console.log(div.offsetWidth);
    </script>
  </body>
</html>

<!DOCTYPE html>
<html>
  <head>
    <title>Example</title>
  </head>
  <body>
    <ul id="list">
      <li>Item 1</li>
      <li>Item 2</li>
      <li>Item 3</li>
    </ul>
  </body>
</html>

const list = document.getElementById("list");
const newItem = document.createElement("li");
newItem.textContent = "Item 4";
list.appendChild(newItem);

const list = document.getElementById("list");
const newItem = document.createElement("li");
newItem.textContent = "Item 1001";
list.appendChild(newItem);

<!DOCTYPE html>
<html>
  <head>
    <title>Example</title>
    <style>
      #list li {
        background-color: #f5f5f5;
      }
      .highlight {
        background-color: yellow;
      }
    </style>
  </head>
  <body>
    <ul id="list">
      <li>Item 1</li>
      <li>Item 2</li>
      <li>Item 3</li>
    </ul>
    <button onclick="highlight()">Highlight Item 2</button>
    <script>
      function highlight() {
        const item = document.querySelector("#list li:nth-child(2)");
        item.classList.add("highlight");
      }
    </script>
  </body>
</html>

<!-- Example of a HTML5 <canvas> element -->
<canvas id="myCanvas"></canvas>

// Example of checking for support for <canvas> in JavaScript
var canvas = document.getElementById("myCanvas");
if (canvas.getContext) {
  var ctx = canvas.getContext("2d");
  // <canvas> is supported
} else {
  // <canvas> is not supported
}

<!-- Example of an HTML button element with different styles on different browsers -->
<button id="myButton">Click me</button>

/* Example of applying different styles to a button element on different browsers */
#myButton {
  color: blue;
  background-color: white;
  border: 1px solid black;
}
/* Fix for Safari */
@media screen and (-webkit-min-device-pixel-ratio: 0) {
  #myButton {
    padding: 1px 6px;
  }
}
/* Fix for Internet Explorer */
@media screen and (min-width: 0\0) {
  #myButton {
    padding: 2px 5px;
  }
}

// Example of detecting the user's browser in JavaScript
if (navigator.userAgent.indexOf("Firefox") !== -1) {
  // Code for Firefox
} else if (navigator.userAgent.indexOf("Chrome") !== -1) {
  // Code for Chrome
} else if (navigator.userAgent.indexOf("Safari") !== -1) {
  // Code for Safari
} else if (navigator.userAgent.indexOf("Trident") !== -1) {
  // Code for Internet Explorer
}

<div id="blog-posts">
  <div class="blog-post">
    <h2 class="blog-post-title">Post 1</h2>
    <p class="blog-post-text">
      Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vivamus at nisi
      sed enim scelerisque auctor.
    </p>
    <button class="expand-button">Expand</button>
  </div>
  <div class="blog-post">
    <h2 class="blog-post-title">Post 2</h2>
    <p class="blog-post-text">
      Morbi at neque ut metus malesuada tempus. Duis vel volutpat libero, id
      congue mauris. Donec sit amet ornare eros.
    </p>
    <button class="expand-button">Expand</button>
  </div>
  <!-- More blog posts... -->
</div>

const blogPosts = document.querySelectorAll(".blog-post");

blogPosts.forEach((blogPost) => {
  const expandButton = blogPost.querySelector(".expand-button");
  const blogPostText = blogPost.querySelector(".blog-post-text");

  let isExpanded = false;

  expandButton.addEventListener("click", () => {
    if (isExpanded) {
      blogPostText.style.display = "none";
      expandButton.textContent = "Expand";
      isExpanded = false;
    } else {
      blogPostText.style.display = "block";
      expandButton.textContent = "Collapse";
      isExpanded = true;
    }
  });
});