A few years ago, I was introduced to React and immediately fell in love with its component-based, state-driven approach to building web applications.

But as I delved deeper into its ecosystem, I encountered not just React, but a range of supporting libraries like Material UI, React Router, Reactstrap, Redux, and more. While exciting, these new concepts and libraries could also feel overwhelming.

I soon realized that mastering React requires a solid understanding of modern JavaScript, especially the ES6+ features. This realization encouraged me to revisit some fundamental JavaScript topics, which helped me become more comfortable with React and write cleaner, more efficient code.

In this guide, I will share my notes as a concise and practical reference. These key JavaScript concepts will give you a strong foundation before you dive deep into React. Whether you’re a beginner or revisiting the language, this guide should give you a boost as you tackle the React ecosystem.

Let’s Get Back to Work

Since React is based on JavaScript, it’s essential to have a good grasp of the language before you start learning React.

I recommend a comprehensive resource like The Modern JavaScript Tutorial for an in-depth review. But if you feel confident about most of JavaScript and just need a brush-up, here’s my recommended list of crucial topics:

1. Template Literals

2. Arrow Functions

3. Default Parameters (or Values)

4. Destructuring Objects and Arrays

5. Rest and Spread Operators

6. Map, Filter, and Reduce Methods

7. Mutability Issues with Methods like Array Sort

8. Ternary Operator

9. Short-Circuiting and Logical Operators

10. Optional Chaining

11. Asynchronous JS (Callbacks, Promises, Async/Await)

12. Closures

13. Modules (import/export)

14. Event Handling and Bubbling

15. Classes and Prototypes

1. Template Literals

Template literals simplify string interpolation and multiline text formatting. By using backticks (`___` ), you can embed expressions into strings with ${}. This makes concatenating variables and expressions with text easy, eliminating the need for cumbersome string concatenation.

let numEggs = 4;

console.log(`In breakfast, I eat ${numEggs} eggs.`);
//Output: In breakfast, I eat 4 eggs.

console.log(`Today, I ate only half of it, I ate just ${numEggs/2} eggs.`);
//Output: Today I ate only half of it, I ate just 2 eggs.

Additionally, template literals support multiline strings (without needing the newline character, that is \n, and also you can add spaces). This lets developers create more readable and organized code.

console.log(`Today I had:
- Breakfast
- Lunch
- Dinner`);
/* Output (now shows multiline text as shown below): 
Today I had:
- Breakfast
- Lunch
- Dinner
*/

With their flexibility and clarity, template literals have become a preferred method for handling strings and dynamic content in modern JavaScript.

2. Arrow Functions

Arrow functions provide a more concise syntax for writing functions and automatically bind this to the context in which they're declared. They are a staple of React development, as they simplify event handlers, lifecycle methods, and other functional logic. Let’s explore different variations of arrow functions.

Arrow Function with a Single Argument: When an arrow function has a single argument, you can omit the parentheses. Here’s an example:

const greet = name => `Hello, ${name}!`;
console.log(greet('John')); // Hello, John!

Arrow Function without Arguments: If there are no arguments, you still need to use parentheses.

const sayHello = () => 'Hello, world!';
console.log(sayHello()); // Hello, world!

Arrow Function with Multiple Arguments: For multiple arguments, parentheses are mandatory.

const add = (a, b) => a + b;
console.log(add(2, 3)); // 5

Single-Line Function Body (Implicit Return): When the function body is a single expression, you can omit the return keyword and curly braces. This is known as an implicit return.

const multiply = (x, y) => x * y;
console.log(multiply(4, 5)); // 20

Multi-Line Function Body: For more complex logic or multiple statements, you need curly braces, and an explicit return is required if the function returns a value.

const getFullName = (firstName, lastName) => {
  const fullName = `${firstName} ${lastName}`;
  return fullName;
};
console.log(getFullName('John', 'Doe')); // John Doe

Returning an Object: To return an object directly, wrap the object in parentheses to avoid confusion with the function body.

const createUser = (name, age) => ({ name, age });
console.log(createUser('Alice', 30)); // { name: 'Alice', age: 30 }

Arrow Functions in Callbacks: Arrow functions are often used as callbacks for array methods like map, filter, and reduce.

const numbers = [1, 2, 3, 4];
const squares = numbers.map(num => num * num);
console.log(squares); // [1, 4, 9, 16]

To learn more about how arrow functions compare with other ways to define functions, you may read this blog on ways to write JS functions.

3. Default Parameters (or Values)

Default parameters allow functions to have pre-set values if no arguments are passed, or when an argument is undefined. This feature is helpful when writing flexible components in React, where you may not always pass every prop or argument.

function greet(name = 'Stranger') {
  console.log(`Hello, ${name}!`);
}
greet(); // Hello, Stranger!
greet('Alice'); // Hello, Alice!

It is relevant to mention here that there’s another commonly used approach in JavaScript, which is leveraging logical operators like || to set a default value when the given value is falsy (that is, values like 0, null, undefined, false, or "").

function greet(name) {
  const finalName = name || 'Stranger';
  console.log(`Hello, ${finalName}!`);
}

greet(); // Hello, Stranger!
greet(''); // Hello, Stranger!
greet('John'); // Hello, John!

The above process uses a concept called short-circuiting of logical operators, which is discussed in Section 9 below.

4. Destructuring Objects and Arrays

Destructuring allows you to extract values from arrays and properties from objects into variables. This concise syntax makes your code cleaner and more readable.

To extract specific values from an array or object, use destructuring by enclosing the desired variables within curly braces for objects or square brackets for arrays.

// Example of Array Destructuring
const [first, second] = [10, 20];
console.log(first); // 10

// Example of Object Destructuring
const user = { name: 'Alice', age: 25 };
const { name, age } = user;
console.log(name); // Alice

Destructuring is commonly used in React for handling props and state. To see more specific use cases of destructuring with code examples, read this quick reference on destructuring.

5. Rest and Spread Operators

The rest and spread operators are incredibly versatile and widely used in JavaScript. Both are represented by three dots (...), but their meanings differ depending on the context in which they are used.

Spread Operator: Expands elements of an array or object.

The spread operator is primarily used to unpack arrays or objects into individual elements. This is especially useful for creating shallow copies or merging arrays (and objects) without mutating the original.

const arr1 = [1, 2, 3];
const arr2 = [...arr1, 4, 5];
console.log(arr2); // [1, 2, 3, 4, 5]

/* arr2 is created by spreading the elements of arr1 
 and then adding additional values */

The spread operator can also be used to copy objects or combine objects:

const obj1 = { name: 'Alice', age: 25 };
const obj2 = { ...obj1, job: 'Engineer' };
console.log(obj2); // { name: 'Alice', age: 25, job: 'Engineer' }

/* obj2 is created by spreading the properties of obj1
 and adding a new property */

This is a common pattern when updating the state in React applications.

Rest Operator: Collects multiple elements into an array.

The rest operator does the reverse: it collects multiple arguments or elements into a single array. It’s especially useful when working with variadic functions (functions that accept a variable number of arguments).

function sum(...args) {
  return args.reduce((total, num) => total + num, 0);
}
console.log(sum(1, 2, 3)); // 6

In this example, ...args gathers all arguments passed to the function into an array. This allows the function to handle any number of arguments dynamically.

You can also use the rest operator to collect remaining properties of an object or elements of an array:

const [first, ...rest] = [10, 20, 30, 40];
console.log(first); // 10
console.log(rest);  // [20, 30, 40]

This technique is particularly useful in React when working with props, where you might want to extract specific properties and pass the rest down to child components.

6. Map, Filter, and Reduce Methods

The map(), filter(), and reduce() methods are incredibly powerful for array manipulation in JavaScript, and they play a crucial role in React for tasks like rendering lists, filtering data, and summarizing information.

• Map: Transforms elements of an array

• Filter: Creates a new array with elements that pass a condition

• Reduce: Accumulates values into a single result

1. Map Method

The map() method creates a new array by transforming each element of the original array according to the function provided. This method is essential in React for dynamically rendering lists of components from arrays of data.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4];
const doubled = numbers.map(num => num * 2);
console.log(doubled); // [2, 4, 6, 8]

In React, map() is commonly used to render lists of components. Here's how you might use it in a React component:

// Example (Rendering a List in React):
const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' },
  { id: 3, name: 'Charlie' }
];

function UserList() {
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

/* Note that each <li> element in the list has a unique 'key' prop.
It is required by React when rendering lists like this */

2. Filter Method

The filter() method creates a new array with all elements that pass the condition specified in the callback function. It's frequently used in React when you want to display only certain items based on user input or a specific condition.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4, 5];
const evenNumbers = numbers.filter(num => num % 2 === 0);
console.log(evenNumbers); // [2, 4]

For a use case, imagine you have a list where some tasks are completed while some are not. So, you can use filter() to display (render) only the tasks that are not yet completed.

// Example (Filtering Data in React):
const todos = [
  { id: 1, task: 'Learn JavaScript', completed: true },
  { id: 2, task: 'Learn React', completed: false },
  { id: 3, task: 'Build a project', completed: false }
];

function TodoList() {
  const incompleteTodos = todos.filter(todo => !todo.completed);
  return (
    <ul>
      {incompleteTodos.map(todo => (
        <li key={todo.id}>{todo.task}</li>
      ))}
    </ul>
  );
}

3. Reduce Method

The reduce() method executes a reducer function on each element of the array, resulting in a single output value. It's used when you need to accumulate data, such as summing values or combining objects.

// Example (Basic Usage):
const numbers = [1, 2, 3, 4];
const sum = numbers.reduce((total, num) => total + num, 0);
console.log(sum); // 10

You might use reduce() in React to calculate a summary of some data, like the total price of items in a shopping cart — considering the items’ individual price and quantities:

// Example (Using reduce() in React):
const cart = [
  { id: 1, name: 'Apple', price: 1.5, quantity: 3 },
  { id: 2, name: 'Banana', price: 1, quantity: 2 },
  { id: 3, name: 'Orange', price: 2, quantity: 1 }
];

function CartSummary() {
  const total=cart.reduce((sum, item)=>sum + item.price * item.quantity, 0);
  return (
    <div>
      <h3>Total: ${total}</h3>
    </div>
  );
}

These array methods are invaluable in React for manipulating and displaying data dynamically. They allow for clean, readable, and declarative logic within your components.

You can also combine these methods to create powerful data transformations. For example, you can filter an array and then map the results: filter() is used to extract only the adult users, and map() is then used to create a list of their names.

// Example: combined use of filter and map methods
const users = [
  { id: 1, name: 'Alice', age: 25 },
  { id: 2, name: 'Bob', age: 17 },
  { id: 3, name: 'Charlie', age: 30 }
];

const adultNames = users
  .filter(user => user.age >= 18)
  .map(user => user.name);
console.log(adultNames); // ['Alice', 'Charlie']

The map() and filter() methods are easier to grasp because they follow a simple "one-to-one" or "one-to-zero-or-more" relationship: map() transforms each element into a new one, while filter() includes or excludes elements based on a condition, returning a similarly structured array.

In contrast, reduce() is more complex, as it accumulates values into a single result rather than maintaining a one-to-one relationship. It requires managing both the current value and an accumulator, making it conceptually different and harder to interpret than map() or filter().

The optional initial value in reduce() adds to the complexity, as it sets the starting point for the accumulation. Without it, the first array element is used as the accumulator, which can cause unexpected results with empty arrays or non-numeric data. To get consistent results for your use of the reduce() method, you may read about the importance of an initial value.

7. Mutability Issues with Methods like Array Sort

The Array.sort() method sorts the elements of an array in place, meaning it mutates the original array. For example:

const numbers = [4, 2, 3, 1];
numbers.sort();
console.log(numbers); // [1, 2, 3, 4]

While this works in plain JavaScript, it’s problematic in React, where immutability is crucial for correctly managing state.

React detects state changes by comparing previous and new states and triggers re-renders based on those changes. But when an array is mutated in place (like with sort()), React may fail to recognize the change, leading to stale UI updates or unpredictable behavior.

To avoid this, it’s best to create a copy using the spread operator (...) or slice() before sorting, ensuring that the original state remains unchanged:

const numbers = [4, 2, 3, 1];
const sortedNumbers = [...numbers].sort();
console.log(sortedNumbers); // [1, 2, 3, 4]

Methods like map(), filter(), reduce(), or copying arrays/objects before modifying them is essential for preserving immutability and ensuring reliable state management in React.

8. Ternary Operator

The ternary operator is a shorthand for conditional statements. It has the syntax condition ? expressionIfTrue : expressionIfFalse. If the condition evaluates to true, it executes the expressionIfTrue. If it’s false, it executes the expressionIfFalse.

let isUserRegistered = true;
let message = isUserRegistered ? 'Please login' : 'Please Sign-up';
console.log(message);
//Output: Please login

In React, it is an efficient replacement for the if-else statements in certain scenarios — like conditional rendering, which delivers elements and components based on certain conditions or values of state or props data.

9. Short-Circuiting and Logical Operators

Logical operators like && (AND) and || (OR) can be used to create clean and concise conditional logic in JavaScript. In React, these operators often determine whether a component or JSX element should render.

1. Logical AND (&&)

The && operator evaluates the expression on the left side first. If it's true, the right-hand expression is evaluated and returned. If the left side is false, the entire expression short-circuits, meaning the right-hand expression is ignored.

let isLoggedIn = true;
console.log(isLoggedIn && 'Welcome back!'); // Welcome back!

This behavior is often used in React for conditional rendering, like so:

function UserGreeting({ isLoggedIn }) {
  return (
    <div>
      {isLoggedIn && <p>Welcome back!</p>}
    </div>
  );
}

This is a common pattern in React for rendering UI based on certain conditions without needing an explicit if statement.

2. Logical OR (||)

The || operator works in the opposite way. It evaluates the left-hand expression first, and if it's true (or any truthy value), it returns that value. If the left-hand expression is false (or any falsy value), it evaluates and returns the right-hand expression.

let username = '';
console.log(username || 'Guest'); // Output: Guest

In React, this is useful for providing default values, like so:

function UserProfile({ username }) {
  return (
    <div>
      <p>Hello, {username || 'Guest'}!</p>
    </div>
  );
}

Note that the nullish coalescing operator (??) is similar to the logical OR operator (||), but with a key difference in how they treat falsy values.

The nullish coalescing operator (??) specifically checks if the left-hand side is either null or undefined. If the value is null or undefined, it returns the right-hand side. This allows 0, false, and '' to be treated as valid values and not overridden. You can read about this and more such nuances associated with JavaScript Operators.

3. Combining && and || for Complex Logic

You can also combine && and || to create more complex conditional logic or nested logic.

let isAdmin = false;
let isLoggedIn = true;
console.log(isAdmin && 'Admin Panel' || isLoggedIn && 'User Dashboard'); 
// Output: User Dashboard

This can be useful in React for deciding what to render based on multiple conditions having an interplay.

function Dashboard({ isAdmin, isLoggedIn }) {
  return (
    <div>
      {isAdmin && <p>Welcome to the Admin Panel</p>}
      {!isAdmin && isLoggedIn && <p>Welcome to the User Dashboard</p>}
    </div>
  );
}

10. Optional Chaining

Optional chaining (?.) is a powerful feature introduced in JavaScript (ES2020) that allows you to safely access deeply nested properties of an object without worrying about encountering undefined or null errors.

In traditional JavaScript, accessing nested properties of objects could result in errors if any part of the chain was undefined or null, causing your code to break. Optional chaining provides a cleaner and safer way to handle these scenarios.

The optional chaining operator short-circuits and returns undefined if the value before it is null or undefined. This prevents the code from throwing an error when trying to access the properties of a null or undefined value.

let user = { name: 'Alice', address: { city: 'Wonderland' } };
console.log(user?.address?.city); 
// Output: Wonderland

// Without optional chaining
let user1 = { name: 'Bill' };
console.log(user1.address.city); 
// Output: Error: Cannot read property 'city' of undefined

// With Optional Chaining:
let user2 = { name: 'Caleb' };
console.log(user2?.address?.city); // undefined

Optional chaining can also be used in different scenarios, such as   with function calls (to check if a function exists before invoking it), while accessing elements in arrays (especially when you’re unsure whether the array exists or whether it has enough elements), or while accessing dynamic properties, as shown below:

// Optional Chaining with Functions:
let user1 = {
  name: 'Alice',
  greet: () => 'Hello!'
};

console.log(user1.greet?.()); // Hello!
console.log(user1.sayGoodbye?.()); // undefined

// Optional Chaining with Arrays:
let users = [{ name: 'Alice' }, { name: 'Bob' }];
console.log(users[0]?.name); // Alice
console.log(users[2]?.name); // undefined

// Optional Chaining with Dynamic Properties:
let user2 = { name: 'Bill', preferences: { theme: 'dark' } };
let property = 'preferences';
console.log(user2?.[property]?.theme); // dark

property = 'settings';
console.log(user2?.[property]?.theme); // undefined

When working with deeply nested objects, optional chaining can save you from having to write repetitive null checks at every level.

let user = { profile: { address: { city: 'Wonderland' } } };

// usage without optional chaining (using short-circuiting):
if (user && user.profile && user.profile.address && user.profile.address.city) {
  console.log(user.profile.address.city);
}

// usage with optional chaining (saving repititive null checks):
console.log(user?.profile?.address?.city); // Wonderland

In React, optional chaining is particularly useful when dealing with props, API responses, or any data that may not always be available. It helps prevent errors when rendering components based on dynamic or incomplete data.

Optional chaining significantly reduces the complexity of your code, making it cleaner and more readable, especially when dealing with deeply nested structures.

// Example usage of Optional Chaining in React
function UserProfile({ user }) {
  return (
    <div>
      <p>Name: {user?.name}</p>
      <p>City: {user?.address?.city ?? 'Unknown'}</p>
    </div>
  );
}

11. Asynchronous JS: Callbacks, Promises, Async/Await

JavaScript is a single-threaded language,  meaning  it can execute one task at a time. But handling asynchronous operations is crucial, especially for tasks like fetching data in React. Callback functions are one of the earliest patterns used to handle asynchronous behavior, like so:

function fetchData(callback) {
  setTimeout(() => {
    console.log("Data fetched");
    callback({ user: "John", age: 30 });
  }, 2000);
}

fetchData((data) => {
  console.log("User:", data.user);
});

/* Output:
Data fetched
User: John
*/

So, as you can see, callbacks are effective for handling simple operations that depend on asynchronous tasks, like the example above.

But when multiple asynchronous tasks rely on each other, callbacks can lead to deeply nested code, commonly referred to as callback hell.

To solve this problem, promises were introduced. A promise is an object that represents the eventual completion (or failure) of an asynchronous operation and its resulting value. Instead of nesting multiple callbacks, promises allow chaining, leading to more structured and readable code.

Similarly, the Fetch API, which is commonly used for handling network requests in React applications, returns a promise which you can handle like so:

function fetchUserDetails(userId) {
  return fetch(`https://api.example.com/users/${userId}`)
    .then((response) => {
      if (!response.ok) {
        throw new Error('Failed to fetch user details');
      }
      return response.json();
    })
    .then((data) => {
      console.log("Fetched user details");
      return { id: userId, name: data.name };
    });
}

function fetchPostsByUser(user) {
  return fetch(`https://api.example.com/users/${user.id}/posts`)
    .then((response) => {
      if (!response.ok) {
        throw new Error('Failed to fetch posts');
      }
      return response.json();
    })
    .then((posts) => {
      console.log(`Fetched posts for ${user.name}`);
      return posts;
    });
}

// Chain promises
fetchUserDetails(1)
  .then((user) => fetchPostsByUser(user))
  .then((posts) => console.log(posts))
  .catch((error) => console.error("Error:", error));

Promises provide a more readable way to handle sequential asynchronous tasks. They also simplify error handling using .catch(). But, while promises eliminate the deep nesting of callbacks, chaining too many .then() calls can still become verbose and hard to follow.

Introduced in ES2017, async/await makes working with promises even simpler. With async/await, asynchronous code looks and behaves more like synchronous code, which greatly improves readability. Here’s how it works:

• async function: An async function returns a promise. The async keyword allows the function to return a resolved promise implicitly.

• await expression: Inside an async function, await pauses the execution of the function until the promise resolves. It simplifies promise handling, as we can directly assign the resolved value to a variable.

async function getUserAndPosts(userId) {
  try {
    const user = await fetchUserDetails(userId); // Waits for user details
    const posts = await fetchPostsByUser(user);  // Waits for posts
    console.log("Posts:", posts);
  } catch (error) {
    console.error("Error:", error);
  }
}

getUserAndPosts(1);

/* Output:
Fetched user details
Fetched posts for John
Posts: ["Post 1", "Post 2"]
*/

Async/await makes asynchronous code appear synchronous, which greatly improves readability and maintainability. The try/catch block also simplifies error handling, making it consistent with how errors are caught in synchronous code.

Error Handling in Async Code

Error handling in asynchronous code can be tricky. Callbacks require error-first handling, while promises and async/await offer more structured approaches, as shown below:

// Handling Errors with Promises
fetchUserDetails(1)
  .then((user) => fetchPostsByUser(user))
  .then((posts) => console.log(posts))
  .catch((error) => console.error("Error fetching data:", error));

// Handling Errors with Async/Await
async function getUserAndPosts() {
  try {
    const user = await fetchUserDetails(1);
    const posts = await fetchPostsByUser(user);
    console.log(posts);
  } catch (error) {
    console.error("Error fetching data:", error);
  }
}

Understanding the evolution of asynchronous JavaScript helps you write efficient, non-blocking code. For more details, you can read this article on the evolutionary progress of Asynchronous JavaScript.

12. Closures

A closure in JavaScript is created when a function “remembers” the variables from its outer scope, even after the outer function has finished executing. This means that a function retains access to the environment it was created in, making closures essential for managing data across different contexts.

function outerFunction(outerVar) {
  return function innerFunction(innerVar) {
    console.log(`Outer: ${outerVar}, Inner: ${innerVar}`);
  };
}

const newFunction = outerFunction('React');
newFunction('JavaScript'); // Outer: React, Inner: JavaScript

In React, closures are crucial for handling state and props within functional components. They allow functions like event handlers or asynchronous callbacks to access the latest state values even after re-renders.

For example, the useState and useEffect hooks rely on closures to "remember" and manage state across renders.

function Counter() {
  const [count, setCount] = useState(0);
  const increment = () => setCount(count + 1); // Closure keeps track of count
  return <button onClick={increment}>Count: {count}</button>;
}

Understanding closures ensures that you can effectively manage state and handle events in React, keeping your components consistent and predictable.

13. Modules (import/export)

React projects are highly modular, meaning that the code is split into multiple files or components, each handling a specific responsibility. This modularity is enabled by ES6 modules, which allow you to export values, functions, or components from one file and import them into another.

Understanding how to use import and export is essential for organizing React applications and making code reusable and maintainable.

In the following example, the greet function is exported from module.js, making it accessible to other files.

// module.js
export const greet = () => console.log('Hello');

In anotherFile.js, we import the greet function from module.js and can now use it as if it were defined locally, like so:

// anotherFile.js
import { greet } from './module';
greet(); // Hello

React components are often exported from their own files and then imported into a central component (like App.js), allowing you to break down your UI into smaller, reusable pieces.

// Button.js
export default function Button() {
  return <button>Click me</button>;
}

// App.js
import Button from './Button';

Understanding this import/export structure is fundamental in React for managing components, reusing logic, and keeping code clean and modular.

Here, you may note that CommonJS was a popular module system for Node.js (server-side JavaScript) before ES6. It allowed you to export values from a file using module.exports and import them using require().

While it worked well in Node.js, it wasn't natively supported by browsers. With the rise of React and other frontend libraries, the need for a native, browser-supported and standardized module system became essential and ES6 provided that.

14. Event Handling and Bubbling

React relies heavily on event handling to respond to user interactions. Events in React are managed through Synthetic Events, which provide cross-browser consistency and performance optimization. Understanding event bubbling, a process where events propagate from the target element up through its parents, is crucial for controlling component behavior.

// Example in vanilla JavaScript:
document.querySelector("button").addEventListener("click", function() {
  console.log("Button clicked");
});

In the above example, clicking the button triggers the event listener, and the event “bubbles” up through parent elements unless stopped. React handles this similarly with its onClick events:

// Example in React:
function handleClick() {
  console.log("Button clicked");
}

function App() {
  return <button onClick={handleClick}>Click me</button>;
}

In React, event bubbling can lead to multiple event handlers being triggered in nested elements. For example, a parent’s onClick can be triggered when its child button is clicked unless it is prevented by calling event.stopPropagation() inside the child button’s handler method — which then prevents the click event from reaching the parent div. This ensures that only the desired event is handled.

// Example of How to Stop Event Bubbling:
function handleButtonClick(event) {
  event.stopPropagation(); // Prevents bubbling
  console.log("Button clicked");
}

function handleDivClick() {
  console.log("Div clicked");
}

function App() {
  return (
    <div onClick={handleDivClick}>
      <button onClick={handleButtonClick}>Click me</button>
    </div>
  );
}

React’s architecture, with its component-based structure and Synthetic Event System, reduces the need for stopPropagation() in most cases—for example, in simpler apps where both a parent and child component are not handling the same event like a click.

But in more complex UI structures, where multiple elements handle the same event (for example, onClick), and you want to prevent the parent element from reacting to the child’s event, stopPropagation() becomes crucial for controlling event flow. This is especially important in scenarios like nested modals, dropdowns, or accordions, where a click inside the modal should not trigger a click handler on the outer container.

15. Classes and Prototypes

While functional components are now dominant in React, understanding JavaScript classes and prototypes is still valuable, especially when working with class-based components or maintaining legacy code. JavaScript classes provide a blueprint for creating objects, and they work by leveraging prototypes under the hood.

class Person {
  constructor(name) {
    this.name = name;
  }  

  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
}

const person = new Person('Alice');
person.greet(); // Hello, I'm Alice

In this example, the Person class defines a constructor to initialize the name property, and a greet() method that prints a message. When you create a new instance of Person, the method is available through JavaScript’s prototype chain.

Though React moved towards functional components with hooks, class-based components were the standard prior to React 16.8. Understanding classes is useful when dealing with codebases that use class components or when you need to understand features like lifecycle methods (componentDidMount, componentDidUpdate, and so on) and this binding, which are more prevalent in class components.

Final Thoughts

Mastering the key JavaScript concepts outlined in this tutorial will give you a solid foundation as you dive into React development.

React heavily relies on modern JavaScript features like map(), filter(), destructuring, and the spread operator, all of which streamline how data is manipulated and components are rendered. And concepts like immutability, optional chaining, and the nullish coalescing operator are critical for writing clean, bug-free code that interacts effectively with dynamic data.

By understanding how these JavaScript features work together, you'll be well-equipped to write more efficient, maintainable React applications.

So, as you begin your React journey, make sure your JavaScript fundamentals are rock-solid—you'll find that it pays off as you tackle more complex challenges in your React projects. Also, if you find I missed any important concept here, please let me know. I will add it back to the article for an updated version.

So in the spirit of Leap Day, let's practice some coding to understand various aspects of programming. We'll focus on the same program but from different perspectives.

Our example program will explore different ways you can code a program that determines whether a given year is a leap year. On other days, we code. But today, let’s decode what we do and get some extra knowledge out of that process.

Table of Contents

• Program Requirements & Prerequisites
• Logical Approaches to Solving the Problem
• My Naïve Approach
• Reassignments and a Single Return Statement
• Switching to Switch-Case from If-Else
• Logical Deduction & Subsets for Better Structure
• Logical Operators Combining All True Conditions
• Applying Nitro with the Ternary Operator
• Making it a Single Line Arrow Function
• Paradigm Shift: Declarative Programming
• Functions with Side Effects
• More About Functional Programming
• Side-Tracking: Short-Circuiting!
• Encapsulation and Declarative Programming
• Going Above & Beyond with Code Quality
• Validations: Beyond the Basic Specifications
• Testing it Out From the Outside
• End Note

Program Requirements & Prerequisites

Logical Approaches to Solving the Problem

My Naïve Approach

This is based on the pedagogical style of determining a leap year that I learned as a kid who knew how to divide numbers. If a year ( the number representing it) is divisible by 4, it is generally a leap year. But not always. When that year ends with two zeroes (meaning when the number is divisible by 100), it must also be divisible by 400 to be a leap year.

How to determine if a year is a leap year - as described above

As a beginner programmer, my thoughts flowed like you can see in the above flowchart. As a result, I converted that logic into my program like so:

function isLeapYear(year) {
  if (year % 4 == 0) {
      if (year % 100 == 0) {
          if (year % 400 == 0) {
              return true;
          } else {
              return false;
          }
      } else {
          return true;
      }
  } else {
   return false
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

This makes the program easily understandable. But with time, as I have moved farther in my programming journey, this type of code looks ugly because of so many nested conditional checks. It's not bad, but because of the nested levels, my brain has to work extra hard to get the logic from the code snapshot quickly.

Reassignments and a Single Return Statement

To avoid nested loops, many programmers follow the strategy of consecutive if conditions, avoiding the else conditions (like how Kyle Cook of Web Dev Simplified shows in this video with examples). It definitely improves readability.

Also, it lets us use only one return statement at the end while reassigning the returnable value. Let's not discuss it too much more when you can better see the code itself:

function isLeapYear(year) {
  let isLeap = false;
  if (year % 4 == 0) {
      isLeap = true;
  }
  if (year % 100 == 0) {
      isLeap = false;
  }
  if (year % 400 == 0) {
      isLeap = true;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

The above code looks shorter and quicker to interpret. But it does affect the efficiency of the code, as now you have to go through all of the if conditions in all cases.

In contrast, in our previous naïve approach, due to the if-else construct, if a year is not divisible by 4 (like the year 2023), it would just be checked against one if condition. It’s true, of course, that for small programs such as this one, you don’t have to be overly concerned with efficiency.

The pitfall in this approach, though, is that you need to be cautious to apply all the if conditions one after another — using ‘else if’ would create trouble, as that would skip some if condition checks if the previous if condition test passed.

Another important fact is that the order matters. Since you started with the more generic cases of years not being a leap year (that is, let isLeap = false;), you have to go from relatively generic to relatively more specific cases.

So if, out of your three condition checks, the check of divisibility by 4 comes at the end, it would make ‘isLeap’ true even for years that are divisible by 100 but not divisible by 400 (like years 1700, 1800, 1900, and so on).

The same logical error would occur if you interchange the order of divisibility checks involving 100 and 400.

One last point I must mention is that some beginner programmers may think that you can not use multiple return statements and you must return only once in a program (and that you can do reassignments until that point). But experienced programmers can only call that notion a beginners’ myth!

Switching to Switch-Case from If-Else

While the if-else structure is used to choose between two options, you can also use switch-case to choose one from multiple options. You can compare it to nested if-else blocks (as in the first approach) or a series of if blocks (as in the second approach).

The benefit of the switch-case structure is that it is more efficient because it can find the matching success criteria in one go.

Note that there is one quirky thing with switch-case. When using switch-case, once a case is matched, all subsequent cases will also execute unless you are using break statements. So, the following program will not be correct even if it looks very similar to our previous version of the code.

Incorrect code: to show problems with missing break statements

```js example-bad function isLeapYear(year) { let isLeap = false; switch (true) { case year % 4 == 0: isLeap = true; case year % 100 == 0: isLeap = false; case year % 400 == 0: isLeap = true; } return isLeap; }

If we must use a switch-case structure, we need to use break statements. We also need to go from specific cases first to generic cases next. While not all if-else logic can be converted into a switch-case logic, we can successfully convert the previous function like so:

```js
function isLeapYear(year) {
  let isLeap = false;
  switch (true) {
    case year % 400 == 0:
      isLeap = true;
      break;
    case year % 100 == 0:
      isLeap = false;
      break;
    case year % 4 == 0:
      isLeap = true;
      break;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Notice that in the above, we don't have a 'default' case. And this is because we have initialized the isLeap variable with false. Had we just declared the variable without initialization with a value, we could've written a default case which would assign the value false to isLeap.

Also, the above version of switch-case code is slightly longer because we wanted to use one return statement in the end and used assignments until then. But if we refactor it, a shorter and more organized code would be this:

function isLeapYear(year) {
  switch (true) {
    case (year % 400 === 0):
      return true;
    case (year % 100 === 0):
      return false;
    case (year % 4 === 0):
      return true;
    default:
      return false;
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Notice that since execution of a return statement in a function automatically ends the function call, the program does not read lines that follow that statement. So, in this example, we don't have to use the break statements necessarily.

Logical Deduction & Subsets for Better Structure

Switching back from switch-case to if-else logic, let's do some logical deduction. In our previous if-else logic, we went from generic cases to specific cases. What if we go in reverse order? We consider that a given year will be a leap year unless negated.

So, we start with the narrower cases of centenary years — for them, the rule is simple: to be negated, they need to be divisible by 100 but not by 400 (like years such as 1700, 1800, 1900).

In this process, since we've already accepted years like 2000 (or years divisible by 400) to be a leap year, we won’t test them for divisibility by 4 (because a number divisible by 400 would anyway be divisible by 4 as well).

In the next step, as we consider only the non-centenary years, we would simply negate the cases where the year is not divisible by 4 (years like 2023, 1996, and so on).

function isLeapYear(year) {
  let isLeap = true;
  if (year % 100 == 0 && year % 400 != 0) {
      isLeap = false;
  } else if (year % 4 != 0) {
      isLeap = false;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Here you see, we first consider the centenary years and then non-centenary years — so they are mutually exclusive — and that’s why we use ‘else-if’ instead of if in the second conditional check. And in that process, we gain some efficiency over consecutive if blocks.

As this approach is about breaking the possible routes of being a leap year (or for that matter, not being a leap year) into subsets of years, depending upon how we break the possible years into subsets, we can construct the program alternatively as shown below:

function isLeapYear(year) {
  let isLeap = false;
  if (year % 400 == 0) {
      isLeap = true;
  } else if (year % 100 != 0 && year % 4 == 0) {
      isLeap = true;
  }
  return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

So, in brief, our deduction from the leap year rule is that  years divisible by 400 (like 1600, 2000) are leap years, and out of all the other years they must be divisible by 4 but not divisible by 100 to be a leap year.

In taking this approach, we have combined conditions and that’s why we involved logical operators (&&, the logical AND operator). This has helped us reduce the length of the function. Instead of three conditional blocks, we are currently using two blocks — an if block and then an else (where we further check the condition, and thus we call it else-if rather than just else).

But now that we are just using almost a single ‘if-else’ construct and we are also delving into logical operators, let's unleash more power from the logical operators in the following approach.

Logical Operators Combining All True Conditions

This time let's just reorganize the logic from the previous approach (two subsets) to group all positive conditions together and then accept a year as a leap year. If that’s not met, then call it a non-leap year.

function isLeapYear(year) {
    if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
        return true;
    } else {
        return false;
    }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

This one looks good because it increases readability by organizing the positive conditions together. The only cost we incur here is that the condition in the if block is longer.

But with logical operators, it looks visually shorter and not complex (at least to programmers habituated to combining logical operators like this).

Dissecting further, since in the previous approach we said we could break the subsets in two different ways, we can have two corresponding two versions for this approach as well. The second one is the following:

function isLeapYear(year) {
  if ((year % 100 == 0 && year % 400 != 0) || year % 4 != 0) {
      return false;
  } else {
      return true;
  }
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Applying Nitro with the Ternary Operator

As you progress in your programming-learning journey, at some point or other, you must have been elated to discover the possibility of writing ultra-short programs.

While logical operators help us do that, to activate the ‘Nitro’ mode, we must use a Ternary Operator — which basically makes our if-else blocks a single line.

function isLeapYear(year) {
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

By now, as a pro programmer, you must be pitying your rookie self. You think of those times when you used to declare and initialize a variable with a default value first and then reassign it with the value you wanted to return, and finally return the value held by that variable.

It has been a long time since you shunned that practice, and you now return what you need to return, and don’t consume unnecessary memory space for useless variables.

Making it a Single Line Arrow Function

Now that you have been boosted with Nitro, your programming technique is advancing like an arrow, on a mission to tear away the remnants of ES5 and boldly fly into the post-ES6 world. So you welcome arrow functions with open arms.

const isLeapYear = year => (year % 4 === 0 && (year % 100 !== 0 || year % 400 === 0));

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Previously, you skipped variables, and you skipped ‘if-else’ blocks. And now, you can even skip the return statement thanks to the arrow function having a single statement in its body. You also skip the parentheses around your argument as it is a single argument.

While singing the saga of shorter code, a point must be made that the shorter code is not necessarily the better code. It all depends on your users of the code (people who might read it and possibly collaborate/improve upon it).

If you are working with experienced programmers, this level of concision is fine. Just make sure you don’t exceed the line width beyond a certain number of spaces (80 characters recommended) so you don't trouble your coworkers with the need to handle horizontal scrollbars.

But if you are working with team members with varying levels of experience, or you are a teacher working with learners, then you must be conscious of the readability of your code for everyone.

Paradigm Shift: Declarative Programming

Anyway, we have discussed the logic of determining the leap year in the above examples. But let’s now dissect further to find more nuances of programming. And in that process let's move from imperative programming (as we have used so far) towards declarative programming (which is the end goal in this section).

Functions with Side Effects

Functions are said to have side effects when they modify non-local variables. In addition, a function that prints (logs) in the console is also considered a function with some side effects. That is because if a function does not have a side effect, a call to it can be replaced by its return value.

Functional Programming is a paradigm which dictates that our program should be like a pure function without side effects. A pure function means a function which always returns the same output given the same input. So, in its body, it depends on only the input parameter given from outside and no other global variable. Additionally, it should just return the output value without side effects or trying to modify anything outside its scope.

But consider the following variation of the program which does not specifically return any value representing the result. Instead, it logs the result as a statement (string) in the console. This is an example of a side effect.

function isLeapYear(year) {
  if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
      console.log("leap year.");
  } else {
      console.log("not leap year.");
  }
}

// Example usage:
let someValue = isLeapYear(2024); // Output: leap year.
console.log(someValue); // Output: undefined

Evidently, it does not follow the specification, as it needs to return a value of boolean type. A function can, of course, do both — printing and returning, like an alternative form of the above function.

function isLeapYear(year) {
  if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
      console.log("leap year.");
      return true;
  } else {
      console.log("not leap year.");
      return false;
  }
}

// Example usage:
let someValue = isLeapYear(2024); // Output: leap year.
console.log(someValue); // Output: true

But the mere fact that it is doing two things — returning a value and printing in the console —  is the problem. A function should be made to do one thing for proper reusability. The ‘isLeapYear’ function should just determine if a year is a leap year. If we need to print anything about it, let that onus of doing the side effects lie with some other logger function(s).

// pure function

function isLeapYear(year) {
    if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
        return true;
    } else {
        return false;
    }
}

// functions with side effect

function simpleLeapYearLogger(isLeap) {
    if (isLeap) {
        console.log("Yes, a leap year!");
    } else {
        console.log("Sorry, not a leap year.");
    }
}

function advancedLeapYearLogger(year, isLeap) {
    if (isLeap) {
        console.log(`The year ${year} is a leap year!`);
    } else {
        console.log(`The year ${year} is not a leap year!`);
    }
}

// Example usage:
let currYear = 2024;
let check2024 = isLeapYear(currYear); // No Output/Side Effect, just retuned value.
simpleLeapYearLogger(check2024); // Output: Yes, a leap year!
advancedLeapYearLogger(currYear, check2024); // Output: The year 2024 is a leap year!

As you can see above, the function ‘isLeapYear’ is more reusable — with two different use cases in two separate logger functions. Also, had there been any mistake in the logic for the ‘isLeapYear’ function, it would have been easier to fix without touching the logger functions’ code.

Similarly, if you need to display the string logged in the console differently, you could modify the respective logger function without touching the leap year’s logic function. Thus, a function doing just one thing that it was supposed to do increases the reusability and maintainability of that function.

More About Functional Programming

In the above section, you have already ventured into the space of functional programming. And now is the time to delve deeper.

If I search the term ‘Functional Programming’ in Wikipedia, the first line states

“functional programming is a programming paradigm where programs are constructed by applying and composing functions.”

The phrase ‘composing function’ means building complex functions from simple ones. In our example, the leap year function is quite simple already. But to showcase the mechanism of function composition, let's create it out of component functions.

// component function
function divisible(dividend, divisor) {
    return dividend % divisor == 0
}

// composed function
function isLeapYear(year) {
    let isLeap = false;
    divisible(year, 4) && (isLeap = true);
    divisible(year, 100) && (isLeap = false);
    divisible(year, 400) && (isLeap = true);
    return isLeap;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear(2023)); // Output: false
console.log(isLeapYear(1900)); // Output: false
console.log(isLeapYear(2000)); // Output: true

Side-Tracking: Short-Circuiting!

Above, you are using a function to build another function — a component-based approach that you also follow in the React JavaScript-based front-end library.

But wait, before we go further into React, what is that ‘&&’ doing in those three lines in the 'isLeapYear' function when we are not using any if-else statements there?

Welcome to the short-circuit evaluation of logical operators. In that process, an expression stops being evaluated as soon as its outcome is determined. So if two sides contain a logical AND (&&) in between, if the first side is false, this makes the whole expression false – so it does not read (not execute) the second side.

But if the first side is evaluated to be true, it further reads (executes) the second side for evaluation. And in that process, it does that assignment on the right-hand side of && in our example.

Similarly, the process when logical OR (||) is involved is such that if the left-hand side is evaluated as true, the whole expression is true (it needs one condition evaluated as true for || for the whole expression to be true). Then, the second side is ignored. The second side is read or executed only when the first side is evaluated as false.

You can use this kind of evaluation logic as a replacement for the ‘if’ condition checks. For more examples of how it works in different scenarios, read the section ‘Short-Circuiting of Logical Operators (&& and ||)’ in my blog post where I have discussed some nuances of JavaScript Operators.

Encapsulation and Declarative Programming

Returning to REACT and components, the idea of building composing functions or components is rooted in the need for encapsulation. With encapsulation, you can hide the complex details, like in a capsule, and use it repeatedly without bothering much about its underlying complexity.

Essentially, you just proclaim (declare) what you need rather than straining yourself with the workload and headache of how you can make it happen step-by-step with ‘do-this’ and ‘do-that’ type statements (imperatives).

That, briefly, is declarative programming for you.

Going Above & Beyond with Code Quality

So far, we have covered the logical structures and the programming paradigms, but now, let’s look at the third aspect: code quality.

Validations: Beyond the Basic Specifications

The requirements that we laid out at first just considered valid inputs. What if the function is called with arguments that are not the ideal ones — like a non-number, or even if a number but a non-integer?

To address that, we can build validation logic. To build validation logic, you need to think about all the different ways in which the input value (the argument passed to your function) may not be workable for you.

If one of those non-workable ways does come along, you need to return something that makes more sense — you can not give a verdict like true or false in that case. You may return something more neutral (like undefined or null) to indicate that the function encountered an invalid entry.

function isLeapYear(year) {
  if (typeof year!="number" || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear("TwentyTwentyFour")); // Output: undefined
console.log(isLeapYear(2023.99)); // Output: undefined
console.log(isLeapYear(0)); // Output: undefined
console.log(isLeapYear(-1)); // Output: undefined
console.log(isLeapYear("2024")); // Output: undefined

But if you noticed carefully, in our leap year logic check, we have evaluated just ordinary equality (==) instead of strict equality (===). We can't reap the benefit of that for a string format entry for a year like "2024".

If our intention is to strictly accept a number, the kind of validation we wrote is fine, and it would then be even more proper to use ===.

But if, on the other hand, we want to accept values like "2024", we must enhance our validation logic like so:

function isLeapYear(year) {
  if (isNaN(Number(year)) || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

// Example usage:
console.log(isLeapYear(2024)); // Output: true
console.log(isLeapYear("TwentyTwentyFour")); // Output: undefined
console.log(isLeapYear(2023.99)); // Output: undefined
console.log(isLeapYear(0)); // Output: undefined
console.log(isLeapYear(-1)); // Output: undefined
console.log(isLeapYear("2024")); // Output: true

Testing it Out From the Outside

In the above two code blocks, we write our code and test it in the same place. But the code that goes into production will not have the opportunity to include such console logs that we have used extensively for demonstrating 'example usage' in the above code blocks.

This is where unit testing comes in. In unit testing, we first export the function for use in other places (files), then import that function in a test file. In that test file is where we run the test, build our cases, and finally run that test file to execute those tests.

I have used the Jest package to do this unit testing, and here is the code from my index file and test script file:

index.js

function isLeapYear(year) {
  if (isNaN(Number(year)) || year % 1 != 0 || year <= 0) return undefined;
  return ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) ? true : false;
}

module.exports = isLeapYear;

index.test.js

const isLeapYear = require('./index.js');

describe('Test isLeapYear', () => {
  it('should return true for leap year', () => {
    expect(isLeapYear(2020)).toBe(true);
  });
  it('should return false for non-leap year', () => {
    expect(isLeapYear(2023)).toBe(false);
  });
  it('should return undefined for invalid input', () => {
    expect(isLeapYear('TwentyTwentyFour')).toBe(undefined);
    expect(isLeapYear('2023.99')).toBe(undefined);
    expect(isLeapYear('0')).toBe(undefined);
    expect(isLeapYear('-1')).toBe(undefined);
  });
  it('should return true for a leap year in string format', () => {
    expect(isLeapYear("2024")).toBe(true);
  });
});

I installed Jest using the command npm i jest. Then, I added jest as a value for test in the scripts object inside my package.json file. Then, as I ran npm test, it passed all my test cases, like so:

testing output

If you want to tweak and try this unit testing code, you can use and fork this replit project.

End Note

We've reviewed many programming concepts in the above exercise. And one key takeaway is that a program can be written in multiple ways.

There are typically many correct solutions to a programming problem. So beginner programmers should, therefore, think of the logic part of it (the algorithm) more than the exact execution steps when starting to solve a problem.

And by the way, if you're wondering why we have leap years, then this is for you: the time Earth takes to complete one revolution around the sun is not exactly 365 days (or 365 x 24 hours) but approximately one-quarter of a day extra.

This process may remind you of the modulus operator, represented by the symbol %, which returns the remainder of a division operation. Here, the approximate time (in hours) taken for one revolution of earth is being divided by 24 hours (that is, a day). It gives a remainder of about 6 hours.

const approxTimeHrsRev = 8766;
const hrsPerDay = 24;
let completedDaysEachYear;

let remainderHrsPerYear = 8766 % hrsPerDay;
completedDaysEachYear = (approxTimeHrsRev - remainderHrsPerYear) / hrsPerDay;

console.log(`After ${completedDaysEachYear} complete days, there is still about ${remainderHrsPerYear} hours left out each year.`);
// Output: After 365 complete days, there is still about 6 hours left out each year.

To account for those missed hours, we must adjust our calendars once every four years when those left-out portions add up to make — again approximately — a day.

Finally, because it is not exactly 6 hours, and a tiny bit more than that, we have to adjust every 100 and 400 years further.