A frontend spike revealed that email validation logic between the backend and frontend was not consistent. The backend depended on a large Mailman regex with additional length checks, while the frontend validation was less restrictive.

Why We Chose to Upgrade to Zod v4

As part of improving consistency, maintainability, and centralizing validation logic across the repo, Zod v4 presented a strong opportunity to modernize how validation is handled across the repository.

The goal was to align frontend validation rules with backend requirements while also reducing technical debt. Migrating to standardized Zod-based validation allowed us to:

• Prevent email addresses accepted on the frontend but rejected by the backend

• Update the email validation regex on the frontend to match backend validation

• Maintain consistent validation behavior across the app

• Reduce manual regex maintenance and duplication

• Centralize email address validation into a reusable shared schema

While the migration was initially motivated by email validation, it quickly became clear that upgrading Zod would provide long-term improvements in developer experience, type safety, and validation reliability.

Unseen Prerequisites That Blocked the Migration

Like many large-scale dependency upgrades, the Zod migration uncovered several prerequisite upgrades that needed to happen first.

When I initially took on on the the project, I discovered our TypeScript version was still on v4.9 while Zod v4 required TypeScript v5.5 or higher. This meant the migration could not happen without first upgrading TypeScript across the repository.

After upgrading TypeScript, additional compatibility issues surfaced with React Hook Form (RHF) and @hookform/resolvers, both required upgrades to support the newer ecosystem.

Adding a bit more complication, our Design System team maintained shared form components that depended on RHF. Their components were running on an older version than what Zod v4 needed to work with, which created a dependency mismatch that prevented a straightforward upgrade.

To resolve this, I collaborated with the Design System team by outlining:

• Why upgrading RHF was necessary for Zod v4 compatibility

• How mismatch impacted validation and form integrations

• The importance of modernizing our ecosystem

Because these shared components were consumed across multiple applications, the upgrade required careful coordination and testing, which extended the migration timeline.

Once the Design System updates were completed and deployed, I was able to successfully install and integrate Zod v4 without additional compatibility issues.

Migration Challenges Inside the Codebase

Once Zod v4 was installed, I quickly realized how loosely validated Zod v3 was compared to v4. Running TypeScript after the upgrade surfaced 80+ type errors across the codebase. While this initially felt overwhelming, a few of the errors highlighted areas where validation logic had been loosely defined or relied on deprecated APIs that included simple updates such as:

• Replacing message with error

• Replacing invalid_type_error and required_error with error

• Replacing import { schema } from “zod” from import { z } from “zod”

Zod v4 Runs a Stricter Program

Beyond syntax updates, Zod v4 introduced noticeably stricter type enforcement. In several files, schemas that compiled successfully now failed due to mismatches between expected and actual data shapes. The stricter checks surfaced validation issues such as:

• Optional values being treated as required

• Inconsistent handling of nullable vs optional fields

• Incorrect union definitions

• Even found a case where a value was spelled incorrectly but still passed in v3!

Zod v4 also refined how schemas are composed and extended. Several chained validation patterns that worked in v3 required restructuring to align with the new composition behavior.

In particular, complex validation scenarios involving:

• .refine()

• .superRefine()

• Schema merging and extension

• transform and coerce changed to type unknown

Resolver and Form Integration Updates

Because Zod was tightly integrated with React Hook Form, upgrading Zod required verifying compatibility with the latest resolver versions. Schema changes occasionally affected how form errors were mapped and surfaced in UI components.

In some cases, validation behavior subtly changed due to stricter typing or updated resolver expectations, requiring regression testing across form-heavy workflows.

Key Lesson

Large dependency migrations rarely fail because of the library upgrade itself. They expose inconsistencies, technical debt, and architectural drift that accumulate over time.

Zod v4 did exactly that for our codebase. While the migration required significant effort, it resulted in stronger type guarantees, more consistent validation behavior, and a cleaner foundation for future development.

Each node of the linked list consists of data and a next pointer. Since (unlike the array) a linked list is not stored contiguously, the purpose of the next pointer is to provide a reference or link to the next node in the sequence. Hence the term "linked" list.

As seen in the image above, the last node's next pointer always points to null. This is how we know we've reached the end of the list.

Head is the name given to the first node in the list Tail is the name given to the last node in the list

Pros of linked list

• insertion and deletion are done in O(1)
• not stored contiguously in memory
• dynamic (linked lists grow/shrink at runtime depending on its size)

Cons of linked list

• uses more memory than an array
• traversal is more time consuming compared to an array since there is no direct (index) access
• in a SLL, reverse traversing is not possible
• random access is not possible because there are no indices

Stepping away from linked lists for a while, when we think of the array in JavaScript, there are methods that allow us to interact and modify the array. Think, push(), shift(), etc. Similarly, there are linked list methods allowing us the ability to interact with and modify it. The only difference is that they're not built-in; we have to create them ourselves.

These methods include

• addToEnd() or push(): adds a node to the end of the list
• addToStart() or unshift(): adds a node to the start of the list
• deleteFromEnd() or pop(): deletes a node from the end of the list
• deleteFromStart() or shift(): deletes a node from start of the list
• length(): returns the length of the linked list

Implementing a linked list node:

Remember, a node consists of data (val) and a next pointer which is initialized to null since the linked list will be empty when we start.

class Node {
  constructor(val) {
    this.value = val;
    this.next = null;
  }
}

Implementing a linked list:

Remember, the first node is called the head and the last node is called the tail. We have instant access to the first and last node which is why insertion and deletion is O(1). Also, the linked list will be empty initially, so both head and tail are initialized with null.

class LinkedList {
  constructor(){
    this.head = null
    this.tail = null
    this.length = 0;
  }

  addToEnd(val) {
    let node = new Node(val)
    if(!this.head) {
      this.head = node
      this.tail = node
    }
    this.tail.next = node
    this.tail = node

    this.length++
    return this;
  }

  deleteFromEnd() {
    if(!this.head) return undefined
    let curr = this.head
    let newTail = curr

    while(curr.next) {
      newTail = curr
      curr = curr.next
    }
    newTail.next = null
    this.tail = newTail

    this.length--

    if(this.length === 0) {
      this.head = null;
      this.tail = null
    }
    return curr;
  }

  addToStart(val) {
    let node = new Node(val)

    if(!this.head) {
      this.head = node
      this.tail = node
    }
    node.next = this.head
    this.head = node

    this.length++

    return this;
  }

  deleteFromStart() {
    if(!this.head) return undefined

    let curr = this.head
    this.head = curr.next

    this.length--

    if(this.length === 0) {
      this.head = null
      this.tail = null
    }
    return null
  }

}
// creating a new instantiation of our linked list class called list.

let list = new LinkedList();
list.addToEnd(21)
list.addToEnd(24)
list.addToEnd(35)
list.addToStart(99)
list.deleteFromEnd()
console.log(list)

What is complexity analysis

Prior to diving into computer science, I used to think all code weighed the same, meaning, all code completed the same task within the same timeframe. Lo and behold, complexity analysis has proven this is not the case! Although two different programs given the same number of inputs provide the same output, one typically gets the job done more efficiently. So, to put it simply, complexity analysis is the method by which we measure this efficiency.

What makes code efficient

Now, what exactly is efficiency? Efficiency is broken down between time and space. Key things to understand:

Time complexity: measures the amount of time it takes a program to complete. The faster your code, the better.

Space complexity: measures the amount of space (memory) a program takes up as it completes. The less space your code consumes, the better.

Both are important but we are generally more concerned with time complexity.

Big O analysis

If complexity analysis is the method by which we measure the efficiency of code, we can then think of Big O as the unit by which we do this measuring. Big O analysis is used to rank an algorithm's performance in relation to the growth of input size. In other words, as our input size gets closer to an infinite number (obviously very large), how efficient does our algorithm remain?

Big O notation

Note: n represents input size

O(1) - Constant: No matter the size of n, our algorithm will take the same amount of time to execute.

O(log n) - Logarithmic: Time goes up linearly, while n goes up exponentially. Meaning, if it takes 1 second to compute 10 elements, it will take 2 seconds to compute 100 elements, etc.

O(n) - Linear: Our algorithm's performance will grow in direct proportion as our input. For example, if it takes 1 second to compute 1 element, it will take 2 seconds to compute 2 elements, 5 seconds to compute 5 elements, and so on.

O(n log n) - Loglinear: Algorithms that repeatedly divide a set of data in half, and then process those halves independently.

O(n²) - Quadratic: As the size of n increases, our algorithm's time to complete will increase exponentially.

We won't cover the others in the chart because as you can see, they're no better than the ones we've already covered anyway so if you ever find yourself in red, it's better to find a better solution to the problem at hand.

Calculating Big O

Let's calculate the Big O solution to Two Sum. Given an array, we must find the two numbers that add up to a given target. Our result should return their index, if there is no sum, return an empty array.

This solution utilizes a brute force approach.

1. function twoSum(arr, target){
2.     for(let i=0; i < arr.length; i++) {
3.         for(let j=i+1; j < arr.length; j++) {
4.             if(arr[i] + arr[j] === target) return [arr[i],arr[j]]
5.         }
6.     }
7.     return []
8. }

Line 2: This for loop traverses our arr array. Since it loops n times for each n element in our array, this line runs in O(n).

Line 3: This second for loop will always run one index ahead of the first loop. This way it's able to sum the numbers of index 1 and index 2 to check if they add to our target. So, for every item in the array, the second loop will traverse that one item n times in order to compare all numbers to that one number before moving to the second index and doing the same all over again. In other words, these two loops are executed in n x n resulting in O(n^2).

Line 4: This line will take the same time to execute no matter our input size. It's O(1).

Line 7: This is a simple statement not relying on n. It also runs in O(1).

Final verdict: Time: O(n^2) | Space: O(1) O(n^2) dominates all other runtimes when it comes to the worst-case scenario, therefore this solution runs in O(n^2).

This next solution utilizes the two-pointers technique.

1. function twoSum(arr, target) {
2.     arr.sort((a,b) => a-b)
3.     let start = 0;
4.     let end = arr.length-1
5.    
6.     while(start < end) {
7.         if (arr[start] + arr[end] === target) return [arr[start],arr[end]]
8.         else if ((arr[start] + arr[end]) < target) start++;
9.         else end--;
10.     }
11.    return []
12. }

line 2: The sort function traverses the array in order to sort it in increasing order. This line runs in O(n).

line 3: Initiating the start variable runs in O(1).

line 4. Initiating the end variable runs in O(1).

line 6. This while loop runs as long as start is less than end. For each loop, we will traverse the array checking to see if our loop statement is still truthy. This line runs in O(n).

line 7-8: These statements run in O(1).

Final verdict: Time: O(n) | Space: O(1)

O(n) dominates all other runtimes in this solution when it comes to the worst-case scenario, therefore this solution runs in O(n). This solution is obviously far superior to the first because it is more efficient.

Summary

1. Time complexity + space complexity = code efficiency

2. Time complexity measures the amount of time a program takes to complete. The faster your code, the better.

3. Space complexity measures the amount of space (memory) a program takes up as it completes. The less space, the better.

4. Big O is used to rank an algorithm's performance in relation to the growth of input size. As our input gets larger, how efficient does our code remain?

5. Study your big O notations.

At the time, I’d estimate that about 95% of the code snippets I found online (StackOverflow, YouTube tutorials, CodeSandbox, etc.) to help me learn React were written using class components. That presented a dilemma.

In the end, I decided it would be beneficial to learn both. And so I did.

What Are Class Components?

Before React v16.8, class components were the primary way React managed state in applications. State is defined as any piece of data capable of changing (via user actions or interactions), causing the UI to re-render with updated data.

In class components, state is typically initialized inside the constructor, as shown in the snippet below. The constructor() is a method that is automatically called when a class instance is created. Additionally, because we are extending the React class (React.Component), super() must be called. This invokes the constructor of the parent class and allows the subclass to function properly.

In short:

• Use constructor() when creating your own classes.

• When extending an existing class, always call super() inside the constructor.

The this keyword refers to the current class instance. Inside the constructor, this refers to the component instance being created. Inside methods like handleNameChange and handleSubmit, this still refers to the component instance. Because arrow functions do not create their own this context, they safely allow access to component state using this.setState().

import React from "react";

export default class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      tempName: "",
      name: "Jane Doe",
    };
  }

  handleNameChange = (e) => {
    this.setState({ tempName: e.target.value });
  };

  handleSubmit = (e) => {
    e.preventDefault();
    this.setState({ name: this.state.tempName, tempName: "" });
  };

  render() {
    return (
      <div className="App">
        <h1>Hello, {this.state.name}!</h1>
        <h2>If you want to change your name, enter it below.</h2>
        <input
          type="text"
          name="name"
          value={this.state.tempName}
          onChange={this.handleNameChange}
        />
        <button type="submit" onClick={this.handleSubmit}>
          Submit
        </button>
      </div>
    );
  }
}

What Are Functional Components?

Originally, functional components were used for simple, stateless presentational components because they lacked the ability to manage state like class components. With the release of React v16.8, Hooks were introduced, allowing functional components to manage state and side effects.

Hooks are functions that allow developers to use state and lifecycle features inside function components. A common convention is that Hooks start with the prefix use.

To convert the class component above into a stateful functional component, we can use the useState Hook. Similar to how the constructor holds state in class components, useState manages state inside functional components.

import React, { useState } from "react";

export default function App() {
  const [name, setName] = useState("Jane Doe");
  const [tempName, setTempName] = useState("");

  const handleNameChange = (e) => {
    setTempName(e.target.value);
  };

  const handleSubmit = (e) => {
    e.preventDefault();
    setName(tempName);
    setTempName("");
  };

  return (
    <div className="App">
      <h1>Hello, {name}!</h1>
      <h2>If you want to change your name, enter it below.</h2>
      <input
        type="text"
        name="name"
        value={tempName}
        onChange={handleNameChange}
      />
      <button type="submit" onClick={handleSubmit}>
        Submit
      </button>
    </div>
  );
}

In this article, I've used just one hook for simplicity. Check out the first article in the React Hooks series: React Hooks Pt. I - useState.

Numerous times, I found myself discouraged when I couldn’t complete certain projects because I struggled to understand how to convert class components into functional ones. So aside from the obvious syntax differences, what truly distinguishes these two component types?

In short: not much.

Functional components have always been a core part of React. However, before version 16.8, they could not manage state. Developers were required to use class components for state management. With the introduction of Hooks in React v16.8, functional components gained the ability to manage state and lifecycle behavior. This innovation removed the need to rely exclusively on class components.

Conclusion

Both functional and class components ultimately produce the same results. The choice between them largely depends on your project requirements and team preferences. That said, functional components with Hooks have become the modern standard due to their simplicity, readability, and flexibility.