DEV Community: Achla

🫧 Event Bubbling & Delegation in JavaScript

Achla — Wed, 23 Jul 2025 01:36:52 +0000

"Why is my button click triggering a parent div click too? 😵‍💫"

If you've ever asked this, welcome to the world of event bubbling.

Let me walk you through this like we’re sitting down, pair programming — and I’m explaining how things flow in the browser DOM with events.

🌊 What is Event Propagation?

When a browser handles events, it does so in three phases:

Capturing phase: event travels from root to target (also called trickling)
Target phase: event hits the actual target element
Bubbling phase: event travels back up to root

Think of event propagation like a rock dropped in water:

Capturing: The rock sinks (top → target).

Bubbling: Bubbles rise back up (target → top).

🍃 Scene 1: Just a Click

📦 Example HTML

<div class="grand-parent">
  <div class="parent">
    <div class="child">Click Me</div>
  </div>
</div>

🧪 Let's Attach Listeners

const grandParent = document.querySelector('.grand-parent');
const parent = document.querySelector('.parent');
const child = document.querySelector('.child');

grandParent.addEventListener('click', () => {
  console.log("Grandparent clicked");
});

parent.addEventListener('click', () => {
  console.log("Parent clicked");
});

child.addEventListener('click', () => {
  console.log("Child clicked");
});

Now if you click the button, here’s what logs:

Child clicked
Parent clicked
Grandparent clicked

Why?

👉 This is event bubbling.
When an event occurs on an element, it bubbles up the DOM tree — triggering listeners on parent elements too.

The event fires on child, then bubbles up to parent and grand-parent.

🔄 Capturing Phase? Use { capture: true }

// Only grandParent and parent have { capture: true }  

grandParent.addEventListener('click', () => console.log("Captured Grandparent"), true);   // or { capture: true }

grandParent.addEventListener('click', () => console.log("Bubbled Grandparent"));  

parent.addEventListener('click', () => console.log("Captured Parent"), true);  

parent.addEventListener('click', () => console.log("Bubbled Parent")); 

child.addEventListener('click', () => console.log("Bubbled Child"));

📋 Now Output becomes:

Captured Grandparent  
Captured Parent  
Bubbled Child  
Bubbled Parent  
Bubbled Grandparent

This is the capturing phase, where events are caught while coming down the DOM tree.

🌊 What Exactly is Event Bubbling?

Imagine you're blowing bubbles underwater.
The event happens at the deepest element (button), and it bubbles up to the top (parent elements).

That’s how the browser handles events by default — in the bubbling phase.

🛑 Can I Stop the Bubble?

Absolutely. You can stop events from bubbling or capturing using:

event.stopPropagation();

Or even more strictly:

event.stopPropagation();

🔍 Difference?

Method	Prevents Parent Listeners?	Prevent other listeners on same element
`stopPropagation()`	✅ Yes	❌ No
`stopImmediatePropagation()`	✅ Yes	✅ Yes

🎯 event.target vs event.currentTarget vs this

Term	Meaning
`event.target`	The actual element clicked
`event.currentTarget`	The element with the listener
`this`	Same as `currentTarget` (in regular functions)

child.addEventListener('click', function (e) {
  console.log('Target:', e.target);        // what was clicked
  console.log('CurrentTarget:', e.currentTarget); // where listener is attached
  console.log('This:', this);              // same as currentTarget
});

🚀 Enter Event Delegation (Big Brain Move)

I had 100 buttons to add click listeners to.
I was doing this:

document.querySelectorAll('.box').forEach((box) => {
  box.addEventListener('click', () => {
    console.log('Box clicked');
  });
});

Worked fine. But slow 🐌
Instead, I did:

document.querySelector('.container').addEventListener('click', (e) => {
  if (e.target.classList.contains('box')) {
    console.log('Clicked:', e.target.textContent);
  }
});

Now the parent handles it all, thanks to event bubbling!

💡 Real-Life Analogy

You’re in a restaurant.
Instead of each table ordering from the chef directly (many listeners),
they tell the waiter (one listener) who passes it along.

Event delegation is that waiter.

Without delegation:
🧑🍳 Chef (browser) runs around taking 100 individual orders (listeners).
With delegation:
🧑💼 Waiter (parent) takes all orders in one trip.

✅ Why Use Event Delegation?

Pros	Cons
✅ Less memory usage	❌ Can catch unintended clicks
✅ Dynamically added elements work	❌ Harder to debug sometimes
✅ Better for long lists or dynamic UIs	❌ Needs conditional checks

🧩 Real Use Case

Say you're building a TODO app where new tasks are added dynamically. Using delegation:

document.querySelector("#todoList").addEventListener("click", (e) => {
  if (e.target.classList.contains("delete-btn")) {
    e.target.closest("li").remove();
    console.log("🗑️ Task deleted");
  }
});

Works even for tasks added after page load! 🔥

❗ When Not to Use Delegation

There are cases where event delegation isn’t ideal:

Isolated Components
Think of popups, modals, or small widgets. Each has a limited scope — no need for a parent to listen.
High-Frequency Events
Events like mousemove, scroll, or input can fire rapidly. Delegating these may create a performance bottleneck.
Security or Specificity Needs
If each element needs to behave very differently or securely, it's better to bind individually.
Form Elements with Blur/Focus
These events don’t bubble, so delegation won't catch them!

<div id="parent">
  <button>Click <span>me</span></button>
</div>

parent.addEventListener('click', (e) => {
  if (e.target.tagName === 'BUTTON') { 
    console.log("Button clicked!"); 
  }
});

❌ Fails if user clicks the inside the button!
✅ Fix: Use e.target.closest('button') instead.

📚 Quick Summary

Concept	What to Remember	Example/Tip
Bubbling	Events rise up (default).	`child → parent → grandparent`
Capturing	Events trickle down (`{ capture: true }`).	`grandparent → parent → child`
`event.target`	Deepest clicked element.	Button inside a div? `target` = button.
Delegation	Parent handles dynamic children.	`parent.addEventListener(..., if (e.target.matches('.child')))`
`stopPropagation()`	Stops parent listeners.	`e.stopPropagation()` in child skips parent.

For deeper dives: MDN Event Propagation Guide

Let the events bubble—but you control the flow like a pro. 🧠💡

Would love to hear how you use event delegation in your projects!

When I Thought Writing Everything in One File Was Smart (And Then It Hit Me...)

Achla — Mon, 14 Jul 2025 05:04:18 +0000

🚀 The Junior Dev Inside Me

When I started as a junior developer, I saw my senior teammate writing so many files... just to save a user to the database. 🤯

There was a UserDTO, a UserService, a UserRepository, some interfaces, and even a folder just for exceptions.

I stared at the structure and thought:

“Isn’t this overkill? I could do this in one file with 10 lines of code. Why make it so complicated?”

So I did just that.

💻 My One-File Hero Moment

// saveUser.js
const express = require("express");
const app = express();
const mongoose = require("mongoose");
app.use(express.json());

mongoose.connect("mongodb://localhost:27017/test");

app.post("/user", async (req, res) => {
  const { name, email } = req.body;
  const User = mongoose.model("User", new mongoose.Schema({ name: String, email: String }));
  await User.create({ name, email });
  res.send("User created");
});

app.listen(3000);

It worked. ✅
I was proud. I deployed it. I slept well. 😌

🧨 Then Reality Hit

A few weeks later:

The client wanted to validate the email.
Then they wanted to add a phone number.
Then they wanted to store the user's role.

Every small update meant:

Digging through my one big file and changing everything 😫

I accidentally broke the DB connection once.
Forgot to validate input once.
It became a bug-prone mess.

That’s when I finally understood why seniors use so many files.
It wasn’t overkill — it was SOLID.

📐 What Are SOLID Principles?

SOLID is a set of 5 design principles that help write clean, maintainable, and scalable code:

Principle	Meaning in Simple Words
S - Single Responsibility	One class/file/function should do only one job
O - Open/Closed	Code should be open for extension but closed for changes
L - Liskov Substitution	Subclasses should behave like their base class
I - Interface Segregation	Don’t force components to depend on things they don’t use
D - Dependency Inversion	Depend on abstractions, not concrete implementations

🛠️ Before vs After (Real Code Example)

❌ Bad (All-in-one mess)

app.post("/user", async (req, res) => {
  const User = mongoose.model("User", new mongoose.Schema({ name: String }));
  await User.create({ name: req.body.name });
  res.send("User created");
});

No validation
Direct DB code in route
Hard to test
Not reusable

✅ Good (SOLID way – broken into parts)

📁 routes/userRoute.js

router.post("/", userController.createUser);

📁 controllers/userController.js

export const createUser = async (req, res) => {
  const dto = new CreateUserDTO(req.body);
  const user = await userService.create(dto);
  res.send(user);
};

📁 services/userService.js

export const create = async (dto) => {
  validateUser(dto);
  return userRepository.save(dto);
};

📁 repositories/userRepository.js

export const save = async ({ name }) => {
  const User = mongoose.model("User", new mongoose.Schema({ name }));
  return await User.create({ name });
};

Now each file has one job, and I can:

✅ Easily test each part
✅ Reuse userService elsewhere
✅ Change DB logic without touching the controller
✅ Scale the app without fear

🍔 Real-Life Analogy

Imagine you run a burger shop:

One person takes orders
Another cooks
One packs
One delivers

Now imagine if one person does everything — they’ll mess something up.

💡 Like in code, separating responsibilities makes things faster, cleaner, and less buggy.

🧠 Final Lesson I Learned

Just because your code works doesn’t mean it’s good.But if it’s modular, testable, and SOLID, you’ll thank yourself later.

I once thought "one file is smart."
Now I know: "smart is writing maintainable code."

💬 What About You?

Have you ever written a one-file monster and paid for it later?

Let me know in the comments — let's normalize learning from messy code! 😄

That Time React Taught Me to Be a Smart Closet Organizer ( Understanding Reconciliation & Diffing)

Achla — Fri, 11 Jul 2025 03:00:08 +0000

Hey folks 👋,

So here I am again, sitting at my desk, coffee in hand, scratching my head over why one small UI update turned into a weird mess. You ever have those moments when you're like, "React, why are you re-rendering the whole world just because I changed one list item?" Yeah. That was me last week.

And that led me into finally understanding something I had always kind of ignored — Reconciliation and Diffing in React.

🧠 First Off, What Is Reconciliation?

Okay, picture this:

React is like a really smart artist who draws your app on a whiteboard.

Now, every time your app’s state or props change, React:

Looks at the old sketch it made (old Virtual DOM).
Looks at the new idea you gave it (new Virtual DOM).
Figures out the difference.
And updates just what’s changed on the actual webpage (the Real DOM).

That whole clever update process? That’s Reconciliation.

Definition

Reconciliation is the process React uses to determine how the UI should be updated when the component’s state or props change.

Here’s how it works:

React creates a new Virtual DOM after every state/prop change.
It compares this new Virtual DOM with the previous one.
Only the changed parts are updated in the actual DOM (the browser's UI).

This approach allows React to minimize expensive DOM operations and ensure a smoother user experience.

🔍 Then What Is Diffing?

Diffing is the actual detective work React does during reconciliation.

It’s like React saying:

"Okay, what's different between what I had before and what I have now?"

And it does this super smartly:

If the tag/component is the same, it just updates the content or attributes.
If it’s different, React throws the old one out and makes a new one.

Definition

Diffing is the algorithm used during reconciliation to compare the new Virtual DOM with the previous one and identify what has changed.

Key points about the diffing process:

Same component or element type: React updates only the changed attributes or content.
Different component or element type: React unmounts the old node and mounts a new one.
For child elements in lists: React uses a key to track and identify individual elements efficiently

🧦 Real Life Analogy: My Messy Closet

Imagine your UI is a closet (mine usually is 😅).

Inside, you have 3 shirts:

👕 Green
👕 Red
👕 Blue

Now you want to change things:

Move Blue to the top
Keep Red in place
Move Green to the bottom

React doesn’t go “Okay, let’s take everything out and start fresh.”

Instead, it just moves a couple shirts around.

Smart and efficient. That’s Diffing and Reconciliation in action.

🏷️ The Magic of Keys (Seriously, Don't Ignore These)

Now here’s where I used to mess up (and maybe you have too?): Keys.

React uses key props to track each item in a list.

If you use something like:

<ul>
  <li key="1">Green</li>
  <li key="2">Red</li>
  <li key="3">Blue</li>
</ul>

React’s core strength lies in its ability to efficiently update and render components as data changes. Two key concepts that enable this performance are Reconciliation and Diffing. As a full-stack developer working with React (Next.js), understanding these internal processes helps in writing optimized, predictable UI code.

Why Keys Matter in Lists

In dynamic lists, using the correct key is crucial for performance and stability. The key prop helps React identify which items have changed, are added, or are removed.

✅ Correct usage:

<ul>
  {items.map(item => (
    <li key={item.id}>{item.name}</li>
  ))}
</ul>

React reuses existing DOM elements based on keys, avoiding unnecessary DOM manipulations.

❌ Inorrect usage:

<ul>
  {items.map((item, index) => (
    <li key={index}>{item.name}</li>
  ))}
</ul>

Using index as a key can cause:

Unnecessary re-renders
Lost input focus
Animation glitches

Overview

In React, Reconciliation is the process used to update the user interface efficiently when the state or props change.

React keeps a Virtual DOM, which is an in-memory copy of the real DOM. Whenever something changes, React creates a new Virtual DOM and compares it with the previous one. This comparison step is called diffing.

During diffing, React checks which elements have changed. It figures out the minimum number of updates needed and then applies only those changes to the real DOM. This makes the UI updates faster and more efficient.

For example, if I have a list like Pen, Paper, Pencil and I change it to Pen, Paper, Whitener, React will detect that only "Pencil" changed to "Whitener" and will update just that item — it won’t touch the others.

Using unique keys with list items helps React identify elements correctly and avoid unnecessary re-renders. This is especially important when reordering or updating list items.

So in short:

Diffing is comparing Virtual DOMs

Reconciliation is updating the real DOM based on the diff

And keys help React do this more efficiently.

My Unexpected Bug Hunt: How Debugging a Weird API Issue in Laravel Taught Me More Than Docs Ever Could

Achla — Sat, 28 Jun 2025 22:40:39 +0000

Hey fellow devs,

Pull up a chair, because I just survived one of those bug hunts — the kind that makes you question your entire career choice but also ends up teaching you something new and, somehow, feels oddly satisfying. If you’re a full-stack dev juggling Next.js, Laravel, Vue, PHP, Python, and recently poking at Machine Learning (yep, that’s me), you’ll probably nod along.

🐞 The Setup: An API That Refused to Play Nice

I was working on a client project built on Laravel. The backend APIs served a Next.js frontend, and everything was humming along smoothly until suddenly… BAM! I started getting 404 errors from one endpoint.

The thing is:

The route existed.
The controller was in place.
Everything should have worked.

And yet Laravel stubbornly refused to acknowledge the endpoint.

Cue the typical developer freak-out:

“Did I break something? Is my localhost on fire? Is this the end?”

🔍 First, Check the Basics (Spoiler: They Were Fine)

I double-checked:

✅ Route file? Yup, the route was there.
✅ Controller method? Defined properly.
✅ API middleware? Nothing weird.
✅ Next.js fetch call? URL correct and consistent.

Still, 404.

At this point, I Googled everything from

“Laravel 404 with valid route”

to

“Is Laravel secretly trolling me?”

🧨 The Culprit: Route Caching — That Sneaky Little Devil

Turns out, I’d forgotten I ran:

php artisan route:cache

And voilà — the API came back to life. 🎉