DEV Community: Emily Scott

Why JavaScript IntersectionObserver Is Not Triggering (And How to Fix It)

Emily Scott — Fri, 24 Apr 2026 10:29:01 +0000

A less common but very frustrating frontend problem developers face is this:

You set up IntersectionObserver, but it never triggers.

No callback.

No lazy loading.

No infinite scroll.

Nothing happens.

This issue appears a lot in:

Infinite scrolling
Lazy loading images
Scroll animations
Ad tracking
Analytics events
Sticky navigation triggers
Performance optimization

It feels like your code is correct, but the observer still does nothing.

Let’s fix it step by step.

The Problem

Suppose you want to detect when an element enters the screen.

You write this:

const target = document.querySelector(".box");

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      console.log("Element is visible");
    }
  });
});

observer.observe(target);

You expect this:

Element is visible

when the element enters the viewport.

But instead, nothing happens.

No logs.

No trigger.

Very confusing.

Why This Happens

IntersectionObserver only works when:

The target element actually exists
The element can be observed inside the viewport
The observer settings are correct
The CSS layout allows proper visibility detection

If even one of these breaks, the callback may never run.

That is usually the real issue.

Common Mistake #1: The Element Does Not Exist Yet

This is very common:

const target = document.querySelector(".box");
observer.observe(target);

If .box is not rendered yet:

target === null

then observation fails silently.

This is especially common in React and dynamic UI rendering.

Step 1: Check the Target First

Safer version:

const target = document.querySelector(".box");

if (target) {
  observer.observe(target);
}

Always confirm the element exists first.

This solves many issues immediately.

Common Mistake #2: Wrong `threshold` Value

Developers often use this:

const observer = new IntersectionObserver(callback, {
  threshold: 1
});

Problem:

threshold: 1 means:

Trigger only when 100% of the element is visible

That often never happens.

Especially with large elements.

Very common mistake.

Step 2: Use a Better Threshold

Safer version:

const observer = new IntersectionObserver(callback, {
  threshold: 0.1
});

This means:

Trigger when 10% of the element becomes visible

Much more practical.

Much better for real applications.

Common Mistake #3: Wrong `root` Setting

Some developers set this:

root: document.querySelector(".container")

But if that container does not actually scroll, the observer behaves strangely.

If you want viewport detection, use:

root: null

which means the browser viewport.

This is usually the correct choice.

Step 3: Use the Viewport Properly

Correct setup:

const observer = new IntersectionObserver(callback, {
  root: null,
  threshold: 0.1
});

Clean.

Reliable.

Production-safe.

React Version of This Problem

This happens constantly in React.

Example:

useEffect(() => {
  observer.observe(ref.current);
}, []);

Problem:

Sometimes ref.current is still null.

Then the observer never starts.

Very common bug.

Step 4: Protect React Refs

Safer version:

useEffect(() => {
  if (ref.current) {
    observer.observe(ref.current);
  }
}, []);

Always protect refs before observing.

This saves a lot of debugging time.

Another Hidden Problem: CSS Layout Issues

Sometimes the problem is not JavaScript.

It is CSS.

Examples include:

display: none
overflow: hidden
Wrong scroll container
Zero-height elements
Elements already visible on load

These directly affect visibility detection.

Developers often miss this completely.

Very important.

Step 5: Debug with `entry`

Always inspect the observer data:

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    console.log(entry);
  });
});

This helps you check:

Is the callback firing?
Is isIntersecting false?
Is the intersection ratio too small?

This reveals the real issue fast.

Quick Debug Rule

Whenever IntersectionObserver fails, ask yourself:

Is the observer broken, or is the element never actually intersecting?

That question usually finds the issue immediately.

Most bugs start there.

Final Thoughts

IntersectionObserver is powerful, but small setup mistakes break everything.

Remember:

Check that the target element exists
Avoid threshold: 1 unless truly needed
Use root: null for viewport detection
Protect React refs
Check CSS layout issues
Debug using the full entry object

This is a less common problem, but when it happens, debugging becomes painful.

Fixing it properly saves serious time.

Especially in infinite scroll and lazy loading features.

Your Turn

Have you ever spent an hour debugging IntersectionObserver only to realize the element was null?

That happens more often than developers admit.

Google Cloud Next '26: The Dawn of the Agentic Enterprise

Emily Scott — Thu, 23 Apr 2026 11:28:24 +0000

Google Cloud Next '26: The Dawn of the Agentic Enterprise

Google Cloud Next '26, the flagship annual conference for Google Cloud, took place April 22–24, 2026, at the Mandalay Bay Convention Center in Las Vegas. The event attracted tens of thousands of attendees to explore the latest advancements in generative AI, infrastructure, security, data, and cloud computing.

This year marked a major shift: from generative AI experiments to the Agentic Enterprise — where autonomous AI agents operate at scale to drive real business transformation.

The Event at a Glance

Dates: April 22–24, 2026 (pre-events on April 21)
Venue: Mandalay Bay Convention Center, Las Vegas
Format: In-person + live-streamed keynotes, technical sessions, workshops, Expo floor, networking, and evening events
Core Themes: Agentic AI, AI infrastructure, data platforms, cybersecurity, developer tools, and Google Workspace

The agenda opened with the "The Agentic Cloud" keynote, followed by a Developer Keynote focused on agents in the autonomous era.

Core Theme: Building the Agentic Enterprise

Google Cloud positioned Next '26 as the launchpad for the Agentic Enterprise. The focus moved beyond chat interfaces to production-grade, multi-step agentic workflows powered by a unified, secure, and scalable AI stack.

Key momentum stats shared:

Nearly 75% of Google Cloud customers use AI products
Hundreds of customers process trillions of tokens monthly
First-party models handle over 16 billion tokens per minute via API

Major Announcements

1. Gemini Enterprise Agent Platform

The biggest reveal: a comprehensive platform (evolving Vertex AI) to build, scale, govern, and optimize agents at enterprise scale.

Key capabilities:

Agent Studio — low-code/no-code visual builder
Agent Developer Kit — graph-based logic with natural language support
Persistent Memory Bank, secure sandboxes, sub-second cold starts
Cryptographic Agent Identity, Agent Registry, and Model Armor protections
Full observability with OpenTelemetry

It also includes the Gemini Enterprise App for business users with inbox-style interactions, scoped Projects, Skills, Canvas, and an Agent Gallery.

2. AI Hypercomputer and 8th-Gen TPUs

New purpose-built AI Hypercomputer architecture with two new TPUs:

TPU 8t (training) — scales to 9,600 chips, 2 PB shared memory, up to 3x performance
TPU 8i (inference) — optimized for millions of concurrent agents with ultra-low latency

Additional infrastructure: Virgo networking, Google Cloud Managed Lustre, Rapid Cloud Storage, and Arm-based Axion processors.

3. Agentic Data Cloud

Cross-Cloud Lakehouse (Apache Iceberg) for zero-copy access across clouds
Knowledge Catalog with dynamic context graphs
Lightning Engine for Apache Spark — up to 4.5x faster
Data Agent Kit and Deep Research Agent for intent-driven insights

4. Agentic Defense & Security

New cybersecurity platform integrating Google Threat Intelligence with Wiz:

Autonomous threat hunting and remediation agents
Wiz Red/Blue/Green agents
Google Cloud Fraud Defense
Model Context Protocol (MCP) support

5. Google Workspace Intelligence

Enhanced semantic layer across Gmail, Docs, Drive, Meet, etc., plus new customer-facing and employee agents.

Real-World Customer Impact

Dozens of customer stories were showcased:

GE Appliances: 800+ agents in manufacturing & logistics
KPMG: 100+ agents in first month with 90% adoption
Virgin Voyages: 1,000+ agents driving 40% faster campaigns
Wins at Citi, Macquarie, PepsiCo, Unilever, Vodafone, and more

Creative demos included AI performance analysis for Olympic athletes.

Why It Matters

Google Cloud Next '26 delivered a clear blueprint: the agentic future is here. With an open, secure, and massively scalable stack (supporting third-party models and hybrid environments), Google is enabling organizations to move AI from pilots to pervasive, agent-driven operations.

The innovations announced in Las Vegas will shape enterprise AI strategies for years to come.

What did you think of Google Cloud Next '26? Which announcement excited you the most? Drop your thoughts in the comments 👇

Stay tuned for deeper technical deep-dives and hands-on codelabs in the coming weeks.

Why JavaScript AbortController Is Not Canceling fetch() Requests (And How to Fix It)

Emily Scott — Thu, 23 Apr 2026 06:41:02 +0000

Why JavaScript AbortController Is Not Canceling fetch() Requests (And How to Fix It)
A less common—but very real—problem many developers face is this:

You try to cancel a fetch() request, but the request still continues.

Or worse, the UI updates with old data after the user has already moved on.

This happens a lot in:

Search suggestions
Live filtering
React components
Route changes
Infinite scroll
File uploads
Dashboard refreshes

It creates strange bugs that are difficult to trace, especially in modern frontend applications.

Let’s fix it properly.

The Problem

Suppose you are building a live search feature.

You write this:

const controller = new AbortController();

fetch("/api/search?q=javascript", {
  signal: controller.signal
})
  .then((res) => res.json())
  .then((data) => {
    console.log(data);
  });

controller.abort();

You expect the request to stop immediately.

Instead, sometimes:

The request still appears in the Network tab
Old results still render
Unexpected errors appear

Very confusing.

It feels like AbortController is broken.

But usually, the real problem is implementation.

Why This Happens

AbortController does not magically stop everything.

It only tells fetch():

Cancel this request if possible

When the request is aborted:

The Promise rejects
An error is thrown
Your .then() chain may still behave unexpectedly if not handled correctly

Many developers forget this part.

That causes bugs.

Common Mistake #1: Forgetting to Handle the Abort Error

Developers often write this:

fetch(url, {
  signal: controller.signal
})
  .then((res) => res.json())
  .then((data) => {
    setResults(data);
  });

But they forget .catch().

When the request is aborted, JavaScript throws an error.

Without proper handling, debugging becomes messy.

Step 1: Always Handle Abort Errors

Use this instead:

fetch(url, {
  signal: controller.signal
})
  .then((res) => res.json())
  .then((data) => {
    setResults(data);
  })
  .catch((error) => {
    if (error.name === "AbortError") {
      console.log("Request was canceled");
    } else {
      console.error(error);
    }
  });

This is the first and most important fix.

Common Mistake #2: Reusing the Same Controller

Wrong approach:

const controller = new AbortController();

function search() {
  fetch(url, {
    signal: controller.signal
  });
}

The problem is simple:

Once aborted, that controller stays aborted.

You cannot safely reuse it.

Many developers miss this.

Step 2: Create a New Controller for Every Request

Correct approach:

function search() {
  const controller = new AbortController();

  fetch(url, {
    signal: controller.signal
  });

  return controller;
}

Fresh controller.

Fresh request.

Much safer.

Real React Example

This problem happens constantly in React.

A user types quickly in a search box.

Older API requests finish later and overwrite newer results.

That creates bad UX.

Very common.

Step 3: Cancel Previous Requests in React

Use this pattern:

let controller;

function handleSearch(query) {
  if (controller) {
    controller.abort();
  }

  controller = new AbortController();

  fetch(`/api/search?q=${query}`, {
    signal: controller.signal
  })
    .then((res) => res.json())
    .then((data) => {
      setResults(data);
    })
    .catch((error) => {
      if (error.name !== "AbortError") {
        console.error(error);
      }
    });
}

Now only the latest request matters.

Much cleaner.

Much safer.

Better UX.

Another Hidden Problem

Some developers think this:

controller.abort();

cancels JavaScript itself.

It does not.

It only affects the network request.

If your .then() has already started running, you must still control that logic manually.

This is a very important detail.

Step 4: Protect UI Updates

Safer example:

fetch(url, {
  signal: controller.signal
})
  .then((res) => res.json())
  .then((data) => {
    if (!controller.signal.aborted) {
      setResults(data);
    }
  });

This helps prevent stale UI updates.

Very useful in real applications.

Quick Debug Rule

Whenever old API data appears, ask yourself:

Did I cancel the request, or did I only assume it was canceled?

That question usually reveals the real issue immediately.

Final Thoughts

AbortController is powerful—but only when used correctly.

Remember:

Always handle AbortError
Never reuse the same controller
Create a new controller for each request
Protect UI updates after aborting
Especially important in React search and filtering

This is a less common bug, but when it happens, it becomes a nightmare.

Fixing it properly saves serious debugging time.

Your Turn

Have you ever had old API results overwrite new ones in your UI?

That is usually where the AbortController lesson begins.

Thanks for reading,
Emily Idioms

Why 'structuredClone()' Is Breaking in JavaScript (And the Right Way to Deep Copy Objects)

Emily Scott — Wed, 22 Apr 2026 09:33:38 +0000

A fresh problem many JavaScript developers are facing in modern projects is this:

ReferenceError: structuredClone is not defined

Or sometimes:

TypeError: Failed to execute 'structuredClone'

This happens a lot in:

React projects
Node.js applications
API data processing
State management
Form handling
Redux updates
Deep object cloning

Many developers moved from the old cloning method:

JSON.parse(JSON.stringify(obj))

to the newer:

structuredClone(obj)

But suddenly, production breaks.

Let’s fix it properly.

The Problem

Suppose you write this:

const user = {
  name: "John",
  settings: {
    theme: "dark"
  }
};

const copy = structuredClone(user);

copy.settings.theme = "light";

console.log(user.settings.theme);

Expected Output

dark

Because you want a real deep copy.

But instead, some developers get:

ReferenceError: structuredClone is not defined

Very frustrating—especially after deploying.

Why This Happens

structuredClone() is a modern JavaScript feature.

It is supported in newer browsers and newer Node.js versions.

But older environments may not support it.

This often happens when:

Your Node.js version is too old
The browser is outdated
Build tools are using older runtimes
The deployment server differs from your local machine

Your code works locally…

but fails in production.

Very common.

Why Developers Prefer `structuredClone()`

Because this old method has serious problems:

const copy = JSON.parse(JSON.stringify(user));

It breaks things like:

Dates
Maps
Sets
Functions
undefined values
Circular references

Example:

const obj = {
  createdAt: new Date()
};

After JSON cloning:

createdAt

becomes a string—not a real Date object.

Bad for real applications.

That is why developers prefer structuredClone().

Step 1: Check Your Environment

Before changing code, check your Node.js version:

node -v

structuredClone() works properly in modern Node.js versions.

If your version is old, upgrade Node.js first.

This solves the issue for many developers immediately.

This should always be your first step.

Step 2: Use the Native Modern Solution

Use this:

const copy = structuredClone(user);

This is the best native solution for deep cloning.

It handles nested objects safely.

Cleaner.

Safer.

More reliable.

This is the preferred solution for modern JavaScript projects.

Step 3: Add a Safe Fallback for Older Environments

If structuredClone() is unavailable, use a fallback:

const copy =
  typeof structuredClone === "function"
    ? structuredClone(user)
    : JSON.parse(JSON.stringify(user));

This protects production apps.

Especially useful when working across mixed environments.

Very practical.

React Example

This matters a lot in React state updates.

Wrong Approach

const newState = oldState;

newState.user.name = "Emma";

This mutates the original state.

Bad for React.

It causes unexpected UI bugs.

Correct Approach

const newState = structuredClone(oldState);

newState.user.name = "Emma";

Now state updates safely.

Much better.

Less debugging.

Cleaner React code.

Another Common Error

Some values cannot be cloned.

Example:

const obj = {
  fn: () => console.log("Hello")
};

structuredClone(obj);

This may fail.

Why?

Because functions are not cloneable with structuredClone().

Important rule:

Use it for data—not executable logic.

Very important.

Quick Debug Rule

Whenever cloning breaks, ask yourself:

Am I cloning plain data… or special objects like functions and classes?

That question finds the issue fast.

Most bugs start there.

Final Thoughts

structuredClone() is powerful, but environment support matters.

Remember:

Check your Node.js version first
Use structuredClone() for modern deep copying
Add fallback support if needed
Do not clone functions this way
Avoid relying only on JSON cloning

This small fix prevents huge debugging problems.

Especially in React and backend applications.

And it is becoming one of the newest common JavaScript production issues.

Your Turn

Have you replaced JSON.parse(JSON.stringify()) with structuredClone() yet?

Many developers are making that switch right now.

Thanks for reading,
Emily Idioms

JavaScript 'Cannot Read Properties of Undefined' Error (How to Fix It Step by Step Guide)

Emily Scott — Tue, 21 Apr 2026 13:49:40 +0000

JavaScript Cannot Read Properties of Undefined (How to Fix It Step by Step)

This is one of the most common and frustrating JavaScript errors developers face:

TypeError: Cannot read properties of undefined

It appears suddenly.

Your code was working.

Then one missing value breaks everything.

This happens in:

API responses
React components
Form handling
DOM manipulation
Database results
Nested objects
User authentication flows

Almost every JavaScript developer has faced this error.

Let’s fix it properly.

The Problem

Suppose you write this:

const user = {
  name: "John"
};

console.log(user.address.city);

Expected Output

New York

Actual Output

TypeError: Cannot read properties of undefined (reading 'city')

Very annoying.

Why?

Because address does not exist.

JavaScript tries to read this:

undefined.city

And that causes the crash.

Why This Happens

JavaScript reads objects step by step.

This line:

user.address.city

means:

Find user
Find address
Find city

But if step 2 returns undefined, step 3 fails immediately.

JavaScript cannot read properties from undefined.

That is the root problem.

Real-World Example

This happens constantly with APIs.

Example:

const response = await fetchUser();

console.log(response.data.profile.name);

Looks normal.

But if this is missing:

response.data

your app crashes.

This is why frontend bugs happen so often after API updates.

Very common in production.

First Fix: Check Before Accessing

Safer version:

if (user.address) {
  console.log(user.address.city);
}

Now JavaScript checks first.

No crash.

Simple and safe.

But this becomes messy with deeply nested objects.

Example:

if (
  response &&
  response.data &&
  response.data.profile
) {
  console.log(response.data.profile.name);
}

Too much code.

Hard to maintain.

Better Fix: Optional Chaining

Modern JavaScript gives us a much better solution:

console.log(user.address?.city);

This means:

Only continue if address exists.

If it does not exist, JavaScript returns undefined instead of crashing.

Much cleaner.

Much better.

Real API Example with Optional Chaining

Instead of this:

if (
  response &&
  response.data &&
  response.data.profile
) {
  console.log(response.data.profile.name);
}

Write this:

console.log(response.data?.profile?.name);

Short.

Readable.

Production-friendly.

This is the preferred modern solution.

Another Useful Fix: Default Values

Sometimes you want a fallback value.

Example:

console.log(user.address?.city || "City not available");

Output

City not available

Very useful for UI rendering.

Especially in React apps.

Users should see fallback text—not app crashes.

React Version of This Problem

This error happens constantly in React:

<h1>{user.profile.name}</h1>

If user.profile is missing, the component crashes.

Safer version:

<h1>{user.profile?.name}</h1>

Much safer.

Cleaner code.

Less production stress.

React developers use this daily.

Hidden Cause: Async Data Loading

Another common reason:

console.log(users[0].name);

If the API has not loaded yet:

users[0]

is undefined.

Crash again.

Safer version:

console.log(users[0]?.name);

Always protect async-loaded data.

Very important.

Quick Debug Rule

Whenever you see:

Cannot read properties of undefined

Ask yourself:

Which value is actually undefined?

Not the final property.

The missing step before it.

That is where the real bug lives.

This saves hours.

Final Thoughts

This error is not random.

It happens because JavaScript reaches undefined before reaching the property you want.

Remember:

Check before accessing
Use optional chaining ?.
Add fallback values when needed
Protect API responses
Protect React rendering
Protect async-loaded data

Mastering this one error removes a huge amount of frontend bugs.

Probably more than any other JavaScript fix.

Your Turn

What was your worst “Cannot read properties of undefined” bug?

Most developers remember that painful day very clearly.

Peace,
Emily Idioms

Why JavaScript forEach() Does Not Work with await (How to Fix It)

Emily Scott — Mon, 20 Apr 2026 12:24:45 +0000

Why JavaScript forEach() Does Not Work with await (And How to Fix It)

One of the most confusing async problems in JavaScript happens when developers use await inside forEach() and expect everything to run in order.

It looks correct.

It feels correct.

But it breaks in production.

This issue appears often in API requests, database operations, email sending, payment processing, and file uploads.

Many developers lose hours debugging this.

Let’s fix it properly.

The Problem

Suppose you want to process users one by one.

You write this:

const users = ["John", "Emma", "Michael"];

users.forEach(async (user) => {
  await sendEmail(user);
  console.log(`Email sent to ${user}`);
});

console.log("All emails processed");

At first glance, this looks perfect.

You expect:

Send email to John
Send email to Emma
Send email to Michael
Print final message

Expected output:

Email sent to John
Email sent to Emma
Email sent to Michael
All emails processed

But the actual output is often:

All emails processed
Email sent to John
Email sent to Emma
Email sent to Michael

Sometimes even worse—execution becomes unpredictable.

Very frustrating.

Why This Happens

The problem is simple:

forEach() does not wait for async/await.

It completely ignores Promises.

Even if you write await inside it, forEach() itself does not pause.

It immediately starts all iterations and moves on.

That means this line:

console.log("All emails processed");

runs before the async work finishes.

This creates race conditions and broken logic.

Especially dangerous in production systems.

Understanding the Core Issue

Let’s simplify it.

This:

users.forEach(async (user) => {
  await sendEmail(user);
});

does NOT mean:

“Wait for each task one by one”

It actually means:

“Start everything immediately and do not wait”

That is the real problem.

forEach() was designed for synchronous operations—not async control flow.

Wrong Real-World Example

Imagine payment processing:

orders.forEach(async (order) => {
  await chargeCustomer(order);
});

closeDailyReport();

Danger:

The report may close before payments finish.

That can create serious business problems.

This is not a small bug.

It can affect money.

The Correct Fix: Use `for...of`

The safest solution is for...of.

Like this:

const users = ["John", "Emma", "Michael"];

async function processUsers() {
  for (const user of users) {
    await sendEmail(user);
    console.log(`Email sent to ${user}`);
  }

  console.log("All emails processed");
}

processUsers();

Now JavaScript waits properly.

Output:

Email sent to John
Email sent to Emma
Email sent to Michael
All emails processed

Perfect.

Predictable.

Safe.

Why `for...of` Works

Because for...of respects await.

Each loop waits for the previous one to finish.

This is called sequential execution.

Very useful for:

Payment processing
Database writes
Email sending
File uploads
Rate-limited APIs
Authentication flows

Anywhere order matters.

What If You Want Parallel Execution?

Sometimes you do want everything to run together.

For example:

Fetching multiple products
Loading dashboard widgets
Getting multiple API responses

In that case, use Promise.all().

Example:

const users = ["John", "Emma", "Michael"];

await Promise.all(
  users.map(async (user) => {
    await sendEmail(user);
    console.log(`Email sent to ${user}`);
  })
);

console.log("All emails processed");

This runs tasks in parallel—but still waits for all of them to finish.

Very powerful.

Rule to Remember

Use this simple rule:

Need order?

Use for...of

Need speed?

Use Promise.all()

Never use?

forEach() with await

This rule saves a lot of debugging time.

Another Common Mistake

Developers often write this:

await users.forEach(async (user) => {
  await sendEmail(user);
});

This still does NOT work.

Why?

Because forEach() returns undefined.

There is nothing real for await to wait for.

So even this fails.

Very common mistake.

Debugging Question

Whenever async loops behave strangely, ask:

“Am I awaiting the loop… or only the function inside it?”

That question reveals the bug fast.

Most developers miss this.

Final Thoughts

forEach() is excellent for simple synchronous loops.

But for async workflows, it becomes dangerous.

Remember:

forEach() ignores await
for...of handles sequence safely
Promise.all() handles parallel work properly
await forEach() is still wrong

Understanding this makes JavaScript async code much cleaner.

And production bugs become much easier to prevent.

Your Turn

Have you ever used await inside forEach() and spent hours debugging it?

Almost every JavaScript developer has.

Peace,
Emily Idioms

Why map() Is Returning undefined in JavaScript (And How to Fix It)

Emily Scott — Sun, 19 Apr 2026 07:34:49 +0000

One of the most common JavaScript bugs developers face is using .map() and getting an array full of undefined.

It looks simple, but this issue wastes hours during debugging—especially in React projects, API handling, and frontend rendering.

Let’s fix it properly.

The Problem

You write code like this:

const numbers = [1, 2, 3];

const doubled = numbers.map((num) => {
  num * 2;
});

console.log(doubled);

Expected Output

[2, 4, 6]

Actual Output

[undefined, undefined, undefined]

Very frustrating.

Why This Happens

When you use curly braces {} inside .map(), JavaScript expects an explicit return.

This code:

(num) => {
  num * 2;
}

does not return anything.

And if nothing is returned, JavaScript automatically returns undefined.

That is why every item becomes undefined.

The Correct Fix

Option 1: Add `return`

const doubled = numbers.map((num) => {
  return num * 2;
});

Output

[2, 4, 6]

Option 2: Use Implicit Return

Cleaner version:

const doubled = numbers.map((num) => num * 2);

This is shorter and commonly preferred.

The React Version of This Bug

This happens constantly in React:

users.map((user) => {
  <div>{user.name}</div>;
});

Nothing renders.

Why?

Because JSX also needs return.

Correct Version

users.map((user) => {
  return <div>{user.name}</div>;
});

Or:

users.map((user) => (
  <div>{user.name}</div>
));

This is one of the most common frontend mistakes.

Another Hidden Trap

Returning objects also causes confusion.

Wrong

const users = data.map((user) => {
  name: user.name;
});

JavaScript thinks this is a function block, not an object.

Correct

const users = data.map((user) => ({
  name: user.name
}));

Wrap the object in parentheses.

Very important.

Quick Debug Rule

If .map() gives undefined, ask yourself:

“Did I actually return something?”

That question usually finds the bug immediately.

Final Thoughts

.map() is powerful, but tiny syntax mistakes create major confusion.

Remember:

Curly braces need return
Parentheses allow implicit return
Objects need wrapping ()
React JSX must also return

Mastering this saves serious debugging time—especially in production apps.

Your Turn

What was your worst .map() debugging moment?

React developers usually have many.

Peace,
Emily Idioms

Why Your JavaScript setTimeout() Is Not Working as Expected (And How to Fix It)

Emily Scott — Sat, 18 Apr 2026 10:54:58 +0000

One of the most common frustrations for JavaScript developers—especially beginners and even experienced devs during debugging—is when setTimeout() behaves differently than expected.

You write a delay, expect the code to wait, but JavaScript seems to ignore your logic.

Let’s fix that.

The Problem

Many developers think setTimeout() pauses JavaScript execution.

Example:

console.log("Start");

setTimeout(() => {
  console.log("Delayed Message");
}, 2000);

console.log("End");

Expected output by many:

Start
(wait 2 seconds)
Delayed Message
End

Actual output:

Start
End
(wait 2 seconds)
Delayed Message

This confuses a lot of developers.

Why This Happens

JavaScript is single-threaded, which means it executes one task at a time.

setTimeout() does not pause execution.

Instead, it tells the browser:

“Run this function after at least 2 seconds.”

The callback is sent to the Event Loop, and JavaScript continues running the next lines immediately.

That is why "End" appears before "Delayed Message".

The Real Issue in Production

This creates bigger problems when working with:

API requests
Form validation
DOM updates
Authentication flows
Payment gateways
Loading states

Developers often expect delayed code to execute in order, but async behavior breaks logic.

Example:

let userData;

setTimeout(() => {
  userData = "John";
}, 1000);

console.log(userData);

Output:

undefined

Because console.log() runs before the timeout finishes.

The Correct Fix

Use callbacks, Promises, or async/await depending on the situation.

Better Example Using Promise

function wait(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function run() {
  console.log("Start");

  await wait(2000);

  console.log("Now it waits properly");
}

run();

Output:

Start
(wait 2 seconds)
Now it waits properly

This gives you predictable execution flow.

Pro Tip for Real Projects

Avoid using setTimeout() just to “wait for something.”

Bad practice:

setTimeout(() => {
  fetchData();
}, 3000);

Good practice:

Use actual event completion:

Promise resolved
API response returned
DOM fully loaded
User action completed

Time-based guessing creates bugs.

Debugging Tip

When debugging async issues, ask:

“Am I waiting for time… or waiting for an actual result?”

That question solves many hidden JavaScript bugs.

Final Thoughts

setTimeout() is not broken.

The misunderstanding is usually about how JavaScript handles async execution.

Once you understand:

Call Stack
Web APIs
Callback Queue
Event Loop

JavaScript becomes far easier to control.

And debugging becomes much less painful.

Have You Faced This?

What was your most confusing setTimeout() bug?

Drop it in the comments—every developer has at least one painful story. Peace Idioms

How I Built a Random Post Feed in WordPress Without Using RSS

Emily Scott — Sun, 12 Apr 2026 06:51:11 +0000

When I started working on my website, theidioms.com, I wanted visitors to discover different content every time they visited.

The problem was simple: the default WordPress RSS feed always showed the latest posts in date order.

That was not ideal for a content-heavy website with hundreds of evergreen articles.

Older idiom posts were getting buried, even though they were still highly useful.

So I decided to build a custom solution.

The Problem

WordPress RSS feeds are mainly designed for recent content syndication.

By default, they return:

the latest published posts
chronological ordering
very limited control over randomization

For my use case, this created a discovery problem.

Visitors kept seeing only the newest articles, while older evergreen posts remained hidden.

For a website focused on idioms and phrases, this meant many useful pages were rarely seen.

My Solution

Instead of relying on the RSS feed, I used a custom WP_Query to fetch a random published post directly from the database.

$args = array(
    'post_type'      => 'post',
    'post_status'    => 'publish',
    'posts_per_page' => 1,
    'orderby'        => 'rand'
);

$query = new WP_Query($args);

if ($query->have_posts()) :
    while ($query->have_posts()) : $query->the_post();
        echo '<a href="' . get_permalink() . '">' . get_the_title() . '</a>';
    endwhile;
endif;

wp_reset_postdata();

This returns one random published post every time the page loads.

Why This Helped

This small change solved several issues.

Better Content Discovery

Visitors now land on different idiom pages instead of repeatedly seeing the latest articles.

Increased Engagement

Random internal links encourage users to continue exploring.

Better Use of Evergreen Content

Older articles get fresh visibility without needing to republish them.

Performance Challenge

One issue I quickly noticed was that orderby => 'rand' can become slow on larger sites.

As the database grows, random queries may increase server load.

To solve this, I later cached the result and refreshed it every 15 minutes.

That gave me the benefit of random discovery without stressing the database on every page request.

Final Thoughts

Sometimes the default WordPress tools are not enough for specific use cases.

For my site, replacing RSS with a custom random query improved both user experience and page visibility.

If you run a blog, dictionary site, or any content archive with evergreen posts, this is a simple technique worth trying.

Have you built a similar custom solution in WordPress? Let me know in the comments.

Cheers! Idioms

How to Fix “Blocked by CORS Policy” Error in JavaScript (Step-by-Step Guide)

Emily Scott — Sat, 21 Feb 2026 04:34:20 +0000

How to Fix “Blocked by CORS Policy” Error in JavaScript (Step-by-Step Guide)

If you are building a web application and see this error in your browser
console:

Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' 
has been blocked by CORS policy.

This is one of the most common issues beginners face when working with
JavaScript and APIs.

In this article, you will learn:

What CORS is
Why this error happens
How to fix it in Node.js (Express)
How to fix it in PHP
Best practices for production

What Is CORS?

CORS (Cross-Origin Resource Sharing) is a browser security feature.

A request is considered cross-origin when:

Your frontend runs on http://localhost:3000
Your backend runs on https://api.example.com

Because these origins are different, the browser blocks the request
unless the server explicitly allows it.

Important: CORS is enforced by the browser, not by the server.

Why the CORS Error Happens

CORS errors occur because the backend server does not send the correct
HTTP headers.

The browser checks for headers like:

Access-Control-Allow-Origin

If the header is missing, the browser blocks the request.

This means you cannot fix CORS from the frontend alone.
It must be configured on the backend.

Solution 1: Fix CORS in Node.js (Express)

First, install the CORS middleware:

npm install cors

Then update your Express server:

const express = require('express');
const cors = require('cors');

const app = express();

app.use(cors());

app.get('/api/data', (req, res) => {
  res.json({ message: "CORS is fixed!" });
});

app.listen(5000, () => console.log("Server running on port 5000"));

Restart the server and test your request again.

Solution 2: Fix CORS in PHP

If you are using PHP, add the following headers at the top of your PHP
file:

<?php
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");
header("Access-Control-Allow-Headers: Content-Type, Authorization");
?>

This allows cross-origin requests.

Important: Do Not Use “*” in Production

Using:

header("Access-Control-Allow-Origin: *");

Allows requests from any domain.

In production, it is safer to specify your domain:

header("Access-Control-Allow-Origin: https://yourdomain.com");

Why Postman Works But the Browser Fails

You may notice:

Postman works
Browser fails

This happens because CORS is enforced only by browsers.
Postman does not enforce CORS restrictions.

Quick Debug Checklist

Confirm CORS headers are set on the backend
Restart the server
Clear browser cache
Check the browser console again

Conclusion

The “Blocked by CORS Policy” error is not a JavaScript bug.
It is a browser security rule.

Once you understand that CORS must be configured on the backend, the
solution becomes straightforward.

Thanks for reading - Idioms

My Journey into Web Development (And Why I Started with JavaScript)

Emily Scott — Fri, 20 Feb 2026 07:36:04 +0000

Hi everyone, 👋

I’m a beginner web developer currently learning JavaScript, HTML, CSS, and PHP, and recently exploring AI integration in web apps. I wanted my first post to share why I started — and what I’ve learned so far.

Why I Started Learning Web Development

I’ve always been curious about how websites actually work. Not just how they look, but how they function behind the scenes.

When I discovered that:

HTML structures the content
CSS styles the design
JavaScript makes it interactive

...it suddenly felt less mysterious and more achievable.

💡 My Current Learning Focus

Right now, I’m focusing on:

✅ Writing clean HTML structure

✅ Building responsive layouts with CSS

✅ Understanding JavaScript fundamentals (variables, functions, loops)

✅ Exploring how AI APIs can connect with web apps

I’m not trying to rush into advanced frameworks yet. I want strong fundamentals first.

🔍 Biggest Lesson So Far

Consistency beats intensity.

It’s easy to feel overwhelmed when you see experienced developers building complex apps. But I’ve learned that small daily progress — even 30–60 minutes — adds up quickly.

🎯 What’s Next?

Learn DOM manipulation deeply
Build small interactive projects
Experiment with simple AI-powered features
Improve my Git & GitHub workflow

If you're also a beginner, I’d love to connect.
What are you currently learning?

Let’s grow step by step. 🚀

Cheers! Idioms

DEV Community: Emily Scott

Why JavaScript IntersectionObserver Is Not Triggering (And How to Fix It)

The Problem

Why This Happens

Common Mistake #1: The Element Does Not Exist Yet

Step 1: Check the Target First

Common Mistake #2: Wrong threshold Value

Step 2: Use a Better Threshold

Common Mistake #3: Wrong root Setting

Step 3: Use the Viewport Properly

React Version of This Problem

Step 4: Protect React Refs

Another Hidden Problem: CSS Layout Issues

Step 5: Debug with entry

Quick Debug Rule

Final Thoughts

Your Turn

Google Cloud Next '26: The Dawn of the Agentic Enterprise

The Event at a Glance

Core Theme: Building the Agentic Enterprise

Major Announcements

1. Gemini Enterprise Agent Platform

2. AI Hypercomputer and 8th-Gen TPUs

3. Agentic Data Cloud

4. Agentic Defense & Security

5. Google Workspace Intelligence

Real-World Customer Impact

Why It Matters

Why JavaScript AbortController Is Not Canceling fetch() Requests (And How to Fix It)

The Problem

Why This Happens

Common Mistake #1: Forgetting to Handle the Abort Error

Step 1: Always Handle Abort Errors

Common Mistake #2: Reusing the Same Controller

Step 2: Create a New Controller for Every Request

Real React Example

Step 3: Cancel Previous Requests in React

Another Hidden Problem

Step 4: Protect UI Updates

Quick Debug Rule

Final Thoughts

Your Turn

Why 'structuredClone()' Is Breaking in JavaScript (And the Right Way to Deep Copy Objects)

The Problem

Expected Output

Why This Happens

Why Developers Prefer structuredClone()

Step 1: Check Your Environment

Step 2: Use the Native Modern Solution

Step 3: Add a Safe Fallback for Older Environments

React Example

Wrong Approach

Correct Approach

Another Common Error

Quick Debug Rule

Final Thoughts

Your Turn

JavaScript 'Cannot Read Properties of Undefined' Error (How to Fix It Step by Step Guide)

The Problem

Expected Output

Actual Output

Why This Happens

Real-World Example

First Fix: Check Before Accessing

Better Fix: Optional Chaining

Real API Example with Optional Chaining

Another Useful Fix: Default Values

Output

React Version of This Problem

Hidden Cause: Async Data Loading

Quick Debug Rule

Final Thoughts

Your Turn

Why JavaScript forEach() Does Not Work with await (How to Fix It)

The Problem

Why This Happens

Understanding the Core Issue

Wrong Real-World Example

The Correct Fix: Use for...of

Why for...of Works

Common Mistake #2: Wrong `threshold` Value

Common Mistake #3: Wrong `root` Setting

Step 5: Debug with `entry`

Why Developers Prefer `structuredClone()`

The Correct Fix: Use `for...of`

Why `for...of` Works

Option 1: Add `return`