DEV Community: mmvergara

Free Ai Supabase Seeder

mmvergara — Fri, 02 May 2025 16:11:47 +0000

🪴 - SupaSeeder - 🪴

Using AI to Generate Seed Data for Supabase

Every developer knows the importance of having good seed data for fast testing and development. Manually crafting SQL queries to populate your database with realistic data can be tedious and error-prone, especially when dealing with complex relationships between tables.

SupaSeeder connects to your Supabase instance, extracts the database schema, then you can either generate SQL insert statements or optimized prompts to use with any AI model to generate the seed data you need.

Try it out online at supaseeder.vercel.app 🔥

⚙️ How It Works

Provide Supabase URL & Anon Key

Connects to your database and reads the schema.
Write a prompt

Describe the data you want (e.g. "10 users with 5 posts each").
Pick mode

Prompt Mode: Get optimized prompts to use with any AI (ChatGPT, Claude, etc.)
Direct Mode: Get complete SQL queries generated using OpenAI

Get SQL output Copy & paste to your SQL editor or Supabase SQL Runner.

🛠️ Setup Locally

Method 2: Run Locally

Clone the repository:

   git clone https://github.com/mmvergara/supaseeder.git
   cd supaseeder

Install dependencies:

   npm install
   # or
   yarn install
   # or
   pnpm install

Start the development server:

   npm run dev
   # or
   yarn dev
   # or
   pnpm dev

Why Are Buttons Losing the Pointer Cursor? ft. ShadCn

mmvergara — Mon, 21 Apr 2025 23:37:13 +0000

Developers working with ShadCN v4 and Tailwind CSS v4 noticed something odd: buttons no longer showed the pointer cursor on hover. For many, this broke expectations. Clicking a button without the familiar hand cursor felt... off.

A github issue was opened but the change wasn’t a bug. It was a deliberate design choice buttons now use the default cursor by design.

The Fix

Workarounds by @aow3xm and @Koda-Pig

@layer base {
  button:not([disabled]),
  [role="button"]:not([disabled]) {
    cursor: pointer;
  }
}

This custom CSS restores expected behavior, with added care to avoid pointer cursors on disabled buttons.

The reason.. i think.

A UX StackExchange thread explains: originally, GUI buttons relied on visual affordances (like shadows) rather than cursors to suggest interactivity. The pointer cursor was reserved for hyperlinks. Even today, native buttons in OSs typically don’t change to a hand cursor.

But web apps are not traditional GUIs they’re hybrid interfaces that mix form and function. Users now expect visual cues like cursor changes for all clickable elements.

TL;DR: Tailwind v4 removed cursor: pointer from buttons by default. It’s intentional, rooted in legacy UX logic. But if your users expect a hand cursor, just add a small CSS override.

I Promise.js for dummies

mmvergara — Wed, 02 Apr 2025 00:06:36 +0000

Think of a promise like ordering food at a restaurant you don’t get the meal immediately, but you do get a receipt (the promise) that guarantees your food will come (or you’ll get an explanation if it doesn’t).

The Three States of a Promise

A promise can be in one of three states:

Pending – Waiting (your order is being cooked).
Fulfilled – Success (food is served).
Rejected – Failed (the kitchen ran out of ingredients).

Once a promise is settled (either fulfilled or rejected), it can’t change states. This is defined in the ECMAScript spec (ECMA-262, section 25.4).

Why Promises Beat Callbacks

Before promises, we had callback hell nested callbacks that made code unreadable. Promises flatten this:

// Callback Hell
getUser(userId, (user) => {
  getPosts(user, (posts) => {
    getComments(posts[0], (comments) => {
      console.log(comments);
    });
  });
});

// With Promises
getUser(userId)
  .then((user) => getPosts(user))
  .then((posts) => getComments(posts[0]))
  .then((comments) => console.log(comments))
  .catch((error) => console.error("Something broke:", error));

The Magic of `.then()` and `.catch()`

.then() handles success (like unwrapping the receipt to get your food).
.catch() handles errors (like the waiter telling you they’re out of steak).

But here’s a gotcha: .then() also returns a new promise, which means you can chain them infinitely (or until your code becomes unreadable).

Async/Await: Promises in Disguise

Under the hood, async/await is just syntactic sugar for promises.

async function fetchData() {
  try {
    const user = await getUser(userId);
    const posts = await getPosts(user);
    const comments = await getComments(posts[0]);
    console.log(comments);
  } catch (error) {
    console.error("Oops:", error);
  }
}

A Niche Example

Promises run in the microtask queue, which has higher priority than the regular callback queue. This means:

console.log("Start");

setTimeout(() => console.log("Timeout"), 0);

Promise.resolve().then(() => console.log("Promise"));

console.log("End");

// Output order:
// Start → End → Promise → Timeout

Why? Because the microtask queue (promises) gets processed before the next event loop tick.

Promises are JavaScript’s way of saying, "I promise to handle this async task cleanly." This is one of the most important concepts in modern JavaScript, so make sure you understand it well!

Extra tip: Promise.all()

When fetching data asynchronously, you might run multiple independent operations. Consider this example:

const user = await getUser(userId);
const posts = await getPosts(userId);

Here, getUser runs first, and only after it completes does getPosts start. However, since getPosts only requires userId not the user data itself there's no reason to wait. Running them sequentially wastes time.

A better approach is to execute them concurrently using Promise.all():

const [user, posts] = await Promise.all([getUser(userId), getPosts(userId)]);

This allows both getUser and getPosts to run simultaneously, significantly improving performance. Use Promise.all() whenever you have multiple independent asynchronous tasks to speed up execution!

The magic of Debouncing in creating reactive Search Bars

mmvergara — Tue, 01 Apr 2025 09:53:24 +0000

Let's just get straight to the point,, ye?

Imagine a search bar that fetches results as you type. Without debouncing, every keystroke fires an API call flooding your server and slowing things down. Debouncing ensures the search only triggers after you stop typing for a set time. This is one of the best use cases for debouncing.

function debounce(func, delay) {
  let timeoutId;
  return function (...args) {
    clearTimeout(timeoutId); // Reset the timer
    timeoutId = setTimeout(() => func.apply(this, args), delay);
  };
}

// Usage:
const search = debounce((query) => {
  console.log(`Searching for: ${query}`);
}, 300);

search("a"); // Ignored
search("ap"); // Ignored
search("app"); // Only this runs after 300ms

Each keystroke resets the delay timer. The function only runs when typing pauses for 300ms.

Debouncing is everywhere resize events, scroll handlers, button clicks to prevent double submissions.

Javascript Prototypal Inheritance once and for all

mmvergara — Mon, 03 Feb 2025 02:28:30 +0000

Prototypal inheritance is one of JavaScript's core concepts, It is essential to understand how it works.

The Family Tree

In JavaScript, every object has a hidden [[Prototype]] property that links it to another object. This is like a child inheriting traits from a parent. When you try to access a property or method on an object, JavaScript will look for it on the object itself. If it doesn’t find it it will check the object’s prototype, and so on, up the chain.

const parent = {
  greet() {
    console.log("Hello from the parent!");
  },
};

const child = Object.create(parent);
child.greet(); // Logs: "Hello from the parent!"

In this example, child doesn’t have its own greet method, but it inherits it from parent. This is prototypal inheritance in action.

The ECMAScript Spec

According to the ECMAScript specification, the [[Prototype]] property is what enables this inheritance. When you create an object using Object.create(), you’re explicitly setting its prototype. If you don’t specify a prototype, the object will inherit from Object.prototype by default.

Let’s say you’re building a game with different types of characters. You can use prototypal inheritance to share common properties and methods.

const character = {
  health: 100,
  attack() {
    console.log(`${this.name} attacks for ${this.damage} damage!`);
  },
};

const warrior = Object.create(character);
warrior.name = "Conan";
warrior.damage = 20;

const mage = Object.create(character);
mage.name = "Gandalf";
mage.damage = 15;

warrior.attack(); // Logs: "Conan attacks for 20 damage!"
mage.attack(); // Logs: "Gandalf attacks for 15 damage!"

Here, both warrior and mage inherit the attack method from character, but they have their own unique properties like name and damage.

The Chain

The prototype chain is like a ladder. When you try to access a property or method, JavaScript climbs up the ladder until it finds what it’s looking for or reaches the top (which is null). If it doesn’t find the property, it returns undefined.

For example:

console.log(warrior.health); // 100 (inherited from character)
console.log(warrior.mana); // undefined (not found in the chain)

Why Prototypal Inheritance?

Let's say where going to create a function that returns an object.

function createCar(carName) {
  return {
    name: carName,
    getName() {
      return this.name;
    },
  };
}

const car1 = createCar("Tesla");
const car2 = createCar("Ford");

At first glance, this approach might seem acceptable. However, if we create multiple car objects, each will have its own copy of the getName method. While the properties are unique to each object, duplicating the method for every instance is inefficient since the method logic remains the same across all objects. Ideally, methods should be shared among instances to avoid unnecessary duplication.

TLDR: every car object created has its own copy of the getName method, which wastes memory.

To avoid duplication, we can use prototypal inheritance to share methods between objects. Here's a cleaner implementation using a constructor function and prototype:

function Car(carName) {
  this.name = carName;
}

Car.prototype.getName = function () {
  return this.name;
};

const car1 = new Car("Tesla");
const car2 = new Car("Ford");

console.log(car1.getName()); // Tesla
console.log(car2.getName()); // Ford

Now the getName method is shared between all Car instances. This way, we avoid duplicating the method for each object, making our code more memory-efficient.

Congratulations! Now you know what actually happens when you use the class syntax in JavaScript. Under the hood, JavaScript uses prototypal inheritance to link the prototype of the Car class to its methods. Here's the same example using the class syntax:

class Car {
  constructor(carName) {
    this.name = carName;
  }

  getName() {
    return this.name;
  }
}

const car1 = new Car("Tesla");
const car2 = new Car("Ford");

console.log(car1.getName()); // Tesla
console.log(car2.getName()); // Ford

Prototypal inheritance is a core concept in JavaScript that helps you write efficient and maintainable code. By sharing methods via the prototype chain (or using class), you avoid duplication and keep your code clean. Whether you use constructor functions, Object.create, or class, the goal is the same: share behavior, not memory.

WTF is 'this' in Javascript

mmvergara — Sat, 01 Feb 2025 01:01:03 +0000

The value of this is determined by how a function is called, not where it's defined. This is what the ECMAScript spec calls "runtime binding." Think of it like a game of hot potato whoever's holding the potato (calling the function) determines what this becomes.

Here's a tricky example that often confuses us developers.

const user = {
  name: "John",
  greet() {
    const sayHi = () => {
      console.log(`Hi, ${this.name}!`);
    };
    setTimeout(sayHi, 1000);
  },
};

user.greet(); // After 1 second: "Hi, John!"

In this case, the arrow function sayHi captures this from its surrounding scope. If we had used a regular function instead, this would've been the global object (or undefined in strict mode), and this.name would've been undefined. aha! another thing to look out for when using this, welcome to js!

Arrow Functions and "this"

Arrow functions are special. Unlike regular functions, they don't have their own this. Instead, they inherit this from their parent scope. It's like they're saying "whatever this meant where I was created, that's what I'll use."

Here's something that might surprise you.

const obj = {
  value: 42,
  getValue: () => {
    console.log(this.value);
  },
};

obj.getValue(); // undefined

Even though getValue is a method on obj, the arrow function doesn't get this from the object. Instead, it inherits this from where the arrow function was created (probably the global scope or module scope), againg welcome to js!

The Spec Says...

According to the ECMAScript specification, when a function is called, an execution context is created. This context includes a ThisBinding component that determines what this will be inside the function. The rules for setting ThisBinding are quite specific:

For constructor functions (called with new), this is the newly created object
For methods, this is the object that owns the method
For arrow functions, this is inherited from the enclosing scope
For plain function calls, this is either the global object or undefined (in strict mode)

Understanding these rules helps you predict what this will be in any situation.

A Real World Example... i think

Here's a pattern you might see in real code:

class EventEmitter {
  constructor() {
    this.events = {};
    // Using an arrow function to preserve 'this'
    this.emit = (event, ...args) => {
      const handlers = this.events[event] || [];
      handlers.forEach((handler) => handler.apply(this, args));
    };
  }

  on(event, handler) {
    this.events[event] = this.events[event] || [];
    this.events[event].push(handler);
  }
}

const emitter = new EventEmitter();
emitter.on("test", function () {
  console.log(this === emitter); // true
});
emitter.emit("test");

In this example, we use both arrow functions and regular functions strategically. The arrow function for emit ensures this always refers to the EventEmitter instance, while the handler function gets its this bound to the emitter through apply.

Remember, this isn't magic it's just a parameter that JavaScript passes to functions in a special way.

Javascript IIFEs - Why They were a Big Deal

mmvergara — Thu, 30 Jan 2025 23:55:48 +0000

Have you ever seen code like this?

(function () {
  console.log("Hello from an IIFE!");
})();

That’s an IIFE, or Immediately Invoked Function Expression. It’s a function that runs as soon as it’s defined. They're a great way to create isolated scopes in JavaScript and avoid polluting the global scope.

The syntax might look a little weird at first, but it’s actually pretty simple. You define a function, wrap it in parentheses, and then add () at the end to call it immediately:

(function () {
  // Your code here
})();

The outer parentheses are crucial—they turn the function into an expression instead of a declaration. This is important because JavaScript doesn’t let you immediately invoke a function declaration. For example, this would throw an error:

function() {
  console.log("This won't work!");
}();

By wrapping the function in parentheses, you’re telling JavaScript, “Hey, treat this as an expression, not a declaration.”

Why?

IIFEs were super popular back in the day (think pre-ES6) because they helped avoid polluting the global scope. IIFEs let you create a temporary scope where variables could live without leaking into the global space.

Here’s an example:

(function () {
  var secret = "I'm hidden!";
  console.log(secret); // "I'm hidden!"
})();

console.log(secret); // ReferenceError: secret is not defined

In this example, secret is only accessible inside the IIFE. Once the IIFE runs, secret is gone. This is super useful for keeping your code clean and avoiding conflicts with other scripts.

Before block-scoped variables (let and const), the only way to create a new scope was with a function. To think that IIFE's are only popular because we didn't have block-scoped variables is kinda sad lol.

Let’s say you’re building a module that needs to initialize some data but doesn’t want to expose it to the outside world. You could use an IIFE to encapsulate that logic:

const counter = (function () {
  let count = 0;

  return {
    increment: function () {
      count++;
      console.log(count);
    },
    reset: function () {
      count = 0;
      console.log("Counter reset!");
    },
  };
})();

counter.increment(); // 1
counter.increment(); // 2
counter.reset(); // "Counter reset!"

Here, the count variable is private. The only way to interact with it is through the increment and reset methods returned by the IIFE.

The ECMAScript spec doesn’t explicitly mention IIFEs, but it does explain how function expressions work. According to the spec, a function expression is evaluated as part of the larger expression it’s contained in. When you add () at the end, you’re invoking that function expression immediately.

With the introduction of block-scoped variables (let and const) and modules in ES6, IIFEs aren’t as necessary as they used to be. But they’re still handy in certain situations, like when you need to create a quick, isolated scope or when you’re working in an older codebase.

More on Solidifying Javascript Foundations
More on Solidifying Javascript Foundations

Javascript Hoisting - What Moves and What Stays

mmvergara — Wed, 29 Jan 2025 23:42:53 +0000

Think of hoisting like setting up a stage before a play. Before the code runs (during the "creation phase"), JavaScript moves all declarations to the top of their scope like stagehands moving props into place before the curtain rises. The only catch is that the declarations are moved, not the initializations.

According to the ECMAScript specification, this behavior is actually part of how JavaScript creates what's called the "lexical environment" during the creation phase. But let's not get too technical just remember that JavaScript does a "pre-scan" of your code before running it.

`var` Hoisting

console.log(x); // Outputs: undefined
var x = 5;
console.log(x); // Outputs: 5

In this example, the var declaration var x is hoisted to the top of the scope, but the initialization x = 5 is not. This is why the first console.log(x) outputs undefined instead of throwing an error. The variable x exists, but it hasn't been assigned a value yet.

`let` and `const` in the Temporal Dead Zone (TDZ)

console.log(y); // Throws a ReferenceError: Cannot access 'y' before initialization
let y = 10;
console.log(y); // Outputs: 10

In this example, the let declaration let y is hoisted, but it is placed in the Temporal Dead Zone (TDZ) until the line where it is initialized. Trying to access y before its initialization results in a ReferenceError. This behavior is different from var, which would simply return undefined in a similar situation.

this also includes anything that is declared using let or const including functions ofcourse

The TDZ (Temporal Dead Zone)

Speaking of the temporal dead zone, this is where let and const declarations live before they're initialized. Unlike var which returns undefined when accessed before initialization, these modern declarations will throw an error. The ECMAScript spec calls this behavior "temporal dead zone semantics", but I just call it "JavaScript keeping us honest".

A slightly harder example

function setupEventHandler() {
  handleClick(); // Works!

  const config = {
    debug: true,
  };

  function handleClick() {
    if (config?.debug) {
      // Undefined!
      console.log("Debug mode");
    }
  }
}

setupEventHandler();

See what happened there? The function declaration handleClick is hoisted, so we can call it early. But that object config? It stays right where it is. This is why accessing config inside handleClick gives us undefined, we're trying to read the script before its ready.

The Class Gotcha

Class hoisting doesn't work quite the same way.

const dog = new Animal(); // Throws an error!

class Animal {
  constructor() {
    this.type = "mammal";
  }
}

While classes are hoisted, they stay in a "temporal dead zone" until their definition is evaluated. This means you can't access them before they're declared.

Just remember declarations are moved to the top, but initializations stay put.

Currying in JavaScript

mmvergara — Wed, 29 Jan 2025 01:46:28 +0000

before tackling this topic make sure you have a good understanding about closures and higher order functions in general.

Currying is the process of transforming a function that takes multiple arguments into a sequence of functions, each taking one argument at a time. This allows you to create more specialized and reusable functions.

Think of currying like ordering a custom pizza: instead of specifying all your toppings at once, you add them one by one, building up to the final result.

Take a look at this simple example:

// Non-curried function
function multiply(a, b, c) {
  return a * b * c;
}

console.log(multiply(2, 3, 4)); // 24

// Curried version
function curriedMultiply(a) {
  return function (b) {
    return function (c) {
      return a * b * c;
    };
  };
}

console.log(curriedMultiply(2)(3)(4)); // 24

In the curried version, curriedMultiply takes one argument at a time, returning a new function until all arguments are provided. This might seem like extra work, but it opens up a world of flexibility.

What about the use case?

Currying is like having a toolkit where each tool does one thing really well. It allows you to create partially applied functions—functions that are pre-loaded with some arguments and ready to take the rest later. This is especially useful for reusability and composition.

take a look:

// Curried function to calculate shipping costs
function calculateShippingCost(baseCost) {
  return function (weight) {
    return function (distance) {
      return baseCost + weight * 2 + distance * 0.5;
    };
  };
}

const standardShipping = calculateShippingCost(10); // Base cost of $10
const heavyItemShipping = standardShipping(20); // Weight of 20kg

console.log(heavyItemShipping(100)); // Shipping cost for 100km: 10 + (20 * 2) + (100 * 0.5) = 80

calculateShippingCost is a curried function that lets you create specialized shipping calculators. You can reuse standardShipping and heavyItemShipping for different scenarios.

Another example to solidify stuff.

// Curried function to create a logger
function createLogger(prefix) {
  return function (message) {
    return function (timestamp) {
      return `[${timestamp}] ${prefix}: ${message}`;
    };
  };
}

const errorLogger = createLogger("ERROR");
const warnLogger = createLogger("WARN");

console.log(errorLogger("File not found")(new Date().toISOString()));
// [2025-10-15T12:00:00Z] ERROR: File not found

console.log(warnLogger("Low disk space")(new Date().toISOString()));
// [2025-10-15T12:00:00Z] WARN: Low disk space

In this example, createLogger is a curried function that generates specialized loggers. You can create errorLogger and warnLogger with different prefixes, making your logging system more flexible and reusable.

We should understand `==` more, than not using it at all.

mmvergara — Tue, 28 Jan 2025 09:24:08 +0000

If you’ve ever wondered why == behaves the way it does in JavaScript, you’re not alone. The == operator, also known as the loose equality operator, has a secret: it prefers numeric comparisons. This might sound odd at first, but once you understand how it works, you’ll see why this behavior exists and how to use it effectively.

The Numeric Preference

According to the ECMAScript specification, the == operator follows the Abstract Equality Comparison Algorithm. This algorithm has a clear bias: it prefers to convert values to numbers before comparing them. Here’s how it works:

If one value is a number and the other is a string, the string is converted to a number.
If one value is a boolean, it’s converted to a number (true becomes 1, false becomes 0).
If one value is an object (like an array), it’s converted to a primitive using the ToPrimitive operation, and the process repeats.

This means that when you use ==, JavaScript is often doing more work under the hood than you might realize. It’s not just comparing values it’s trying to make them numbers first.

Why Does This Matter?

Understanding this numeric preference can help you predict how == will behave in different scenarios. For example:

console.log(5 == "5"); // true

Here, the string "5" is converted to the number 5, and the comparison succeeds. But if you use ===, the types must match, so it returns false.

This behavior isn’t random it’s designed to make certain comparisons easier. For instance, if you’re comparing a number to a string representation of that number, == can handle it without requiring explicit type conversion.

When Does `==` Make Sense?

While === is generally safer, there are cases where == can be useful. For example, if you’re working with data that might come in as either a string or a number (like user input from a form), == can simplify your code:

function isAnswerCorrect(userInput, correctAnswer) {
  return userInput == correctAnswer;
}

console.log(isAnswerCorrect("42", 42)); // true

Here, == allows the function to handle both string and number inputs without additional type-checking logic.

The Bigger Picture

The key takeaway is that == isn’t inherently bad, it’s just a tool. The real issue arises when you use it in ways that don’t make sense, like comparing a number to an array:

console.log(42 == [42]); // true

This works because the array is converted to a string ("42"), which is then converted to a number (42). But just because it works doesn’t mean it’s a good idea. The problem here isn’t == it’s the nonsensical comparison.

The == operator in JavaScript has a numeric preference, and understanding this can help you write better, more predictable code. While === is often the safer choice, == can be useful in specific scenarios where type coercion is intentional and well-understood, we have to be open to the idea of using it because it is part of the language.

JavaScript NaN Quirks: Features, Not Flaws.

mmvergara — Mon, 27 Jan 2025 10:15:30 +0000

NaN, or "Not-a-Number," is one of those JavaScript quirks that can trip you up if you're not paying attention. But here's the thing: NaN isn't just a quirky value—it's a sentinel value that represents an invalid number. It's not the absence of a number, and it's definitely not zero. It's a specific, intentional signal that something went wrong in a numeric operation. (or i don't know, i didn't create the language)

What is NaN?

NaN comes from the IEEE 754 spec, which defines how numbers work in JavaScript. It's not a bug or a mistake—it's a deliberate part of the language. Think of NaN as a red flag that says, "Hey, this operation didn't make sense mathematically."

For example:

console.log(Math.sqrt(-1)); // NaN

You can't take the square root of a negative number (at least not in real numbers), so JavaScript gives you NaN. It's like asking, "What's the color of happiness?"—it's a question that doesn't have a meaningful answer.

NaN's Quirky Behavior

Here's where things get weird. NaN is the only value in JavaScript that is not equal to itself:

console.log(NaN === NaN); // false

This isn't a bug—it's by design. According to the ECMAScript spec, NaN is "unordered" with respect to other values, including itself. This means you can't use === to check for NaN. Instead, you need to use Number.isNaN():

console.log(Number.isNaN(NaN)); // true
console.log(Number.isNaN("Hello")); // false

Why NaN is a Number

Here's the weird thing. NaN is technically a number type. Yes, you read that right. The typeof NaN is "number". This is because NaN is part of the IEEE 754 spec, which defines numeric operations. When a numeric operation fails, it doesn't make sense to return undefined, null, or -1—those aren't numbers. Instead, JavaScript returns NaN, which is still a number, just an invalid one.

Example

Let's say you're building a function to calculate the average of an array of numbers. What happens if the array contains non-numeric values?

function calculateAverage(arr) {
  const sum = arr.reduce((acc, val) => acc + val, 0);
  return sum / arr.length;
}

console.log(calculateAverage([1, 2, "three", 4])); // NaN

Here, the string "three" can't be added to the sum, so the result is NaN. This is a great example of how NaN can sneak into your code and cause unexpected behavior.

Despite all of this weirdness, NaN is a powerful tool. It's the only value that makes sense to return when a numeric operation fails, we have to learn how to work with the language.

NaN is a unique and important concept in JavaScript. It's not just a value—it's a signal that something went wrong in your calculations.

Unraveling the "===" of javascript

mmvergara — Sun, 26 Jan 2025 21:56:20 +0000

The behavior of the strict equality operator (===) is defined in the ECMAScript specification under the section Strict Equality Comparison. Here’s a breakdown of how it works, step by step:

The Algorithm for `===`

When you use ===, JavaScript follows this algorithm to determine if two values are equal:

Check if the types are the same:

If the types of the two values are different, return false.
If the types are the same, proceed to the next step.

Compare the values based on their type:

Numbers:
- If both values are NaN, return false (yes, NaN === NaN is false!).
- If the numbers have the same numeric value, return true.
- If one value is +0 and the other is -0, return true (they are considered equal).
Strings:
- If both strings have the same sequence of characters, return true.
- Otherwise, return false.
Booleans:
- If both values are true or both are false, return true.
- Otherwise, return false.
Objects (including arrays and functions):
- If both values reference the same object in memory, return true.
- Otherwise, return false.
null and undefined:
- null === null is true.
- undefined === undefined is true.
- null === undefined is false (they are different types).

Why `NaN === NaN` is `false`

This is a common point of confusion. According to the spec, NaN (Not-a-Number) is defined as not equal to itself. This is because NaN represents an invalid or undefined numeric result, and it doesn’t make sense to compare two invalid results as equal.

For example:

NaN === NaN; // false

If you need to check if a value is NaN, use Number.isNaN() or Object.is():

Number.isNaN(NaN); // true
Object.is(NaN, NaN); // true

Why `+0 === -0` is `true`

The spec treats +0 and -0 as equal because, in most cases, they behave the same way in mathematical operations. However, there are rare scenarios where they differ (e.g., 1 / +0 is Infinity, while 1 / -0 is -Infinity). If you need to distinguish between them, use Object.is():

Object.is(+0, -0); // false

Objects and Reference Equality

When comparing objects (including arrays and functions), === checks if they reference the same object in memory. This is why two objects with identical contents are not considered equal:

const obj1 = { name: "Alice" };
const obj2 = { name: "Alice" };
obj1 === obj2; // false (different objects)

But if two variables point to the same object, they are equal:

const obj3 = obj1;
obj1 === obj3; // true (same object)

More on Solidifying Javascript Foundations

DEV Community: mmvergara

Free Ai Supabase Seeder

🪴 - SupaSeeder - 🪴

Try it out online at supaseeder.vercel.app 🔥

⚙️ How It Works

🛠️ Setup Locally

Method 2: Run Locally

Why Are Buttons Losing the Pointer Cursor? ft. ShadCn

The Fix

The reason.. i think.

I Promise.js for dummies

The Three States of a Promise

Why Promises Beat Callbacks

The Magic of .then() and .catch()

Async/Await: Promises in Disguise

A Niche Example

Extra tip: Promise.all()

The magic of Debouncing in creating reactive Search Bars

Javascript Prototypal Inheritance once and for all

The Family Tree

The ECMAScript Spec

The Chain

Why Prototypal Inheritance?

WTF is 'this' in Javascript

Arrow Functions and "this"

The Spec Says...

A Real World Example... i think

Javascript IIFEs - Why They were a Big Deal

Why?

Javascript Hoisting - What Moves and What Stays

var Hoisting

let and const in the Temporal Dead Zone (TDZ)

The TDZ (Temporal Dead Zone)

A slightly harder example

The Class Gotcha

Currying in JavaScript

What about the use case?

We should understand `==` more, than not using it at all.

The Numeric Preference

Why Does This Matter?

When Does == Make Sense?

The Bigger Picture

JavaScript NaN Quirks: Features, Not Flaws.

What is NaN?

NaN's Quirky Behavior

Why NaN is a Number

Example

Unraveling the "===" of javascript

The Algorithm for ===

Why NaN === NaN is false

Why +0 === -0 is true

Objects and Reference Equality

The Magic of `.then()` and `.catch()`

`var` Hoisting

`let` and `const` in the Temporal Dead Zone (TDZ)

When Does `==` Make Sense?

The Algorithm for `===`

Why `NaN === NaN` is `false`

Why `+0 === -0` is `true`