Forem: Ugwuoke Adaeze

When Tests Can't Reach Your Code, That may not be a Test Problem...

Ugwuoke Adaeze — Thu, 12 Mar 2026 06:41:26 +0000

There's a common misconception that writing tests is purely about verifying that your code works. That's true, but it's only half the story. Tests also apply pressure to your code structure and design. Code that is hard to test is usually hard to reason about, hard to reuse, and hard to debug, for the same underlying reason: it's too coupled to its context.

This is my story about a test coverage gap that revealed a design flaw, and how fixing the design fixed the coverage, along with some other things I hadn't noticed were broken.

The Setup

Imagine a React form component that manages a list of shipping destinations. Each destination has fields like address, weight limit, and delivery zone. When the user submits with incomplete destinations, a toast notification should appear telling them to fill out all the required fields.

The validation error-checking logic lives inside a useEffect:

// ShippingForm.tsx

useEffect(() => {
  const destinationErrors = errors?.destinations as DestinationError[];
  const hasErrors =
    destinationErrors?.some((entry) => {
      if (!entry) return false;
      return Object.values(entry).some((field) => field?.message);
    }) ?? false;

  if (hasErrors) {
    toast.error('Please expand and fill all destination fields');
  }
}, [errors]);

The logic does three things:

Guards against null entries in the errors array (if (!entry) return false)
Checks whether any field in the entry has an error message
Shows a toast if any errors are found

This looks reasonable. It works in the browser. Surely the tests will should be straightforward or so I thought.

The Coverage Gap

When writing tests for this component, the happy path and most error paths were straightforward to cover. But the coverage report flagged one specific line as unreachable:

if (!entry) return false;

The instinct was to find a way to trigger this branch through the component, submit the form with one valid destination and one invalid one, so the errors array would contain a null entry at the first index and an error object at the second.

The problem? React Hook Form never actually produces that.

RHF stores field array errors as a sparse object internally: { 1: { address: {...} } }.
When that gets cast to an array and iterated with .some(), JavaScript only visits keys that exist. Index 0 is never visited. The callback never receives a falsy value. The if (!entry) return false branch is, in practice, unreachable through normal form interaction.

At this point there are two roads:

Road A: Find a subtle workaround, spy on useForm, override formState, inject a synthetic errors object with a null entry just to hit the branch.
Road B: Ask why the branch is unreachable, and fix.

PS: I, like a couple of other people, I know and do not know, detest rewriting codes we didn’t write, but if you have a boss and mentor like mine who will drag you like 'tiger gen' with the statements like “i ga na e make use of your upper”, “i na-ede some funny funny things”, (find an Igbo person to translate, lol), “why exactly do we have this here?”(me in my mind: swear you don’t know why we have it 😩😭😂), you will not choose A.
You'll be forced to learn to find joy in doing things the right way. Anyways I digress 🤲🏽😅.
I chose B cause the reason for those statements was beginning to make sense after hearing them multiple times over the past 1+ years.

Road B is always the right answer, it often reveals more with a simpler approach.

What the Unreachable Branch Was Actually Saying

The if (!entry) return false guard is defensive code. It's protecting against a null value appearing in the array. But that situation can only arise if the errors object is constructed manually, it never happens in the actual running system.

So why is it there? Either:

It was added out of caution without confirming it was reachable
It was copy-pasted from somewhere where it made sense
It was written to handle a case we thought could happen, but can't

In any of those cases, the logic is either dead code or it's solving a hypothetical problem. And it's doing so inside a useEffect that also owns the side effect of calling toast.error. That's two jobs in one place.

And that is the real problem the test was pointing at.

The Fix: Extract the Logic

The solution is to pull the error-checking logic out of the useEffect and into a standalone pure function:

// utils/destination-field-errors.ts

type ErrorField = {
  message: string;
  type: string;
};

type DestinationError = {
  address?: ErrorField;
  weightLimit?: ErrorField;
  deliveryZone?: ErrorField;
} | null;

export const hasDestinationFieldErrors = (
  destinations: DestinationError[] | undefined
): boolean => {
  if (!destinations) return false;
  return destinations.some((entry) => {
    if (!entry) return false;
    return Object.values(entry).some((field) => !!field?.message);
  });
};

The component's useEffect becomes a clean one-liner:

// shipping-form.tsx

useEffect(() => {
  if (hasDestinationFieldErrors(errors?.destinations as DestinationError[])) {
    toast.error('Please expand and fill all destination fields');
  }
}, [errors]);

Now the Tests Are Trivial

With the logic extracted, every branch is reachable by passing plain values directly to the function. No component. No form submission. No React Hook Form internals.

Every branch is hit. Every test is readable. No mocking of framework internals required.

But the Actual Benefits Go Beyond Coverage

You will agree with me on this. Here's what else improved by making this change, none of which the test coverage report would say.

1. Single Responsibility

Before the extraction, the useEffect was doing two jobs: computing whether errors exist AND reacting to that result by firing the toast. Those are different concerns.
After extraction, each piece has one job:

the function answers a question,
the effect acts on the answer.

2. The Logic Became Visible

When logic lives inside a useEffect, it's hidden inside React's machinery. To understand what "checking for destination errors" means, you have to mentally parse the hook, the dependency array, and the inline logic all at once.

A named function hasDestinationFieldErrors documents intent at the call site. The name itself becomes part of the codebase's vocabulary, searchable, referenceable, and self-explanatory.

3. Reusability

If another component, hook, or validation flow ever needs the same logic, it can import the function directly. Without the extraction, the only option is to copy-paste, which is how subtle bugs and inconsistencies spread across a codebase.

4. Easier Debugging

When a bug is reported about error toasts not appearing, or appearing incorrectly, there is now a precise entry point. You can test hasDestinationFieldErrors in isolation with the exact inputs from the bug report, without needing to reproduce the full form state in a browser.

The Bigger Lesson

Tests didn't cause this improvement. The improvement was always available. But without the discipline of writing tests, there was no mechanism to feel the resistance that the design was creating.

This is what good test coverage actually does. It doesn't just verify that the code works. It applies constant, honest pressure to the structure of the code itself.
A function that is hard to test is a function that probably is doing too much, coupled to too much, or hiding in a place it doesn't really belong.

If you can't write a clean test for something, just maybe the code is telling you something.

The coverage gap was never really about a missing test. It was a signal that a piece of logic had no identity of its own, it existed only as a side note inside a React hook. Giving it an identity (a name, a file, a signature, a test) forced it to stand on its own, and in doing so, made the entire surrounding system cleaner.

That, my friend, is one the many reasons why testing matters. Not just to catch bugs, but to keep asking the question: Is this code as simple and clear as it could be?

Are you team test or no test?
Have you encountered a coverage gap that pointed to a deeper code structure or design issue?
Lemme hear from you...

A Beginner's Guide to Loops

Ugwuoke Adaeze — Sat, 30 Nov 2024 18:58:09 +0000

Loops are one of the most important concepts to understand when learning programming. They are control flow statements that allow you to repeat a block of code multiple times, making your programs less repetitive, concise, and easier to maintain. They are tools that let your program repeat actions until a certain condition is met. Conditions return true or false. A loop will continue running until the defined condition returns false.

We’ll cover three types of loops in this article — for loop, while loop, and do-while loop. These loops basically do the same thing(repeating a block of code until the condition returns false), however, a type of loop may be preferred over another depending on the situation at hand. The syntax for most loops typically includes the following;

Initialization: This is executed once before the code block runs.
Condition: This defines the rule for the loop to run before and after each iteration. If the condition evaluates to true, the statement is executed, loop ends if false.
Statement: This is the code to execute in each iteration. To execute multiple statements, use a block statement ({ }) to group them.
Update: happens after each iteration until the condition returns false, and the loop ends. This update can be an increment or a decrement.

Imagine you’re doing household chores: you wash one dish, then another, and you stop only when all the dishes are clean. That’s essentially a loop in action!

The For Loop
A for loop is a statement that allows you to execute a block of code repeatedly until the condition evaluates to false.

For loop syntax

for (initialization; condition; update) {
    // Statement(s)
}

Example 1: Delivering Packages
You have 5 packages to deliver. You need to:

Start with the first package.
Deliver each package in order.
Stop when all packages are delivered.

for (let i = 1; i <= 5; i++) {
    console.log("Delivering package number:", i);
}

How It Works
let i = 1: Start with the first package (i is your counter, starting at 1).
i <= 5: Keep delivering while the number of packages (i) is less than or equal to 5.
i++: Move to the next package after delivering the current one.

Example 2: Printing array items

const fruits = ['apple', 'banana', 'cherry'];
for (let i = 0; i < fruits.length; i++) {
  console.log(`Fruit: ${fruits[i]}`);
}
// Logs "Fruit: apple", "Fruit: banana", "Fruit: cherry"

Example 3: Counting Down

for (let count = 10; count > 0; count--) {
  console.log(`Countdown: ${count}`);
}
// Logs "Countdown: 10" to "Countdown: 1"

Example 4: Creating a Multiplication Table

for (let i = 1; i <= 5; i++) {
  console.log(`2 x ${i} = ${2 * i}`);
}
// Logs "2 x 1 = 2" to "2 x 5 = 10"

The While Loop
You keep executing a statement as long as a condition remains true.

While loop syntax

while (condition) {
    // Statement

update
}

Example 1: Filling a Glass with Water
You’re pouring water into a glass. You:

Start pouring.
Keep pouring while the glass isn’t full.
Stop when the glass is full.

let glassFull = false; // The glass starts empty

while (!glassFull) { // Keep pouring while the glass is not full
    console.log("Pouring water...");
    glassFull = true; // Assume the glass becomes full after pouring
}

How It Works
glassFull = false: Start with an empty glass.
while (!glassFull): Condition Check... Is the glass is full? If not, continue pouring.
glassFull = true: After pouring, the glass becomes full, and the loop stops.

Example 2: Summing up Numbers

let num = 1;
let sum = 0;
while (num <= 10) {
  sum += num;
  num++;
}
console.log(`Sum: ${sum}`);

// Logs "Sum: 55"

Example 3: Evaluating User's Input

let password = "";
while (password.length < 8) {
  password = prompt("Enter a password with at least 8 characters:");
}

console.log("Password accepted.");

Example 4: Calculating Total Cart Price

const cart = [
  { item: "Laptop", price: 1200 },
  { item: "Mouse", price: 25 },
  { item: "Keyboard", price: 75 },
];

let total = 0;
let i = 0;

for ( i < cart.length ) {
  total += cart[i].price;
  i++;
}

console.log(`Total cart price: #${total}`);

The Do Loop
A do-while loop is like a while loop, but with one key difference:
It always runs the code at least once, before checking if the condition is true, then it repeats the loop until the condition evaluates to false.

Do loop syntax

do {
    // Statement
} while (condition);

Example 1: Playing a ludo game
You roll a dice first
If you get a 6, you roll again until you don't.

let diceRoll;
do {
    diceRoll = Math.floor(Math.random() * 6) + 1; // Roll the dice ( the operation generates a random number between 1 and 6)
    console.log(`You rolled a: , ${diceRoll}`);
} while (diceRoll === 6); // Keep rolling if the number is less than 6

How It Works
First Roll: The do part executes, rolling the dice.
Condition Check: The while part checks if the number is 6. If true, roll again. If false, stop.

Example 2: Showing Onboarding Steps

const steps = ["Step 1: Welcome", "Step 2: Set Up Profile", "Step 3: Complete Tutorial"];
let stepIndex = 0;

do {
  console.log(steps[stepIndex]);
  stepIndex++;
} while (stepIndex < steps.length);

Example 3: User Authentication Simulation

const correctPassword = "secure123";
let enteredPassword;

do {
  enteredPassword = prompt("Enter your password:");
} while (enteredPassword !== correctPassword);

console.log("Welcome back!");

Example 4: Pagination (Loading Pages)

let currentPage = 1;
const totalPages = 5;

do {
  console.log(`Loading page ${currentPage}...`);
  currentPage++;
} while (currentPage <= totalPages);

console.log("All pages loaded.");

Converting Between Loops
The key to converting between loops is knowing where to place each part is placed in a loop's syntax; initialization, condition, update, and statement.
For Loop
All parts come in a bracket after the for statement

for (initialization; condition; update) {
  // execution statement
}

While Loop

initialization; // Move initialization before the loop
while (condition) { // Condition comes right after the while statement
  Execution Statement  // inside the loop
  update; // inside the loop, right after the statement
}

Do Loop

initialization; // move before the loop
do {
  Execution Statement // inside the loop
  update; // inside the loop
} while (condition); // condition is checked after the loop body

Example Conversion between loops

For loop

const products = [
  { name: "Product A", price: 10, quantity: 2 },
  { name: "Product B", price: 15, quantity: 3 },
  { name: "Product C", price: 20, quantity: 1 }
];

let totalCost = 0;

for (let i = 0; i < products.length; i++) {
  const product = products[i];
  totalCost += product.price * product.quantity;
}

console.log("Total cost:", totalCost);

Explanation:
Initialization: We initialize a totalCost variable to 0.
Condition: Checks if the i is less than the length of the products.
Update: The loop iterates over each product in the products array.
Calculation: For each product, we calculate the product's total cost by multiplying its price and quantity.
Accumulation: The calculated product cost is added to the totalCost variable.
Final Output: After processing all products, the final totalCost is printed to the console.

While Loop
Using the same code above, we'll convert it to a while loop.

const products = [
  { name: "Product A", price: 10, quantity: 2 },
  { name: "Product B", price: 15, quantity: 3 },
  { name: "Product C", price: 20, quantity: 1 }
];

let totalCost = 0;
let index = 0;

while (index < products.length) {
  const product = products[index];
  totalCost += product.price * product.quantity;
  index++;
}

console.log("Total cost:", totalCost);

Do Loop
Using the same lets convert to a Do loop.

const products = [
  { name: "Product A", price: 10, quantity: 2 },
  { name: "Product B", price: 15, quantity: 3 },
  { name: "Product C", price: 20, quantity: 1 }
];

let totalCost = 0;
let i = 0;

do {
  const product = products[i];
  totalCost += product.price * product.quantity;
  i++;
} while (i < products.length)

console.log("Total cost:", totalCost);

Happy Learning!

Performance Optimization in React

Ugwuoke Adaeze — Sat, 19 Oct 2024 17:34:25 +0000

Code Performance optimization is a set of strategies and techniques developers utilize to enhance the speed and efficiency of their software applications. There are various techniques software developers use to enhance performance, and we will be discussing a few of them below.

useMemo
useMemo is a React hook that caches/stores the result of a function so that the value doesn’t get recalculated unless its dependencies change. This is useful for expensive calculations that don’t need to run on every render.

import React, { useState, useMemo } from 'react';

const App = () => {
  const [count, setCount] = useState(0);
  const [input, setInput] = useState("");

  // Memoizing the result of the expensive calculation
  const memoizedValue = useMemo(() => {
    console.log("Calculating...");
    for (let i = 0; i < 1000000000; i++) {} // Simulate expensive logic
    return count * 2;
  }, [count]);

  return (
    <div>
      <h1>Memoization Example</h1>
      <p>Result: {memoizedValue}</p>

      <button onClick={() => setCount(count + 1)}>Increment Count</button>
      <input
        value={input}
        onChange={(e) => setInput(e.target.value)}
        placeholder="Enter something"
      />
    </div>
  );
};

export default App;

In the code, Without useMemo() the expensive calculation would run on every render, even if only the input state changes.
With useMemo(): The calculation inside useMemo only runs when the count state changes. When input changes, React re-renders, but the cached value for memoizedValue is used, avoiding the recalculation of the expensive calculation.
This ensures performance optimization by minimizing unnecessary re-computations, especially when the expensive logic isn’t affected by every state update.

useCallback
useCallback is a React hook that memoizes a function so that it isn’t recreated every time the component re-renders. This is particularly useful when you pass functions as props to child components.

import React, { useState, useCallback } from 'react';

const Child = React.memo(({ onClick }) => {
  console.log("Child component re-rendered");
  return <button onClick={onClick}>Click Me</button>;
});

const App = () => {
  const [count, setCount] = useState(0);

  // Memoizing the function to prevent re-creation
  const handleClick = useCallback(() => {
    console.log("Button clicked");
  }, []);

  return (
    <div>
      <h1>useCallback Example</h1>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment Count</button>
      <Child onClick={handleClick} />
    </div>
  );
};

export default App;

Without useCallback in the code, the handleClick function would be recreated every time the parent component re-renders, causing the Child to re-render unnecessarily.
With useCallback, the function is memoized, so the Child only re-renders when necessary.

useRef
useRef can play a key role in performance optimization by reducing unnecessary re-renders and improving efficiency. It allows developers to store mutable values and interact with the DOM without triggering component re-renders.
useRef can be utilized in different ways;
Avoids Re-renders by Storing Mutable Values: Unlike useState, updating a value stored in a useRef object does not trigger re-renders. This is particularly useful when you want to store values that change frequently (like form field focus states, counters, or previous values) but don’t affect the UI.

import { useRef } from 'react';

const ClickCounter = () => {
  const clickCount = useRef(0); // Persistent value across renders

  const handleClick = () => {
    clickCount.current += 1; // Updates without triggering re-render
    console.log(`Button clicked ${clickCount.current} times`);
  };

  return <button onClick={handleClick}>Click Me</button>;
};

export default ClickCounter;

Here, the click count is updated without causing unnecessary re-renders of the component, improving performance.

Prevents Unnecessary Function Re-Creations: When used with event handlers or timers, useRef ensures that the function or value persists across renders. This prevents re-creating functions on each render, saving memory and execution time.

import { useRef, useEffect } from 'react';

const Timer = () => {
  const intervalRef = useRef(null);

  useEffect(() => {
    intervalRef.current = setInterval(() => {
      console.log('Tick');
    }, 1000);

    return () => clearInterval(intervalRef.current); // Cleanup on unmount
  }, []); // No dependency updates here

  return <div>Check the console for ticks!</div>;
};

export default Timer;

Using useRef to store the interval ID ensures that the timer persists without needing to update the interval function or causing unnecessary component re-renders.

Efficient DOM Manipulation Without Re-renders

Using useRef to reference DOM elements avoids state updates (which would trigger re-renders) when all you need is to manipulate the DOM directly.
Example:

import { useRef } from 'react';

const AutoFocusInput = () => {
  const inputRef = useRef(null);

  const focusInput = () => {
    inputRef.current.focus(); // Directly interacts with the DOM
  };

  return (
    <div>
      <input ref={inputRef} type="text" />
      <button onClick={focusInput}>Focus Input</button>
    </div>
  );
};

export default AutoFocusInput;

Explanation: Directly interacting with the DOM using useRef avoids unnecessary state updates and re-renders, improving performance.

Storing Previous State or Prop Values Without Triggering Re-renders

useRef can store the previous value of state or props without causing re-renders, unlike useState.
Example:

import { useState, useRef, useEffect } from 'react';

const PreviousState = () => {
  const [count, setCount] = useState(0);
  const prevCount = useRef(count); // Stores the previous value

  useEffect(() => {
    prevCount.current = count; // Updates without re-rendering
  }, [count]);

  return (
    <div>
      <p>Current Count: {count}</p>
      <p>Previous Count: {prevCount.current}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
};

export default PreviousState;

In the code, the prevCount is stored using useRef to avoid triggering re-renders when updating the previous value.

Why useRef Improves Performance:
Prevents unnecessary re-renders: Storing values in useRef avoids costly UI updates when the component does not need to re-render.
Efficient DOM interactions: Manipulating the DOM directly with useRef avoids updating the component’s state.
Minimizes function re-creation: With useRef, event handlers and timers remain consistent across renders, reducing the overhead of re-creating functions.
When to Use useRef for Optimization:
When storing mutable values that don't need to trigger re-renders (e.g., counters, previous states).
When interacting with DOM elements directly without modifying component state.
When you need consistent references to functions or values (e.g., timers, event listeners).
Conclusion:
useRef is a powerful hook for performance optimization in React. By storing values that persist across renders without causing re-renders, it reduces unnecessary UI updates and enhances efficiency. It’s especially useful when managing DOM elements, maintaining previous state or props, and avoiding frequent function re-creation.

Memo
React memo is a higher-order component (HOC) that wraps your functional component. Memo is used to simulate pure components, that is components that don't rerender unless there is a change in the props or states. This helps to avoid unnecessary re-renders when the parent component updates.
Every time a component’s state or props change, React triggers a re-render to update the user interface. However, unnecessary re-renders can hurt performance, especially if the component tree is large.
Example; If ParentComponent passes a prop to ChildComponent, every time the parent re-renders, the child also re-renders, even if the child’s data hasn’t changed.
To memoize a component wrap it in a memo, it will not re-render when its parent component re-renders as long its props remain the same.

import { memo, useState } from 'react';

export default function MyApp() {
  const [name, setName] = useState('');
  const [address, setAddress] = useState('');
  return (
    <>
      <label>
        Name{': '}
        <input value={name} onChange={e => setName(e.target.value)} />
      </label>
      <label>
        Address{': '}
        <input value={address} onChange={e => setAddress(e.target.value)} />
      </label>
      <Greeting name={name} />
    </>
  );
}

const Greeting = memo(function Greeting({ name }) {
  console.log("Greeting was rendered at", new Date().toLocaleTimeString());
  return <h3>Hello{name && ', '}{name}!</h3>;
});

In the code provided, memo enhances performance by preventing unnecessary re-renders of the Greeting component.
Without memo(), Greeting would re-render every time any part of the parent component (MyApp) re-renders, such as when address changes.
With memo(), Greeting only re-renders if the name prop changes, skipping re-renders when irrelevant state (like address) is updated.
This optimization reduces the rendering workload, improving the app's performance by minimizing unnecessary renders.
Memo() Optimizes Performance through:

Shallow Comparison of Props: On every render, memo() compares the current props with the previous props. If the props are the same (using shallow comparison), the component won’t re-render, reducing unnecessary rendering.
Avoids Re-renders in Child Components: Useful when a parent component frequently re-renders, but the child component’s props don’t change.

Profiler
The <Profiler /> component is a built-in React tool that measures the rendering behavior of components wrapped inside it. It records the response time of a component and logs each re-render with useful information such as render duration and the reason for re-renders (e.g., state changes or prop updates). Profiling adds some additional overhead, so it is disabled in the production build by default.
Profiler takes in two props, an id, and an onRender callback function.

<Profiler id="Sidebar" onRender={onRender}>
<Profiler/>

id: A string identifying the part of the UI you are measuring, usually the name of the component being measured.
onRender: An onRender callback that React calls every time components within the profiled tree update. It receives information about what was rendered and how much time it took.

function onRender(id, phase, actualDuration, baseDuration, startTime, commitTime) {
  // Aggregate or log render timings...
}

usage of Profiler:

The whole App can wrapped with the profiler as shown below

<Profiler id="App" onRender={onRender}>
  <App />
</Profiler>

Wrapping specific components with the profiler

<App>
  <Profiler id="Sidebar" onRender={onRender}>
    <Sidebar />
  </Profiler>
  <PageContent />
</App>

Nesting components with the profiler

<App>
    <Sidebar />
    <Profiler id="Content" onRender={onRender}>
    <Content>
      <Profiler id="Editor" onRender={onRender}>
        <Editor />
      </Profiler>
      <Preview />
    </Content>
  </Profiler>
</App>

When to Use These Tools?

Use React.memo: When you have functional components that receive unchanging props. Example: Display components that show static or rarely changing information.
Use useMemo: When you need to cache expensive calculations to avoid unnecessary recomputations. Example: A search feature that filters large datasets.
Use useCallback: When you pass functions as props to child components to avoid triggering re-renders. Example: Buttons or input handlers inside child components.
Use <Profiler /> Component

During development: Use it to track performance bottlenecks early and ensure components aren’t rendering more than necessary.
In large applications: Use to analyze the impact of heavy components (e.g., data grids or charts).
Before releasing: Identify any slow renders or unnecessary re-renders before shipping your app.

Other methods of performance optimization include; code splitting and lazy for lazyloading.

Code splitting

Code-splitting is a feature that enables you to create multiple bundles that can be dynamically loaded at runtime. This basically breaking your application’s code into smaller chunks (bundles).
Instead of loading the entire app upfront, code splitting ensures that only the necessary chunks are loaded at a time—like loading a particular page or component on demand.
This reduces initial load time and improves performance, especially for large applications.
Code splitting can help your app “lazy-load” just the things that are currently needed by the user, which can significantly improve the speed and performance of your app. While you haven’t reduced the overall amount of code in your app, you’ve avoided loading code that the user may never need and reduced the amount of code needed during the initial load.

Lazy
lazy allows you to defer loading a component’s code until it is rendered for the first time. It returns a React component you can render in your tree. While the code for the lazy component is still loading, attempting to render it will be suspended. can be used to display a loading indicator while it’s loading.

import React, { Suspense, lazy } from 'react';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';

// Lazy load pages
const Home = lazy(() => import('./pages/Home'));
const About = lazy(() => import('./pages/About'));
const Contact = lazy(() => import('./pages/Contact'));

function App() {
  return (
    <Router>
      <Suspense fallback={<p>Loading page...</p>}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
          <Route path="/contact" element={<Contact />} />
        </Routes>
      </Suspense>
    </Router>
  );
}

export default App;

In the above code, we use lazy() to load the page components (Home, About, Contact) only when the user navigates to those routes and <suspense/> to show a loading message while the loads.

Happy Learning!!!

Understanding React, Component Lifecycle, and UseEffect Hook

Ugwuoke Adaeze — Wed, 16 Oct 2024 19:18:42 +0000

You may have heard that React is a library but what actually makes it a library and not a framework?
A framework typically provides everything you need to build an application; state management, routing, testing etc.
A library on the other hand focuses on the User Interface and gives you the freedom to use extra tools to complete your project such as redux or context for state management, react-router for routing, and so on, which is exactly what react does.

React is a javascript library that uses custom reusable components to make building UIs faster and well structured. This reusability gives you the ability to update a particular section of your application without needing to update it individually everywhere else.
React allows developers write both logic and structure on the same page using JSX syntax, making codes easier to read and work with.
React uses a Virtual DOM (an in-memory representation of the actual DOM) to update the UI efficiently. When data changes, React updates only the part of the UI that changed, instead of reloading the whole page.

Component Lifecycle in React

In class-based React components, certain methods are invoked at different points in the component’s "lifecycle." These lifecycle methods allow you to control what actions the component should perform at each stage, such as when it mounts, updates, or unmounts.
They are a way of telling your code when to perform a particular action at each stage. The names easily explain the stage each of them represents.

Component DidMount
This method runs once right after the component is rendered for the first time, ie immediately after the component is added to the DOM. It performS any action that should only happen when the component appears for the first time. Usage includes; Fetching data from APIs, setting timers or intervals, adding event listeners etc.
Example Usage
Fetching data from an API when the component loads:

class UserProfile extends React.Component {
  state = { user: null };

  componentDidMount() {
    fetch('https://api.frontendfirefighter.com/user/1')
      .then((response) => response.json())
      .then((data) => this.setState({ user: data }));
  }

  render() {
    const { user } = this.state;
    return <div>{user ? <h1>{user.name}</h1> : <p>Loading...</p>}</div>;
  }
}

In this example, componentDidMount() triggers an API call to fetch user data as soon as the component appears.

Component DidUpdate
This method runs every time the component updates, that is whenever props or state change. It’s useful when you need to react to changes in props or states and perform some action after the re-render. Usage includes; Fetching new data if certain props have changed, updating the DOM in response to new data, triggering side effects based on state or prop changes.
Example usage:
Re-fetching data when a prop changes:

class UserProfile extends React.Component {
  componentDidUpdate(prevProps) {
    if (this.props.userId !== prevProps.userId) {
      fetch(`https://api.frontendfirefighter.com/user/${this.props.userId}`)
        .then((response) => response.json())
        .then((data) => console.log('New user data:', data));
    }
  }

  render() {
    return <h1>User ID: {this.props.userId}</h1>;
  }
}

In this example, componentDidUpdate() checks if the userId prop has changed. If it has, it fetches new user data.

Component WillUnmount
This method runs just before the component is removed from the DOM. It’s essential for cleaning up resources to avoid memory leaks, such as clearing timers or removing event listeners. It runs right before the component is unmounted and removed from the DOM. Usage includes; clearing timers or intervals, removing event listeners, canceling network requests.
Example Usage:
Clearing an interval when the component unmounts:

class Timer extends React.Component {
  componentDidMount() {
    this.timer = setInterval(() => {
      console.log('Timer running...');
    }, 1000);
  }

  componentWillUnmount() {
    clearInterval(this.timer);  // Cleanup the interval
    console.log('Timer stopped!');
  }

  render() {
    return <h1>Timer Running</h1>;
  }
}

In this example, componentWillUnmount() clears the interval to prevent it from running after the component is removed from the screen.

With the pivot towards functional components, react component lifecycle is now managed using the useEffect hook.

useEffect
UseEffect is a react hook that allows you run any side effect or reaction after a component renders, re-renders, or before unmounting.
It takes two parameters;

A callback function that contains the reaction or side effect you want to run and
A dependency array that controls when it runs.

useEffect(() => {
  // callback function
}, [dependency array]);

No dependencies: The effect runs after every render.
Empty array []: The effect runs only once, like componentDidMount().
Specific dependency (eg [count]): The effect runs only when that state or prop changes.

Component lifecycle with UseEffect

Component didmount

useEffect(() => {
  console.log('I understand useEffect better!');
}, []);

This will only log on the console once, ie when the component mounts.

Component didupdate

import { useEffect, useState } from 'react';

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

  // This useEffect runs only when 'count' changes
  useEffect(() => {
    console.log(`I read this article ${count} times`);
  }, [count]);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Read it Again</button>
    </div>
  );
}

Component willunmount

useEffect(() => {
  document.addEventListener('mousedown', handleClickOutside);

  return () => {
    document.removeEventListener('mousedown', handleClickOutside);
  };
}, []);

}

In the above code useEffect adds a mousedown event listener to the document.
The event listener runs whenever a user clicks anywhere on the page. It triggers the handleClickOutside function (In the complete code, it checks if the user clicked outside a modal).

When it happens: The event listener is added right after the component renders, just like componentDidMount.
In class components, componentWillUnmount runs right before the component is removed from the DOM. The cleanup function inside the useEffect serves the same purpose here. Right before the component unmounts, React calls the cleanup function to remove it from the DOM.

Why do we need cleanup?
If we don’t remove the event listener, it will continue to run even after the component is unmounted. This could cause memory leaks or unexpected behavior.

Happy Learning!!!