Course overview

How to work with course materials

Introduction

Setting up Developer Environment

Setting up Initial Project

How to Use ESLint and Prettier Together in a React Project

How to Configure React to Use TypeScript

How to Add Jest to a React Project for Automated Testing

Setting up developer environment

Building React Hooks: API Considerations and Best Practices

How to Implement a Custom useBoolean React Hook

Testing a Custom useBoolean Hook With React Testing Library

How to Implement a Custom useMap Hook With Tests

How to Quickly Import Custom React Hooks With an Index File

Implement an Object Returning API With a react-hanger Clone

Development of custom hooks

CommonJS vs ES6: An Intro to JavaScript Module Systems

What is Transpilation? An Intro to Transpilers vs Compilers

An Intro to Transpilers: ESBuild, Babel, and SWC Compared

What are Babel Transforms and Plugins?

A Beginner's Guide to JavaScript Bundlers

How to Simplify Bundling React Code With Microbundle

How to Add TypeScript Build Steps to React

How to Implement Babel Build Steps in a React App

Conclusion

Preparing code for publishing

Add Continuous Integration to a React Build With GitHub Actions

How to Automatically Generate a React App Changelog

How to Publish a React Library to NPM With GitHub Actions

Publishing the Code

In this course we’ll build a set of custom reusable hooks, a mini react-hanger clone, essentially going from nothing to a fully-automated publishing pipeline that follows the best practices.  We will cover common Hooks APIs every React developer should know, then dive straight into implementing Custom React Hooks, similar to what you will find in leading React libraries in the open source React ecosystem.

## Why this course
React Hooks promise to eliminate the difficulties of sharing state without writing class-based components. The challenge is that Hooks do away with the lifecycle methods and class-based semantics of state management that many React developers were familiar with.  Learning React Hooks on your own can be time consuming, confusing and frustrating.  With that in mind, The newline Guide to Creating a React Hooks Library, was created to provide a complete tutorial that fully covers React Hooks.  Within a few hours you'll have a strong grasp on React Hooks and how to implement them.

## Course Topics
This course packs practical hands-on-instruction using and building React Hooks, along with the best practices you need to build wider React Hooks libraries others across your organization can use.
The first module provides an overview of the React Hooks library project we’ll build, and we'll set up a complete environment with tools for library development.
The subsequent modules then take you through building with React Hooks and creating your React Hooks library, including:
- Hooks API fundamentals
- Developing custom React Hooks
- How to write reusable React Hooks
- Common React Hooks mistakes to avoid in your code
- Transpilers and bundlers for JavaScript libraries
- Using GitHub Actions to test, build, and lint your library
- Publish your React Hooks library to NPM

We’ll use tools including React, TypeScript, Babel, as well as GitHub Actions to build, test, and package a React Hooks library available for others to download from NPM.  Ultimately, build your own React Hooks library and learn the best practices that will make your code reusable. With these skills, you can contribute more confidently to any React codebase using React Hooks, and make your team more productive.

This course is a complete step-by-step guide to coding custom React Hooks and building a Hooks library from scratch.  Confidently master React Hooks, a transformative update added since React version 16.8, that makes it much easier to reuse code as your React codebase grows.

The newline Guide to Creating a React Hooks Library

Common React Hooks mistakes to avoid in your code

Transpilers and bundlers for JavaScript libraries

Using GitHub Actions to test, build, and lint your library

When you develop your modern web app, you usually use tools like Parcel or Webpack. These are 

. They take all your modular and human-readable code and transform it into a single file or "bundle". They also make sure that all the other resources for your web app like CSS, images, fonts etc are collected into one folder.
Few other bundlers that are getting popularity that are focused on performance and developer experience are ESBuild, Vite and Snowpack. Some are 100% written from scratch not borrowing anything from anyone like ESBuild. Another like Vite and Snowpack are wrappers around SWC, Babel, ESBuild and other standalone tools to achieve better DX by giving an instant feedback loop between code changes in the contrary to Rollup/Webpack which usually take few seconds or minutes for rebuild, especially on the first run, surely depending on the size of the codebase they process.

For development, bundling usually done without any optimizations, so it's quickly ready to test, but in production it has to be done in a slow and highly-optimized way. Typical optimizations are:

Imagine you're using a library of helper functions, let say 

 but the problem is that people mostly use less than ten of its dozens of functions. Without a tree-shaking optimization, if you imported, for example, the 

 will be taken along and end up in your bundle, even though you only need 

. Tree-shaking will check what functions, classes, or constants are used and then takes only those into the bundle. So instead of the whole of 

 weighing 66.9 kilobytes, you will only import around 4 kilobytes. You can check if the library that you use is shakable by using services like Bundlephobia.com.

You might wonder why bundle size is so important.

First of all, not all connections are equal, so if you're sitting somewhere in Europe, say Poland or Ukraine, you can expect super-stable half gigabit cable connection at home or in the office. But, if we look at the cellular connection in these two countries, only three or four years ago, Ukraine had only 2G or so-called EDGE connection, whilst Poland has already been enjoying 4G for a few years. So your average user in Poland will download 

 within 5ms, but the average user on the streets of Kyiv will wait for whole second for it to download. Now imagine adding on top of it React, a few libraries, helpers, CSS-in-JS library or whatever, and you could quickly end up with a megabyte of gzipped JavaScript.

---
title: A Beginner's Guide to JavaScript Bundlers
isPublicLesson: false
---

When you develop your modern web app, you usually use tools like Parcel or Webpack. These are **bundlers**. They take all your modular and human-readable code and transform it into a single file or "bundle". They also make sure that all the other resources for your web app like CSS, images, fonts etc are collected into one folder.
Few other bundlers that are getting popularity that are focused on performance and developer experience are ESBuild, Vite and Snowpack. Some are 100% written from scratch not borrowing anything from anyone like ESBuild. Another like Vite and Snowpack are wrappers around SWC, Babel, ESBuild and other standalone tools to achieve better DX by giving an instant feedback loop between code changes in the contrary to Rollup/Webpack which usually take few seconds or minutes for rebuild, especially on the first run, surely depending on the size of the codebase they process.

For development, bundling usually done without any optimizations, so it's quickly ready to test, but in production it has to be done in a slow and highly-optimized way. Typical optimizations are:

-   **Minification** - this means all your code will be on the same line, without any spaces. All variable and function names will be replaced with super-short names, as will many other things that can take less characters without changing the logic of the code.
-   **Dead code elimination** - this means the removal of code that's never going to run no matter what you do. For example, you may have a useless `if` statement that is always `true`, with a `return` statement. All code below it will never run. This code would be identified as useless and deleted.
-   **Code splitting** - this is where you send only the small chunk of code needed to render your first page, and for any other page, additional code will be downloaded on demand.
-   **Tree-shaking** - this is almost the same thing as dead code elimination, but is based on modules and usage of these modules and their exports. In other words tree shaking is the process of removing unused code from your bundle, but a bit more sophisticated than "Dead code elimination".

Imagine you're using a library of helper functions, let say `lodash`. Everyone loves `lodash` but the problem is that people mostly use less than ten of its dozens of functions. Without a tree-shaking optimization, if you imported, for example, the `merge` function like this: `import { merge } from 'lodash'`, all of the functions available in `lodash` will be taken along and end up in your bundle, even though you only need `merge`. Tree-shaking will check what functions, classes, or constants are used and then takes only those into the bundle. So instead of the whole of `lodash` weighing 66.9 kilobytes, you will only import around 4 kilobytes. You can check if the library that you use is shakable by using services like Bundlephobia.com.