React 17 Design Patterns and Best Practices

Taking Your First Steps with React

Hello, readers!

This book assumes that you already know what React is and what problems it can solve for you. You may have written a small/medium application with React, and you want to improve your skills and answer all of your open questions. You should know that React is maintained by the developers at Facebook and hundreds of contributors within the JavaScript community. React is one of the most popular libraries for creating UIs, and it is well known to be fast, thanks to its smart way of working with the Document Object Model (DOM). It comes with JSX, a new syntax for writing markup in JavaScript, which requires you to change your thinking regarding the separation of concerns. It has many cool features, such as server-side rendering, which gives you the power to write universal applications.

In this first chapter, we will go through some basic concepts that are essential to master in order to use React effectively, but are straightforward enough for beginners to figure out:

The difference between imperative and declarative programming
React components and their instances, and how React uses elements to control the UI flow
How React changed the way we build web applications, enforcing a different new concept of separation of concerns, and the reasons behind its unpopular design choice
Why people feel JavaScript fatigue, and what you can do to avoid the most common errors developers make when approaching the React ecosystem
How TypeScript changed the game

Differentiating between declarative and imperative programming

When reading the React documentation or blog posts about React, you will have undoubtedly come across the term declarative. One of the reasons why React is so powerful is that it enforces a declarative programming paradigm.

Therefore, to master React, it is essential to understand what declarative programming means and what the main differences between imperative and declarative programming are. The easiest way to approach this is to think about imperative programming as a way of describing how things work, and declarative programming as a way of describing what you want to achieve.

Entering a bar for a beer is a real-life example in the imperative world, where normally you will give the following instructions to the bartender:

Find a glass and collect it from the shelf.
Place the glass under the tap.
Pull down the handle until the glass is full.
Hand me the glass.

In the declarative world, you would just say "Can I have a beer, please?"

The declarative approach assumes that the bartender already knows how to serve a beer, an important aspect of the way declarative programming works.

Let's move into a JavaScript example. Here we will write a simple function that, given an array of lowercase strings, returns an array with the same strings in uppercase:

toUpperCase(['foo', 'bar']) // ['FOO', 'BAR']

An imperative function to solve the problem would be implemented as follows:

const toUpperCase = input => { 
  const output = []
   
  for (let i = 0; i < input.length; i++) { 
    output.push(input[i].toUpperCase())
  } 
    
  return output
}

First of all, an empty array to contain the result is created. Then, the function loops through all the elements of the input array and pushes the uppercase values into the empty array. Finally, the output array is returned.

A declarative solution would be as follows:

const toUpperCase = input => input.map(value => value.toUpperCase())

The items of the input array are passed to a map function that returns a new array containing the uppercase values. There are some significant differences to note: the former example is less elegant and it requires more effort to be understood. The latter is terser and easier to read, which makes a huge difference in big code bases, where maintainability is crucial.

Another aspect worth mentioning is that in the declarative example, there is no need to use variables, nor to keep their values updated during the execution. Declarative programming tends to avoid creating and mutating a state.

As a final example, let's see what it means for React to be declarative. The problem we will try to solve is a common task in web development: creating a toggle button.

Imagine a simple UI component such as a toggle button. When you click it, it turns green (on) if it was previously gray (off), and switches to gray (off) if it was previously green (on).

The imperative way of doing this would be as follows:

const toggleButton = document.querySelector('#toggle')

toogleButton.addEventListener('click', () => {
  if (toggleButton.classList.contains('on')) {
    toggleButton.classList.remove('on')
    toggleButton.classList.add('off')
  } else {
    toggleButton.classList.remove('off')
    toggleButton.classList.add('on')
  }
})

It is imperative because of all the instructions needed to change the classes. In contrast, the declarative approach using React would be as follows:

// To turn on the Toggle
<Toggle on />

// To turn off the toggle
<Toggle />

In declarative programming, developers only describe what they want to achieve, and there's no need to list all the steps to make it work. The fact that React offers a declarative approach makes it easy to use, and consequently, the resulting code is simple, which often leads to fewer bugs and more maintainability.

In the next section, you will learn how React elements work and you will get more context on how props are being passed on a React component.

How React elements work

This book assumes that you are familiar with components and their instances, but there is another object you should know about if you want to use React effectively – the element.

Whenever you call createClass, extend Component, or declare a stateless function, you are creating a component. React manages all the instances of your components at runtime, and there can be more than one instance of the same component in memory at a given point in time.

As mentioned previously, React follows a declarative paradigm, and there's no need to tell it how to interact with the DOM; you declare what you want to see on the screen, and React does the job for you.

As you might have already experienced, most other UI libraries work the other way round: they leave the responsibility of keeping the interface updated to the developer, who has to manage the creation and destruction of the DOM elements manually.

To control the UI flow, React uses a particular type of object, called an element, which describes what has to be shown on the screen. These immutable objects are much simpler compared to the components and their instances and contain only the information that is strictly needed to represent the interface.

The following is an example of an element:

  { 
    type: Title, 
    props: { 
      color: 'red', 
      children: 'Hello, Title!' 
    } 
  }

Elements have type, which is the most important attribute, and some properties. There is also a particular property, called children, that is optional and represents the direct descendant of the element.

type is important because it tells React how to deal with the element itself. If type is a string, the element represents a DOM node, while if type is a function, the element is a component.

DOM elements and components can be nested with each other as follows, to represent the render tree:

  { 
    type: Title, 
    props: { 
      color: 'red', 
      children: { 
        type: 'h1', 
        props: { 
          children: 'Hello, H1!' 
        } 
      } 
    } 
  }

When the type of the element is a function, React calls the function, passing props to get back the underlying elements. It keeps on performing the same operation recursively on the result until it gets a tree of DOM nodes that React can render on the screen. This process is called reconciliation, and it is used by both React DOM and React Native to create the UIs of their respective platforms.

React is a game-changer, so at the beginning, the React syntax might seem weird to you, but once you understand how it works, you will love it, and for this, you need to unlearn everything you know so far.

Understanding JavaScript fatigue

There is a prevailing opinion that React consists of a vast set of technologies and tools, and if you want to use it, you are forced to deal with package managers, transpilers, module bundlers, and an infinite list of different libraries. This idea is so widespread and shared among people that it has been clearly defined, and has been given the name JavaScript fatigue.

It is not hard to understand the reasons behind this. All the repositories and libraries in the React ecosystem are made using shiny new technologies, the latest version of JavaScript, and the most advanced techniques and paradigms.

Moreover, there is a massive number of React boilerplate on GitHub, each with tens of dependencies to offer solutions for any problems. It is straightforward to think that all these tools are required to start using React, but this is far from the truth. Despite this common way of thinking, React is a pretty tiny library, and it can be used inside any page (or even inside JSFiddle) in the same way everyone used to use jQuery or Backbone, just by including the script on the page before the closing body element.

There are two scripts because React is split into two packages:

react: Implements the core features of the library
react-dom: Contains all the browser-related features

The reason behind this is that the core package is used to support different targets, such as React DOM in browsers and React Native on mobile devices. Running a React application inside a single HTML page does not require any package manager or complex operation. You can just download the distribution bundle and host it yourself (or use https://unpkg.com/), and you are ready to get started with React and its features in a few minutes.

Here are the URLs to be included in the HTML to start using React:

If we add the core React library only, we cannot use JSX because it is not a standard language supported by the browser; but the whole point is to start with the bare minimum set of features and add more functionalities as soon as they are needed. For a simple UI, we could just use createElement (_jsx on React 17) and only when we start building something more complex can we include a transpiler to enable JSX and convert it into JavaScript. As soon as the app grows a bit more, we may need a router to handle different pages and views, and we can include that as well.

At some point, we may want to load data from some API endpoints, and if the application keeps growing, we will reach the point where we need some external dependencies to abstract complex operations. Only at that very moment should we introduce a package manager. Then, the time will come to split our application into separate modules and organize our files in the right way. At that point, we should start thinking about using a module bundler.

Following this simple approach, there's no fatigue. Starting with a boilerplate that has 100 dependencies and tens of npm packages of which we know nothing is the best way to get lost. It is important to note that every programming-related job (and frontend engineering in particular) requires continuous learning. It is the nature of the web to evolve at a breakneck pace and change according to the needs of both users and developers. This is the way our environment has worked since the beginning and is what makes it very exciting.

As we gain experience working on the web, we learn that we cannot master everything and we should find the right way to keep ourselves updated to avoid fatigue. We are able to follow all the new trends without jumping into the new libraries for the sake of it unless we have time for a side project.

It is astonishing how, in the JavaScript world, as soon as a specification is announced or drafted, someone in the community implements it as a transpiler plugin or a polyfill, letting everyone else play with it while the browser vendors agree and start supporting it.

This is something that makes JavaScript and the browser a completely different environment compared to any other language or platform. The downside of it is that things change quickly, but it is just a matter of finding the right balance between betting on new technologies versus staying safe.

In any case, Facebook developers care a lot about the Developer Experience (DX), and they listen carefully to the community. So, even if it is not true that to use React we are required to learn hundreds of different tools, they realized that people were feeling the fatigue and they released a CLI tool that makes it incredibly easy to scaffold and run a real React application.

The only requirement is to use a node.js/npm environment and install the CLI tool globally as follows:

npm install -g create-react-app

When the executable is installed, we can use it to create our application, passing a folder name:

create-react-app hello-world --template typescript

Finally, we move into the folder of our application with cd hello-world, and we just run the following command:

npm start

Magically, our application is running with a single dependency, but with all the features needed to build a complete React application using the most advanced techniques. The following screenshot shows the default page of an application created with create-react-app:

This is basically your first React application.

Introducing TypeScript

TypeScript is a typed superset of JavaScript that is compiled to JavaScript, which means TypeScript is JavaScript with some additional features. TypeScript was designed by Anders Hejlsberg (the designer of C#) at Microsoft and is open source.

Let's see what the features of TypeScript are and how to convert JavaScript to TypeScript.

TypeScript features

This section will try to summarize the most important features you should be taking advantage of:

TypeScript is JavaScript: Any JavaScript code you write will work with TypeScript, which means if you already know how to use JavaScript basically you have all you need to do TypeScript; you just need to learn how to add types to your code. All the TypeScript code is transformed into JavaScript at the end.
JavaScript is TypeScript: This just means that you can rename any valid .js file with the .ts extension, and it will work.
Error checking: TypeScript compiles the code and checks for errors, which helps a lot to highlight errors before we run our code.
Strong typing: By default, JavaScript is not strongly typed. With TypeScript, you can add types to all your variables and functions, and you can even specify the returned value types.
Object-oriented programming supported: It supports concepts such as classes, interfaces, inheritance, and so on.

Converting JavaScript code into TypeScript

In this section, we will see how to transform some JavaScript code into TypeScript.

Let's suppose we have to check whether a word is a palindrome. The JavaScript code for this algorithm will be as follows:

function isPalindrome(word) {
  const lowerCaseWord = word.toLowerCase()
  const reversedWord = lowerCaseWord.split('').reverse().join('')

  return lowerCaseWord === reversedWord
}

You can name this file palindrome.ts.

As you can see, we are receiving a string variable (word), and we are returning a boolean value, so how will this be translated to TypeScript?

function isPalindrome(word: string): boolean {
  const lowerCaseWord = word.toLowerCase()
  const reversedWord = lowerCaseWord.split('').reverse().join('')

  return lowerCaseWord === reversedWord
}

You're probably thinking great, I just specified the string type as word and boolean type to the function returned value, but now what?

If you try to run the function with some value that is different from a string, you will get a TypeScript error:

console.log(isPalindrome('Level')) // true
console.log(isPalindrome('Anna')) // true
console.log(isPalindrome('Carlos')) // false
console.log(isPalindrome(101)) // TS Error
console.log(isPalindrome(true)) // TS Error
console.log(isPalindrome(false)) // TS Error

So, if you try to pass a number to the function, you will get the following error:

That's why TypeScript is very useful because it will force you to be more strict and explicit with your code.

Types

In the last example, we saw how to specify some primitive types for our function parameter and returned value, but you're probably wondering how you can describe an object or array with more details. Types can help us to describe our objects or arrays in a better way. For example, let's suppose you want to describe a User type to save the information into the database:

type User = {
  username: string
  email: string
  name: string
  age: number
  website: string
  active: boolean
}

const user: User = {
  username: 'czantany',
  email: 'carlos@milkzoft.com',
  name: 'Carlos Santana',
  age: 33,
  website: 'http://www.js.education',
  active: true
}

// Let's suppose you will insert this data using Sequelize...
models.User.create({ ...user }}

We get the following error if you forget to add one of the nodes or put an invalid value in one of them:

If you need optional nodes, you can always put a ? next to the name of the node, as shown in the following code block:

type User = {
  username: string
  email: string
  name: string
  age?: number
  website: string
  active: boolean
}

You can name type as you want, but a good practice to follow is to add a prefix of T, so, for example, the User type will become TUser. In this way, you can quickly recognize that it is type and you don't get confused thinking it is a class or a React component.

Interfaces

Interfaces are very similar to types and sometimes developers don't know the differences between them. Interfaces can be used to describe the shape of an object or function signature just like types, but the syntax is different:

interface User {
  username: string
  email: string
  name: string
  age?: number
  website: string
  active: boolean
}

You can name an interface as you want, but a good practice to follow is to add a prefix of I, so, for example, the User interface will become IUser. In this way, you can quickly recognize that it is an interface and you don't get confused thinking it is a class or a React component.

An interface can also be extended, implemented, and merged.

Extending

An interface or type can also be extended, but again the syntax will differ, as shown in the following code block:

// Extending an interface
interface IWork {
  company: string
  position: string
}

interface IPerson extends IWork {
  name: string
  age: number
}

// Extending a type
type TWork = {
  company: string
  position: string
}

type TPerson = TWork & {
  name: string
  age: number
}

// Extending an interface into a type
interface IWork {
  company: string
  position: string
}

type TPerson = IWork & {
  name: string
  age: number
}

As you can see, by using the & character, you can extend a type, while you extend an interface using the extends keyword.

Implementing

A class can implement an interface or type alias in the same exact way. But it cannot implement (or extend) a type alias that names a union type, for example:

// Implementing an interface
interface IWork {
  company: string
  position: string
}

class Person implements IWork {
  name: 'Carlos'
  age: 33
}

// Implementing a type
type TWork = {
  company: string
  position: string
}

class Person2 implements TWork {
  name: 'Cristina'
  age: 32
}

// You can't implement a union type
type TWork2 = { company: string; position: string } | { name: string; age: number } 

class Person3 implements TWork2 {
  company: 'Google'
  position: 'Senior Software Engineer'
}

If you write that code, you will get the following error in your editor:

As you can see, you are not able to implement a union type.

Declaration merging

Unlike a type, an interface can be defined multiple times and will be treated as a single interface (all declarations will be merged), as shown in the following code block:

interface IUser {
  username: string
  email: string
  name: string
  age?: number
  website: string
  active: boolean
}

interface IUser {
  country: string
}

const user: IUser = {
  username: 'czantany',
  email: 'carlos@milkzoft.com',
  name: 'Carlos Santana',
  country: 'Mexico',
  age: 33,
  website: 'http://www.js.education',
  active: true
}

This is very useful when you need to extend your interfaces in different scenarios by just re-defining the same interface.

Filter reviews by

All

Packt verified reviews

Amazon verified reviews

Cristina Elizabeth Rojas Zamora May 26, 2021

I just got it a few days ago and is has been very good so far, I already know React and this book is giving me a lot of new information like the new React Hooks, how to implement GraphQL or the new React Suspense.Totally recommended.

Amazon Verified review

ryan diaz Feb 28, 2022

I bought this book to prepare for a SWE role that used a lot of React. I used React in the past but was coming from a Vue Shop. This book was able to get me in the proper mindset for React and gave an abundance of patterns to use that I’ve used in real projects. If you’re looking to enhance your React skills and add timeless React patterns to your arsenal - this is the book.

Joe Sep 22, 2021

You need to have a good experience in React then only you should go for this book. It is not for immediate beginners or even intermediate players. Covers a vast variety of topics and get to grips with the new React Suspense technique and GraphQL

Mark Dunn Jul 02, 2021

I've used React on several projects and I learned some new things from this book. It was nice to review TypeScript. React Hooks and GraphQL are both new to me. I like this author's writing style as I found this book easy to read. I also very much appreciate the coverage of best practices and design patterns. This book will serve well as a reference and it thoroughly covers the topic of React.

Stephan Miller Jun 04, 2021

This book was especially helpful to learn the changes in React that have happened over the last two versions. I was still using class-based components up to last year. While I had started using function-based components, I didn't know everything I could do with them until reading this book. While project-based books will show you how to build a complete application, sometimes functionality is left out when it is not needed for the example app. This book helped me understand what React hooks were actually doing, how to use GraphQL, and had a lot of information on best practices and patterns to use in Development. I recommend it for anyone who has done a little React development and wants a better understanding of the framework and how to use it.

React 17 Design Patterns and Best Practices: Design, build, and deploy production-ready web applications using industry-standard practices , Third Edition

What do you get with Print?

React 17 Design Patterns and Best Practices

Technical requirements

Differentiating between declarative and imperative programming

How React elements work

Unlearning everything

Understanding JavaScript fatigue

Introducing TypeScript

TypeScript features

Converting JavaScript code into TypeScript

Types

Interfaces

Extending

Implementing

Declaration merging

Summary

Page 1 of 8

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs

React 17 Design Patterns and Best Practices: Design, build, and deploy production-ready web applications using industry-standard practices , Third Edition

What do you get with Print?

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs