You’re building a Cover Letter Builder. A user clicks “Modern Template.” Now what? Do you navigate to a new page, update the URL quietly, or pop open a modal? The answer shapes your entire user experience — and most beginners guess wrong.

This guide breaks down the three routing patterns you’ll reach for constantly in Next.js, when to use each one, and the navigation mechanics (router.push, replace, Link) that tie it all together. By the end, you’ll have a simple decision rule you can apply to any feature you build.

The Setup: What Are We Actually Choosing Between?

Imagine you’re building a job application tool. Users browse a gallery of CV/cover letter templates and pick one to start editing. The moment they click “Use This Template,” you have three options:

Option A → navigate to /cover-letter/modern       (Full Page Route)
Option B → stay on /templates?selected=modern     (Query Params)
Option C → open a popup on top of /templates      (Modal)

Each one feels slightly different to the user. Each one has different implications for your code. Let’s go through them one by one.

Pattern 1: Full Page Route

What it looks like

/cover-letter/modern
/cover-letter/minimal
/cover-letter/creative

How it works in Next.js App Router

You create a folder structure with square brackets — that’s the “dynamic segment”:

app/
 └── cover-letter/
      └── [templateId]/
           └── page.tsx

The [templateId] part is a placeholder. When a user visits /cover-letter/modern, Next.js automatically fills in:

ts

params.templateId = "modern"

Your page component receives this as a prop:

tsx

// app/cover-letter/[templateId]/page.tsx
interface PageProps {
  params: { templateId: string }
}
export default function CoverLetterPage({ params }: PageProps) {
  const { templateId } = params
  // templateId = "modern" | "minimal" | "creative" etc.
  return (
    <div>
      <h1>Editing: {templateId} template</h1>
      <CoverLetterEditor templateId={templateId} />
    </div>
  )
}

You can also generate page metadata dynamically — great for SEO:

tsx

// Same file, above the component
export async function generateMetadata({ params }: PageProps) {
  return {
    title: `${params.templateId} Cover Letter Template`,
    description: `Edit your cover letter using the ${params.templateId} layout`,
  }
}

Real-life examples of Full Page Routes

These are all URLs that make sense to live at their own address:

/products/nike-air-max-2024       ← a specific product
/blog/how-to-write-a-resume       ← a specific article
/users/johndoe                    ← a user profile
/checkout                         ← the checkout page
/dashboard/settings               ← settings section

Think of it this way: if someone sent you that link in a WhatsApp message and you opened it, would it make sense? If yes — it belongs as a Full Page Route.

When to use it

Use Full Page Routes when the thing you’re showing has its own identity:

• It can be bookmarked and revisited later
• It can be shared with someone else
• It has its own loading state, error state, and metadata
• The user is truly “going somewhere new” in your app

Pros

1. URLs are clean and readable

/cover-letter/modern    ← anyone can read this

2. Bookmarkable — users can save the link and come back a week later. Their work is right there.

3. Shareable — paste the URL anywhere, it opens the same thing.

4. Browser back button works naturally — tap back on mobile, you go to the previous page. No tricks needed.

5. Great for SEO — Google prefers clean path-based URLs:

/blog/react-hooks        ← Google loves this
/blog?id=react-hooks     ← Google likes this less

6. Each page has its own lifecycle — independent loading, error boundaries, and layout.

Cons

1. Navigation takes a moment — you’re doing a full page transition, not a quick popup.

2. Overkill for quick interactions — if you just want a user to preview an image or confirm a delete, a full page navigation is too heavy.

Pattern 2: Query Params

What it looks like

/cover-letter?template=modern
/products?category=shoes&color=black&size=42
/search?q=react+hooks&page=2

How it works in Next.js

You read query params using the useSearchParams hook (client component only):

tsx

'use client'
import { useSearchParams } from 'next/navigation'
export default function CoverLetterPage() {
  const searchParams = useSearchParams()
  const template = searchParams.get('template')  // "modern"
  const page = searchParams.get('page')           // "2" (always a string)
  return (
    <div>
      <h1>Template: {template}</h1>
    </div>
  )
}

Note: Query params are always strings. If you store a number like ?page=2, you'll need to convert it: Number(searchParams.get('page')).

You can update query params without a full page reload using useRouter:

tsx

'use client'
import { useRouter, useSearchParams, usePathname } from 'next/navigation'
export default function FilterBar() {
  const router = useRouter()
  const pathname = usePathname()
  const searchParams = useSearchParams()
  function setFilter(key: string, value: string) {
    // Build a new URLSearchParams from the current ones
    const params = new URLSearchParams(searchParams.toString())
    params.set(key, value)
    // Update the URL without navigating away
    router.push(`${pathname}?${params.toString()}`)
  }
  return (
    <div>
      <button onClick={() => setFilter('color', 'black')}>Black</button>
      <button onClick={() => setFilter('color', 'white')}>White</button>
    </div>
  )
}

Real-life examples of Query Params

You see these everywhere in e-commerce and search:

amazon.com/s?k=laptop&rh=p_36:10000-50000     ← search + price filter
youtube.com/results?search_query=next.js       ← search query
airbnb.com/s/Paris?checkin=2024-06-01         ← date filter
github.com/issues?q=is:open+label:bug          ← issue filte

None of these are “new pages” — they’re all the same page with different data showing.

When to use it

Use query params when you’re controlling state within the same page, not navigating to a new concept:

• Filters (color, size, price range)
• Sorting (newest, price low to high)
• Pagination (page 1, page 2)
• Active tab (overview, reviews, specs)
• Search keywords
• View mode (grid vs list)

Pros

1. Perfect for filters — the most common use case in the real world.

2. Still shareable — ?color=black&size=42 in the URL means someone else gets the same filtered view.

3. Survives a refresh — if the user refreshes the page, their filters are still there (they’re in the URL, not in useState).

4. Great for lightweight UI state — tabs, pagination, search — anything that’s “same page, different view.”

Cons

1. Less readable than clean paths:

/cover-letter/modern        ← clear
/cover-letter?template=modern  ← slightly noisier

2. Not ideal for primary resources — if something is a standalone page (a product, a user profile, an article), it deserves its own path, not a query param.

3. Slightly weaker SEO — for content that matters to Google, clean paths are better.

Pattern 3: Modal

What it looks like

A popup appears on top of the current page.
The URL might not change at all.
The background page is still there, dimmed behind the modal.

How it works

The simplest version uses local React state:

tsx

'use client'

import { useState } from 'react'
export default function TemplateGallery() {
  const [isOpen, setIsOpen] = useState(false)
  const [selectedTemplate, setSelectedTemplate] = useState<string | null>(null)
  function openPreview(templateId: string) {
    setSelectedTemplate(templateId)
    setIsOpen(true)
  }
  return (
    <div>
      <h1>Choose a Template</h1>
      <div className="grid">
        {['modern', 'minimal', 'creative'].map((id) => (
          <div key={id} onClick={() => openPreview(id)}>
            <img src={`/templates/${id}.png`} alt={id} />
            <button>Preview</button>
          </div>
        ))}
      </div>
      {/* The modal */}
      {isOpen && selectedTemplate && (
        <div className="modal-overlay" onClick={() => setIsOpen(false)}>
          <div className="modal-content" onClick={(e) => e.stopPropagation()}>
            <button onClick={() => setIsOpen(false)}>✕ Close</button>
            <h2>Preview: {selectedTemplate}</h2>
            <img src={`/templates/${selectedTemplate}-preview.png`} alt="preview" />
            <a href={`/cover-letter/${selectedTemplate}`}>
              Use This Template →
            </a>
          </div>
        </div>
      )}
    </div>
  )
}

A more advanced version (like how Instagram does it) changes the URL when the modal opens — so it’s shareable — but still shows a modal on top of the gallery. This uses Next.js Parallel Routes with Intercepting Routes, which is an advanced topic for when you’re comfortable with the basics.

Real-life examples of Modals

Instagram → click a photo   → modal opens, URL changes to /p/ABC123
GitHub    → delete a repo   → "Are you sure?" confirm modal
Figma     → right-click     → context menu / quick action modal
Airbnb    → photo gallery   → image lightbox (fullscreen zoom)
Notion    → create new page → simple name input modal
Linear    → create issue    → full-featured create modal
Stripe    → view payment    → details slide-in panel

When to use it

Use a modal when the interaction is temporary — the user needs to do something quick and return to what they were doing:

• Confirm a destructive action (“Delete this file?”)
• Preview something before committing (“See what this template looks like”)
• Fill in a short form (“Add a comment”)
• Zoom into an image
• Show a login prompt

Pros

1. Fast — opens and closes instantly, no navigation.

2. User stays in context — the original page is still there behind the modal. Great for workflows where they need to keep their place.

3. Perfect for temporary interactions — confirm, preview, quick edit, zoom.

Cons

1. Not shareable by default — there’s no URL to copy and paste (unless you add extra logic).

2. Disappears on refresh — because the state lives in useState, a page reload closes the modal.

3. Browser back button is tricky — by default, pressing back doesn’t close the modal, it navigates away from the page entirely. You need extra code to handle this.

4. Accessibility requires extra work — you need to handle focus trapping (keyboard can’t escape the modal accidentally), the Escape key closing it, and preventing background scroll. Libraries like Radix UI or Headless UI handle this for you.

The Decision Framework: 3 Questions

Before you build anything, ask yourself these three questions in order:

Question 1: "Can someone send this URL to a friend and have it open the right thing?"
            If yes → Full Page Route

Question 2: "Is this just a different view of the same page?"
            If yes → Query Param
Question 3: "Is the user doing something quick and coming right back?"
            If yes → Modal

Here’s that mapped to the Cover Letter Builder example:

User actionBest patternWhyOpens the builder for “modern” templateFull Page Route/cover-letter/modern — it's their workspace, they'll bookmark itSwitches template inside the builderQuery Param/cover-letter?template=modern — same page, different viewPreviews a template before committingModalQuick look, then decide — no need for a full pageConfirms "Delete my draft"ModalTemporary destructive actionViews a friend's shared cover letterFull Page RouteShared URL should open something meaningful

The Part Most Beginners Skip: Browser History & Navigation Methods

This is where it gets interesting — and where most beginners hit confusing bugs.

When you navigate in a browser, it maintains a history stack. Think of it like a stack of cards:

[Home] [Templates] [Cover Letter / Modern]
                                    ↑ you are here

Every time you go somewhere new, a card gets added. When you press Back, the top card is removed.

Next.js gives you three ways to navigate — and they behave very differently.

Method 1: <Link> — The Default, Always Start Here

<Link> is Next.js's version of an anchor tag. It handles client-side navigation (fast, no full page reload) automatically.

tsx

import Link from 'next/link'

// Basic navigation
<Link href="/cover-letter/modern">
  Open Modern Template
</Link>
// With dynamic values
<Link href={`/cover-letter/${templateId}`}>
  Open {templateId}
</Link>
// Prefetches the page on hover - instant feel
<Link href="/templates" prefetch={true}>
  Browse Templates
</Link>

What it does to browser history: Adds a new entry. User can press Back to return.

Real-life analogy: Clicking a link in a book that takes you to a new chapter. You can flip back.

Use it for: Almost all navigation. Links in navbars, buttons that take users to new pages, breadcrumbs.

Method 2: router.push() — Programmatic Navigation

Sometimes you need to navigate based on logic, not a click on a static link. For example: after a form submission, redirect the user.

tsx

'use client'

import { useRouter } from 'next/navigation'
export default function TemplateCard({ templateId }: { templateId: string }) {
  const router = useRouter()
  async function handleSelectTemplate() {
    // Maybe save to database first
    await saveSelection(templateId)
    // Then navigate
    router.push(`/cover-letter/${templateId}`)
  }
  return (
    <button onClick={handleSelectTemplate}>
      Use This Template
    </button>
  )
}

What it does to browser history: Same as <Link> — adds a new entry. User can press Back.

Real-life analogy: A staff member escorting you to a new room. You still came from somewhere, so you can go back.

Use it for:

• After form submission (redirect to success page)
• After login (redirect to dashboard)
• After completing a multi-step flow
• Conditional navigation based on logic

tsx

// Common pattern: redirect after login
async function handleLogin(email: string, password: string) {
  const result = await login(email, password)

if (result.success) {
    router.push('/dashboard')        // go to dashboard
  } else {
    setError('Invalid credentials')  // stay on login page, show error
  }
}

Method 3: router.replace() — Navigate Without Leaving a History Trail

replace is like push — it takes you to a new page — but it replaces the current history entry instead of adding a new one.

tsx

router.replace('/cover-letter/modern')

What it does to browser history:

Before push:    [Home] [Templates]
After push:     [Home] [Templates] [Cover Letter/Modern]   ← new card added
Back works ✅

Before replace: [Home] [Templates]
After replace:  [Home] [Cover Letter/Modern]               ← current card swapped
Back goes to Home, not Templates ⚠️

Real-life analogy: An editor who changes the current page you’re on instead of giving you a new one. There’s no “previous version” to go back to.

Use it for (the real cases):

Case 1: After login, don’t let users go “back” to the login page:

tsx

// After login succeeds:
router.replace('/dashboard')
// Now if user presses Back, they go to whatever was before the login page
// NOT back to the login form (which would be confusing and insecure)

Case 2: Multi-step forms — don’t let users go back to completed steps:

tsx

// Step 1 → Step 2 → Step 3
// When user completes step 1:
router.replace('/onboarding/step-2')
// Now Back from step 2 doesn't return to step 1
// (They already submitted step 1, going back would cause confusion)

Case 3: Resetting filters without polluting history:

tsx

function clearAllFilters() {
  router.replace('/products')  // go back to clean URL
  // Without replace: history stack fills up with filter combinations
}
'use client'
import Link from 'next/link'
import { useRouter } from 'next/navigation'
import { useState } from 'react'
const templates = ['modern', 'minimal', 'creative', 'executive']
export default function TemplatesPage() {
  const router = useRouter()
  const [previewTemplate, setPreviewTemplate] = useState<string | null>(null)
  async function handleUseTemplate(templateId: string) {
    // Save choice, then navigate (router.push - user can go back)
    await fetch('/api/drafts', {
      method: 'POST',
      body: JSON.stringify({ templateId }),
    })
    router.push(`/cover-letter/${templateId}`)
  }
  return (
    <div>
      <nav>
        {/* Link - simple navigation, adds to history */}
        <Link href="/dashboard">← Back to Dashboard</Link>
      </nav>
      <h1>Choose Your Template</h1>
      <div className="grid">
        {templates.map((id) => (
          <div key={id} className="card">
            <img src={`/previews/${id}.png`} alt={id} />
            <h3>{id}</h3>
            {/* Quick preview → Modal */}
            <button onClick={() => setPreviewTemplate(id)}>
              Preview
            </button>
            {/* Use template → router.push to builder page */}
            <button onClick={() => handleUseTemplate(id)}>
              Use This Template
            </button>
          </div>
        ))}
      </div>
      {/* Modal - stays on same page, no URL change */}
      {previewTemplate && (
        <div className="modal-overlay" onClick={() => setPreviewTemplate(null)}>
          <div className="modal" onClick={(e) => e.stopPropagation()}>
            <button onClick={() => setPreviewTemplate(null)}>✕</button>
            <img src={`/previews/${previewTemplate}-full.png`} alt="preview" />
            <button onClick={() => handleUseTemplate(previewTemplate)}>
              Use This Template →
            </button>
          </div>
        </div>
      )}
    </div>
  )
}

Putting It All Together: A Real Cover Letter Builder Flow

Here’s how all three navigation methods work together in one real feature:

tsx

// app/templates/page.tsx
// The template gallery page

tsx

// app/cover-letter/[templateId]/page.tsx
// The actual builder page
'use client'
import { useRouter } from 'next/navigation'
import { useSearchParams } from 'next/navigation'
interface Props {
  params: { templateId: string }
}
export default function BuilderPage({ params }: Props) {
  const router = useRouter()
  const searchParams = useSearchParams()
  // Query param for active section within the builder
  // e.g., /cover-letter/modern?section=experience
  const activeSection = searchParams.get('section') ?? 'intro'
  function switchSection(section: string) {
    // replace - switching sections shouldn't fill up history
    router.replace(`/cover-letter/${params.templateId}?section=${section}`)
  }
  async function handleSubmit() {
    await saveDraft()
    // replace - after saving, replace so Back doesn't re-submit
    router.replace('/dashboard?saved=true')
  }
  return (
    <div className="builder">
      <h1>Editing: {params.templateId} template</h1>
      <nav className="section-tabs">
        {['intro', 'experience', 'skills'].map((s) => (
          <button
            key={s}
            onClick={() => switchSection(s)}
            className={activeSection === s ? 'active' : ''}
          >
            {s}
          </button>
        ))}
      </nav>
      <SectionEditor section={activeSection} />
      <button onClick={handleSubmit}>Save & Finish</button>
    </div>
  )
}

Quick Reference: Link vs push vs replace

<Link>router.push()router.replace()Adds to history?✅ Yes✅ Yes❌ No (replaces)Back button works?✅ Yes✅ Yes⚠️ Skips this stepUse caseStatic links in UINavigate after logic/asyncRedirect after login, multi-step formsPrefetch support✅ Built-in❌❌ExampleNavbar linksPost-submit redirectAfter login, clear filter state

The One-Sentence Summary for Each Pattern

Full Page Route — Use when the thing being shown deserves its own permanent address (product page, profile, article, builder).

Query Params — Use when you’re adjusting the view of the same page (filters, sort, tabs, pagination).

Modal — Use when the user needs to do something quick without losing their current place (confirm, preview, quick edit).

router.push — Navigate forward and keep history (user can go back).

router.replace — Navigate forward but erase the current step from history (login redirect, form steps).

<Link> — The default for any clickable navigation in your UI.

What to Build Next

Now that you understand these patterns, a good exercise is to open any app you use daily (Airbnb, GitHub, Twitter, Notion) and identify which routing pattern each interaction uses. You’ll start seeing the logic behind every URL decision they made — and it’ll make your own decisions much easier.

Questions? Drop them in the comments — especially if you run into a case where none of these three patterns feels quite right. Those edge cases are where the real learning happens.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! 🌹. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub
 — Noran 🌹

Next.js Routing Patterns Explained: Full Page Routes, Query Params, and Modals was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Once you understand Islands Architecture, you’ll start seeing it everywhere — in the sites you visit, in the frameworks you use, and in every performance decision you make.

This isn’t about a specific framework or a new tool you need to learn. It’s a mental model for how you organize rendering on a page. Once it clicks, it’ll influence how you think about every web project you build.

Let’s build it from scratch.

The One-Sentence Version

Islands Architecture = most of your page is static HTML, with small isolated interactive components scattered through it.

static page + isolated interactive components

Those interactive components are the “islands.” They sit inside a sea of plain HTML — alive and interactive while everything around them is just markup.

That’s literally where the name comes from.

🌊 HTML  🌊 HTML  🌊 HTML
🌊 HTML  🌊 HTML  🌊 HTML
🏝️ [ Search Box ]
🌊 HTML  🌊 HTML  🌊 HTML
        🏝️ [ Like Button ]
🌊 HTML  🌊 HTML  🌊 HTML

What a Page Actually Looks Like

Imagine a typical blog article page:

──────────────────────────────────────
  Header                  (static)
  Hero / Intro            (static)
  Article Content         (static)
  Images                  (static)


[ Newsletter Form ] (interactive ← island)

  Related Articles        (static)

      [ Like Button ]     (interactive ← island)

  Footer                  (static)
──────────────────────────────────────

Two interactive components out of eight sections. The rest is just HTML.

Now ask yourself: why would you ship a full JavaScript application for a page that’s 75% plain text and images?

That’s the question Islands Architecture was invented to answer.

The Problem It Solves: A Short History

To really get why this matters, you need to understand what came before.

Era 1: Server-Rendered HTML (the old way)

Back when the web was simpler, the server did everything. You’d request a page, the server would build the full HTML, and send it back:

html

<!-- Server sends this complete HTML -->
<h1>My Blog Post</h1>
<p>Here's the article content...</p>
<img src="photo.jpg" alt="photo" />
<footer>© 2024</footer>

The browser receives real content immediately. Pages loaded fast. But they weren’t very interactive — every click that needed new data required a full page reload.

Era 2: Single Page Applications (SPAs)

Then came React, Vue, Angular. The SPA era. Now the server sends almost nothing:

html

<!-- Server sends just this -->
<div id="root"></div>

And JavaScript builds the entire page in the browser — every heading, paragraph, button, image. Everything.

This made apps incredibly dynamic and interactive. But it introduced a serious problem.

The Problem: JavaScript Bloat

Let’s say you have a blog post page with:

• A title
• 1,200 words of article text
• 5 images
• A footer
• One Like button

With a full SPA, you might ship 200KB–400KB of JavaScript to the user’s browser just to make that one Like button work.

The title doesn’t need JavaScript. The article text doesn’t need JavaScript. The images definitely don’t need JavaScript. But the SPA hydrates (makes interactive) the entire page anyway — because that’s how it’s built.

Islands Architecture looks at this and says: why are we doing this?

💡 Turn on the lights only in the rooms where people actually are — not the entire building.

The Core Concept: Hydration

Before we go further, you need to understand hydration, because it’s central to how Islands work.

What hydration means

When a server renders HTML and sends it to the browser, the page looks correct — but nothing is wired up yet. The buttons don’t respond. The forms don’t submit. It’s like a beautiful stage set with no electricity.

Hydration is the process of attaching JavaScript to that HTML so it becomes interactive.

Before hydration:

<button>Like ❤️</button>
↑ renders, looks fine, but clicking does nothing

After hydration:
<button onClick={handleLike}>Like ❤️</button>
↑ now it actually works

In a traditional SPA, hydration happens for the entire page — every component, every element, even the ones that don’t need it.

Islands Architecture says: only hydrate the parts that actually need to be interactive.

Full SPA hydration:
┌──────────────────────────────────┐
│  💧 Header                       │
│  💧 Hero                         │
│  💧 Article                      │
│  💧 Newsletter Form              │ ← only this actually needs JS
│  💧 Related Posts                │
│  💧 Like Button                  │ ← and this
│  💧 Footer                       │
└──────────────────────────────────┘
Hydrating: everything. JS shipped: 380KB.

Islands hydration:
┌──────────────────────────────────┐
│     Header                       │
│     Hero                         │
│     Article                      │
│  🏝️ Newsletter Form              │ ← hydrated
│     Related Posts                │
│  🏝️ Like Button                  │ ← hydrated
│     Footer                       │
└──────────────────────────────────┘
Hydrating: 2 components. JS shipped: 18KB.

That difference in JavaScript shipped directly translates to faster pages, especially on mobile devices and slower connections.

What Islands Look Like in Code

The framework most associated with Islands Architecture is Astro. Here’s what a page might look like:

astro

---
// This runs on the server. No JS sent to the browser.
import Header from './Header.astro'
import ArticleContent from './ArticleContent.astro'
import Footer from './Footer.astro'
// These are interactive components
import LikeButton from './LikeButton.jsx'
import NewsletterForm from './NewsletterForm.jsx'
import SearchBox from './SearchBox.jsx'
---
<!-- Static components - zero JavaScript -->
<Header />
<ArticleContent />
<!-- Islands - JavaScript loaded and hydrated -->
<LikeButton client:load />
<NewsletterForm client:visible />
<SearchBox client:idle />
<Footer />

Notice the client: directives. These tell Astro when and how to hydrate each island:

Directive When it hydrates Best forclient:loadImmediately on page load Critical interactive elements (search, cart)client:idleWhen the browser is idleNon-urgent UI (theme toggle, share buttons)client:visibleWhen element scrolls into viewBelow-the-fold content (comments, newsletter)client:mediaWhen a CSS media query matchesMobile-only or responsive components

This granularity is powerful. You can say “load this search box immediately” but “wait until the user scrolls down to load the comments section.” That’s a level of control that traditional SPAs don’t give you.

Real-World Examples

Example 1: A Blog Post Page

/blog/how-to-learn-react
Structure:
  - Blog post title         → static HTML
  - Author info             → static HTML
  - Article body (2000 words) → static HTML
  - Code blocks             → static HTML + CSS
  - Copy Code Button        → 🏝️ island (tiny JS to copy to clipboard)
  - Like / Bookmark         → 🏝️ island (JS to call API)
  - Comments Section        → 🏝️ island (loads when scrolled to)
  - Related Articles        → static HTML
  - Footer                  → static HTML
JavaScript sent: ~22KB (just for the 3 islands)
Instead of: ~350KB (for the full SPA version)

Example 2: An E-commerce Product Page

/products/nike-air-max

Structure:
  - Product images gallery  → static HTML (maybe with CSS lightbox)
  - Product title + brand   → static HTML
  - Description             → static HTML
  - Size guide              → static HTML
  - Color/Size Picker       → 🏝️ island (needs JS to update selection)
  - Add to Cart Button      → 🏝️ island (needs JS to call cart API)
  - Reviews Filter & Sort   → 🏝️ island (needs JS to re-sort)
  - Stock Countdown Timer   → 🏝️ island (real-time countdown)
  - Shipping info           → static HTML
  - Footer                  → static HTML

The customer can see the product, read the description, check the price — all instantly, before any JavaScript loads. Then the interactive pieces layer in progressively.

Example 3: A Documentation Site

docs.yourframework.com

Structure:
  - Sidebar navigation      → static HTML
  - Page content / API docs → static HTML
  - Code blocks             → static HTML
  - Search                  → 🏝️ island (full-text search needs JS)
  - Copy Button per code block → 🏝️ island (small, per-block)
  - Theme Toggle (dark mode) → 🏝️ island (needs JS to switch)
  - "Was this helpful?" widget → 🏝️ island (feedback form)

Sites like the old Astro docs and many developer documentation portals are built this way. The content renders instantly. The search box hydrates right away. The theme toggle can wait.

Building a Simple Island Yourself

You don’t need Astro to understand the concept. Here’s the idea in plain JavaScript to make it tangible.

The static HTML (what the server sends):

html

<!-- index.html — sent from server, renders instantly -->
<article>
  <h1>My Blog Post</h1>
  <p>A long article with lots of text...</p>

<!-- Island placeholder - empty shell -->
  <div id="like-button-island" data-post-id="123">
    <!-- Will be filled by JavaScript -->
    <button disabled>❤️ Like</button>
  </div>
  <p>More article content...</p>
</article>

The island JavaScript (loaded separately):

javascript

// like-button.js — only loaded for this one component
const island = document.getElementById('like-button-island')
const postId = island.dataset.postId
async function handleLike() {
  const response = await fetch(`/api/posts/${postId}/like`, {
    method: 'POST'
  })
  const data = await response.json()
  island.innerHTML = `<button>❤️ ${data.likes} likes</button>`
}
// Replace the disabled button with the real interactive one
island.innerHTML = `
  <button onclick="handleLike()">❤️ Like this post</button>

The result:

• The article loads instantly (pure HTML)
• The like button activates after like-button.js downloads
• If JavaScript is slow or fails, the user still sees the article just fine

This is the essence of progressive enhancement — content first, interactivity layered on top.

How Islands Compares to the Alternatives

Server-Only HTML   Full SPA      Islands Architecture
                    ─────────────────  ──────────    ────────────────────
Initial load speed  ✅ Very fast       ❌ Slow       ✅ Very fast
Interactivity       ❌ Limited         ✅ Full        ✅ Where needed
JavaScript sent     ✅ Minimal         ❌ All of it  ✅ Only islands
SEO                 ✅ Excellent       ⚠️ Depends    ✅ Excellent
Developer experience ⚠️ Limited        ✅ Great      ✅ Great
Best for            Simple sites      Apps           Content + some interactivity

When Islands Architecture Is the Right Choice

Use it for:

Blogs and editorial sites — The content is text and images. Maybe 5% of the page is interactive (comments, reactions, share buttons). Islands are a perfect fit.

Marketing and landing pages — Hero text, pricing tables, testimonials are all static. A contact form, an interactive pricing calculator, or a video player are islands.

Documentation sites — Docs are essentially books on the web. Static content with a search box, a copy button, and a theme toggle. Classic Islands territory.

E-commerce product pages — The product info is static. The cart, variant picker, and reviews filter are islands.

News sites — Articles are static. Live score widgets, weather, breaking news tickers — islands.

Skip it when:

Your entire page is a dynamic application. If you’re building a Figma, a Notion, a Trello, or any kind of dashboard where every panel updates, every action triggers UI changes, and nothing is ever just “text that stays still” — Islands won’t give you much benefit. A client-heavy framework (Next.js App Router with client components, Remix, or a pure React SPA) is a better fit.

Everything is user-specific. If nothing on your page is the same between users (a personalized dashboard, an inbox, a real-time editor), the “static sea” part of Islands doesn’t exist. There’s no sea, only islands — so you’ve just got an app.

A rough rule of thumb:

Static content > 60% of page?  →  Think Islands
Interactive content > 60%?      →  Think SPA / App

The Performance Numbers That Make This Worth It

Here’s why teams care about Islands enough to rearchitect sites around it:

JavaScript bundle size — Moving from a full SPA to Islands can cut your JavaScript payload by 60–90% for content-heavy pages. Less JavaScript means less download time, less parse time, less execution time.

Time to First Contentful Paint (FCP) — Because the HTML arrives from the server already complete, users see real content almost instantly — not a loading spinner waiting for JavaScript to boot.

Time to Interactive (TTI) — With less JavaScript to execute, the page becomes fully interactive much sooner. On a slow mobile connection, this can be the difference between a 2-second TTI and a 9-second one.

Core Web Vitals — Google’s ranking signals (LCP, FID, CLS) all improve when you send less JavaScript and more pre-rendered HTML. Islands Architecture is one of the most direct paths to excellent Core Web Vitals scores.

Real-world example: When the Astro documentation site was rebuilt using Islands Architecture, their Lighthouse performance score went from the 70s to consistently hitting 98–100.

Frameworks That Use This Pattern

Astro — The framework that popularized Islands Architecture. You can mix React, Vue, Svelte, Solid, or plain JS components as islands on the same page.

Fresh (Deno) — Built on the Islands concept from the ground up. Islands are isolated by default; everything else is server-rendered.

Marko — An older framework from eBay that pioneered similar ideas under different terminology before “Islands” became the standard term.

Qwik — Takes the idea further with “resumability” — instead of hydrating islands on load, it defers JavaScript execution until the user actually interacts with a component.

You’ll also see Island-like patterns emerging in Next.js with React Server Components — where components are server-only by default, and you opt into client behavior with 'use client'.

The Mental Model to Keep

Every time you design a page or feature, run this check:

Step 1: Draw your page layout on paper (or in your head).

Step 2: Go through each section and ask:
        "Does this section need to respond to user input?"
        "Does this section need to make API calls?"
        "Does this section need to update without a page reload?"
Step 3: If the answer to all three is NO → static HTML
        If the answer to any is YES   → island

Then count your islands. If your page has 2 islands and 10 static sections — Islands Architecture will give you a dramatic performance win. If your page has 10 islands and 2 static sections — you’re probably better off with a regular React/Next.js setup.

The Analogy That Makes It Stick

Think of your web page like a hotel at night.

A full SPA turns on every light in the entire building the moment anyone walks in — the lobby, every room, every floor, the rooftop — whether guests are there or not.

Islands Architecture only turns on the lights in the rooms that actually have guests. The rest of the building stays in the dark (but it’s all there, fully built, you just can’t interact with it).

Less electricity. Same building. Same guest experience — actually better, because they’re not waiting for the whole building to power up before they can use their room.

What to Explore Next

• Try Astro — Build a simple blog with one or two interactive islands. The client:load / client:visible directives are immediately satisfying to work with.
• Read about React Server Components — Next.js 13+ implements a similar philosophy: components are server-only by default, client behavior is opt-in.
• Look into Core Web Vitals — Understanding LCP, FID, and CLS will make you viscerally understand why sending less JavaScript matters.
• Inspect the sites you use — Open DevTools on any blog or news site and look at the JavaScript bundle size. Then open a web app like Figma or Notion. The difference will make Islands Architecture feel immediately practical.

The best architecture decisions aren’t about using the newest tool — they’re about matching the right tool to the shape of the problem. Islands Architecture is one of the clearest examples of that principle in modern web development.

Found this helpful? Follow me for more content on navigating the modern tech job market.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! 🌹. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub
 — Noran 🌹

Islands Architecture: The Idea That Changes How You Think About Web Performance was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Once you understand Islands Architecture, you’ll start seeing it everywhere — in the sites you visit, in the frameworks you use, and in every performance decision you make.

This isn’t about a specific framework or a new tool you need to learn. It’s a mental model for how you organize rendering on a page. Once it clicks, it’ll influence how you think about every web project you build.

Let’s build it from scratch.

The One-Sentence Version

Islands Architecture = most of your page is static HTML, with small isolated interactive components scattered through it.

static page + isolated interactive components

Those interactive components are the “islands.” They sit inside a sea of plain HTML — alive and interactive while everything around them is just markup.

That’s literally where the name comes from.

🌊 HTML  🌊 HTML  🌊 HTML
🌊 HTML  🌊 HTML  🌊 HTML
🏝️ [ Search Box ]
🌊 HTML  🌊 HTML  🌊 HTML
        🏝️ [ Like Button ]
🌊 HTML  🌊 HTML  🌊 HTML

What a Page Actually Looks Like

Imagine a typical blog article page:

──────────────────────────────────────
  Header                  (static)
  Hero / Intro            (static)
  Article Content         (static)
  Images                  (static)

[ Newsletter Form ] (interactive ← island)

  Related Articles        (static)

      [ Like Button ]     (interactive ← island)

  Footer                  (static)
──────────────────────────────────────

Two interactive components out of eight sections. The rest is just HTML.

Now ask yourself: why would you ship a full JavaScript application for a page that’s 75% plain text and images?

That’s the question Islands Architecture was invented to answer.

The Problem It Solves: A Short History

To really get why this matters, you need to understand what came before.

Era 1: Server-Rendered HTML (the old way)

Back when the web was simpler, the server did everything. You’d request a page, the server would build the full HTML, and send it back:

html

<!-- Server sends this complete HTML -->
<h1>My Blog Post</h1>
<p>Here's the article content...</p>
<img src="photo.jpg" alt="photo" />
<footer>© 2024</footer>

The browser receives real content immediately. Pages loaded fast. But they weren’t very interactive — every click that needed new data required a full page reload.

Era 2: Single Page Applications (SPAs)

Then came React, Vue, Angular. The SPA era. Now the server sends almost nothing:

html

<!-- Server sends just this -->
<div id="root"></div>

And JavaScript builds the entire page in the browser — every heading, paragraph, button, image. Everything.

This made apps incredibly dynamic and interactive. But it introduced a serious problem.

The Problem: JavaScript Bloat

Let’s say you have a blog post page with:

• A title
• 1,200 words of article text
• 5 images
• A footer
• One Like button

With a full SPA, you might ship 200KB–400KB of JavaScript to the user’s browser just to make that one Like button work.

The title doesn’t need JavaScript. The article text doesn’t need JavaScript. The images definitely don’t need JavaScript. But the SPA hydrates (makes interactive) the entire page anyway — because that’s how it’s built.

Islands Architecture looks at this and says: why are we doing this?

💡 Turn on the lights only in the rooms where people actually are — not the entire building.

The Core Concept: Hydration

Before we go further, you need to understand hydration, because it’s central to how Islands work.

What hydration means

When a server renders HTML and sends it to the browser, the page looks correct — but nothing is wired up yet. The buttons don’t respond. The forms don’t submit. It’s like a beautiful stage set with no electricity.

Hydration is the process of attaching JavaScript to that HTML so it becomes interactive.

Before hydration:

<button>Like ❤️</button>
↑ renders, looks fine, but clicking does nothing

After hydration:
<button onClick={handleLike}>Like ❤️</button>
↑ now it actually works

In a traditional SPA, hydration happens for the entire page — every component, every element, even the ones that don’t need it.

Islands Architecture says: only hydrate the parts that actually need to be interactive.

Full SPA hydration:
┌──────────────────────────────────┐
│  💧 Header                       │
│  💧 Hero                         │
│  💧 Article                      │
│  💧 Newsletter Form              │ ← only this actually needs JS
│  💧 Related Posts                │
│  💧 Like Button                  │ ← and this
│  💧 Footer                       │
└──────────────────────────────────┘
Hydrating: everything. JS shipped: 380KB.

Islands hydration:
┌──────────────────────────────────┐
│     Header                       │
│     Hero                         │
│     Article                      │
│  🏝️ Newsletter Form              │ ← hydrated
│     Related Posts                │
│  🏝️ Like Button                  │ ← hydrated
│     Footer                       │
└──────────────────────────────────┘
Hydrating: 2 components. JS shipped: 18KB.

That difference in JavaScript shipped directly translates to faster pages, especially on mobile devices and slower connections.

What Islands Look Like in Code

The framework most associated with Islands Architecture is Astro. Here’s what a page might look like:

astro

---
// This runs on the server. No JS sent to the browser.
import Header from './Header.astro'
import ArticleContent from './ArticleContent.astro'
import Footer from './Footer.astro'
// These are interactive components
import LikeButton from './LikeButton.jsx'
import NewsletterForm from './NewsletterForm.jsx'
import SearchBox from './SearchBox.jsx'
---
<!-- Static components - zero JavaScript -->
<Header />
<ArticleContent />
<!-- Islands - JavaScript loaded and hydrated -->
<LikeButton client:load />
<NewsletterForm client:visible />
<SearchBox client:idle />
<Footer />

Notice the client: directives. These tell Astro when and how to hydrate each island:

Directive When it hydrates Best forclient:loadImmediately on page load Critical interactive elements (search, cart)client:idleWhen the browser is idleNon-urgent UI (theme toggle, share buttons)client:visibleWhen element scrolls into viewBelow-the-fold content (comments, newsletter)client:mediaWhen a CSS media query matchesMobile-only or responsive components

This granularity is powerful. You can say “load this search box immediately” but “wait until the user scrolls down to load the comments section.” That’s a level of control that traditional SPAs don’t give you.

Real-World Examples

Example 1: A Blog Post Page

/blog/how-to-learn-react
Structure:
  - Blog post title         → static HTML
  - Author info             → static HTML
  - Article body (2000 words) → static HTML
  - Code blocks             → static HTML + CSS
  - Copy Code Button        → 🏝️ island (tiny JS to copy to clipboard)
  - Like / Bookmark         → 🏝️ island (JS to call API)
  - Comments Section        → 🏝️ island (loads when scrolled to)
  - Related Articles        → static HTML
  - Footer                  → static HTML
JavaScript sent: ~22KB (just for the 3 islands)
Instead of: ~350KB (for the full SPA version)

Example 2: An E-commerce Product Page

/products/nike-air-max

Structure:
  - Product images gallery  → static HTML (maybe with CSS lightbox)
  - Product title + brand   → static HTML
  - Description             → static HTML
  - Size guide              → static HTML
  - Color/Size Picker       → 🏝️ island (needs JS to update selection)
  - Add to Cart Button      → 🏝️ island (needs JS to call cart API)
  - Reviews Filter & Sort   → 🏝️ island (needs JS to re-sort)
  - Stock Countdown Timer   → 🏝️ island (real-time countdown)
  - Shipping info           → static HTML
  - Footer                  → static HTML

The customer can see the product, read the description, check the price — all instantly, before any JavaScript loads. Then the interactive pieces layer in progressively.

Example 3: A Documentation Site

docs.yourframework.com

Structure:
  - Sidebar navigation      → static HTML
  - Page content / API docs → static HTML
  - Code blocks             → static HTML
  - Search                  → 🏝️ island (full-text search needs JS)
  - Copy Button per code block → 🏝️ island (small, per-block)
  - Theme Toggle (dark mode) → 🏝️ island (needs JS to switch)
  - "Was this helpful?" widget → 🏝️ island (feedback form)

Sites like the old Astro docs and many developer documentation portals are built this way. The content renders instantly. The search box hydrates right away. The theme toggle can wait.

Building a Simple Island Yourself

You don’t need Astro to understand the concept. Here’s the idea in plain JavaScript to make it tangible.

The static HTML (what the server sends):

html

<!-- index.html — sent from server, renders instantly -->
<article>
  <h1>My Blog Post</h1>
  <p>A long article with lots of text...</p>

<!-- Island placeholder - empty shell -->
  <div id="like-button-island" data-post-id="123">
    <!-- Will be filled by JavaScript -->
    <button disabled>❤️ Like</button>
  </div>
  <p>More article content...</p>
</article>

The island JavaScript (loaded separately):

javascript

// like-button.js — only loaded for this one component
const island = document.getElementById('like-button-island')
const postId = island.dataset.postId
async function handleLike() {
  const response = await fetch(`/api/posts/${postId}/like`, {
    method: 'POST'
  })
  const data = await response.json()
  island.innerHTML = `<button>❤️ ${data.likes} likes</button>`
}
// Replace the disabled button with the real interactive one
island.innerHTML = `
  <button onclick="handleLike()">❤️ Like this post</button>

The result:

• The article loads instantly (pure HTML)
• The like button activates after like-button.js downloads
• If JavaScript is slow or fails, the user still sees the article just fine

This is the essence of progressive enhancement — content first, interactivity layered on top.

How Islands Compares to the Alternatives

Server-Only HTML   Full SPA      Islands Architecture
                    ─────────────────  ──────────    ────────────────────
Initial load speed  ✅ Very fast       ❌ Slow       ✅ Very fast
Interactivity       ❌ Limited         ✅ Full        ✅ Where needed
JavaScript sent     ✅ Minimal         ❌ All of it  ✅ Only islands
SEO                 ✅ Excellent       ⚠️ Depends    ✅ Excellent
Developer experience ⚠️ Limited        ✅ Great      ✅ Great
Best for            Simple sites      Apps           Content + some interactivity

When Islands Architecture Is the Right Choice

Use it for:

Blogs and editorial sites — The content is text and images. Maybe 5% of the page is interactive (comments, reactions, share buttons). Islands are a perfect fit.

Marketing and landing pages — Hero text, pricing tables, testimonials are all static. A contact form, an interactive pricing calculator, or a video player are islands.

Documentation sites — Docs are essentially books on the web. Static content with a search box, a copy button, and a theme toggle. Classic Islands territory.

E-commerce product pages — The product info is static. The cart, variant picker, and reviews filter are islands.

News sites — Articles are static. Live score widgets, weather, breaking news tickers — islands.

Skip it when:

Your entire page is a dynamic application. If you’re building a Figma, a Notion, a Trello, or any kind of dashboard where every panel updates, every action triggers UI changes, and nothing is ever just “text that stays still” — Islands won’t give you much benefit. A client-heavy framework (Next.js App Router with client components, Remix, or a pure React SPA) is a better fit.

Everything is user-specific. If nothing on your page is the same between users (a personalized dashboard, an inbox, a real-time editor), the “static sea” part of Islands doesn’t exist. There’s no sea, only islands — so you’ve just got an app.

A rough rule of thumb:

Static content > 60% of page?  →  Think Islands
Interactive content > 60%?      →  Think SPA / App

The Performance Numbers That Make This Worth It

Here’s why teams care about Islands enough to rearchitect sites around it:

JavaScript bundle size — Moving from a full SPA to Islands can cut your JavaScript payload by 60–90% for content-heavy pages. Less JavaScript means less download time, less parse time, less execution time.

Time to First Contentful Paint (FCP) — Because the HTML arrives from the server already complete, users see real content almost instantly — not a loading spinner waiting for JavaScript to boot.

Time to Interactive (TTI) — With less JavaScript to execute, the page becomes fully interactive much sooner. On a slow mobile connection, this can be the difference between a 2-second TTI and a 9-second one.

Core Web Vitals — Google’s ranking signals (LCP, FID, CLS) all improve when you send less JavaScript and more pre-rendered HTML. Islands Architecture is one of the most direct paths to excellent Core Web Vitals scores.

Real-world example: When the Astro documentation site was rebuilt using Islands Architecture, their Lighthouse performance score went from the 70s to consistently hitting 98–100.

Frameworks That Use This Pattern

Astro — The framework that popularized Islands Architecture. You can mix React, Vue, Svelte, Solid, or plain JS components as islands on the same page.

Fresh (Deno) — Built on the Islands concept from the ground up. Islands are isolated by default; everything else is server-rendered.

Marko — An older framework from eBay that pioneered similar ideas under different terminology before “Islands” became the standard term.

Qwik — Takes the idea further with “resumability” — instead of hydrating islands on load, it defers JavaScript execution until the user actually interacts with a component.

You’ll also see Island-like patterns emerging in Next.js with React Server Components — where components are server-only by default, and you opt into client behavior with 'use client'.

The Mental Model to Keep

Every time you design a page or feature, run this check:

Step 1: Draw your page layout on paper (or in your head).

Step 2: Go through each section and ask:
        "Does this section need to respond to user input?"
        "Does this section need to make API calls?"
        "Does this section need to update without a page reload?"
Step 3: If the answer to all three is NO → static HTML
        If the answer to any is YES   → island

Then count your islands. If your page has 2 islands and 10 static sections — Islands Architecture will give you a dramatic performance win. If your page has 10 islands and 2 static sections — you’re probably better off with a regular React/Next.js setup.

The Analogy That Makes It Stick

Think of your web page like a hotel at night.

A full SPA turns on every light in the entire building the moment anyone walks in — the lobby, every room, every floor, the rooftop — whether guests are there or not.

Islands Architecture only turns on the lights in the rooms that actually have guests. The rest of the building stays in the dark (but it’s all there, fully built, you just can’t interact with it).

Less electricity. Same building. Same guest experience — actually better, because they’re not waiting for the whole building to power up before they can use their room.

What to Explore Next

• Try Astro — Build a simple blog with one or two interactive islands. The client:load / client:visible directives are immediately satisfying to work with.
• Read about React Server Components — Next.js 13+ implements a similar philosophy: components are server-only by default, client behavior is opt-in.
• Look into Core Web Vitals — Understanding LCP, FID, and CLS will make you viscerally understand why sending less JavaScript matters.
• Inspect the sites you use — Open DevTools on any blog or news site and look at the JavaScript bundle size. Then open a web app like Figma or Notion. The difference will make Islands Architecture feel immediately practical.

The best architecture decisions aren’t about using the newest tool — they’re about matching the right tool to the shape of the problem. Islands Architecture is one of the clearest examples of that principle in modern web development.

Found this helpful? Follow me for more content on navigating the modern tech job market.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! 🌹. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub
 — Noran 🌹

You studied the algorithms. You practiced LeetCode. But now you’re staring down an AI interviewer — and the rules have changed.

AI-powered interviews are becoming the new normal in tech hiring. Whether it’s a fully automated screening round or an AI co-pilot scoring your answers alongside a human, one thing is clear: the way you communicate matters just as much as what you actually know.

Here’s everything I learned about cracking the AI interview — broken down by question type, with tactical tips you can use right away.

1. The 30-Second “Introduce Yourself” Formula

This is the question everyone underestimates. It sounds simple, but it’s your first impression — and AI systems are trained to evaluate structure, clarity, and relevance from the very first sentence.

Here’s the formula that works:

Step 1 — Say exactly who you are professionally. Not your life story. One clear sentence: your role, your domain, your years of experience. “I’m a backend engineer with five years of experience building distributed systems at scale.”

Step 2 — Share your single strongest skill or achievement. Pick one. The AI is looking for signal, not a resume dump. “My main strength is designing APIs that reduce latency — I cut response times by 40% at my last company.”

Step 3 — Explain why you’re here for this specific job. Connect the dots between your background and this role. Generic answers like “I’m passionate about technology” are invisible to AI scoring. Specificity wins. “I’m applying because your team is working on real-time data pipelines, which is exactly where I’ve spent the last three years.”

Three sentences. Tight. Relevant. Done.

2. Technical Questions: Quality Over Quantity

One of the most common mistakes in technical interviews — AI or human — is listing every tool you’ve ever touched:

“I know Python, Java, React, Node.js, Kubernetes, Terraform, Docker, Kafka, Redis, Spark…”

AI interviewers don’t reward long lists. They reward depth. When you rattle off 15 technologies without explanation, you’re giving the system nothing concrete to evaluate.

The better approach: Pick one or two tools and explain how you use them.

Instead of: “I use Kafka for messaging.”

Say: “I use Kafka as the backbone of our event-driven architecture. Specifically, I design topics around domain events and use consumer groups to horizontally scale processing — this lets us handle around 200,000 events per second without bottlenecking the downstream services.”

That answer tells the AI: you understand the tool, you’ve applied it in a real context, and you know the why behind your decisions. That’s what gets you to the next round.

3. Problem-Solving Questions: Show Your Logic, Not Just the Answer

When AI evaluates your problem-solving, it’s not just looking for the correct answer. It’s analyzing your reasoning process — specifically whether you think in clear, structured steps.

Here’s the three-part structure to follow:

1. Define the problem. Restate it in your own words. This shows you understand the scope before jumping to solutions. “So the core issue is that our deployment pipeline is causing 15-minute downtime windows, which is unacceptable for a 24/7 service.”

2. Walk through your solution step by step. Use signpost words: first, next, then, finally. These signal structure to both AI and human listeners. “First, I’d set up a blue-green deployment to eliminate downtime. Next, I’d add automated smoke tests to validate the new environment before switching traffic. Then, I’d implement a rollback trigger if error rates spike within the first five minutes.”

3. Explain how you’ll measure success. This is the step most candidates skip — and it’s the one that separates good answers from great ones. It shows you’re not just fixing problems, you’re making sure they stay fixed. “I’d measure success by tracking deployment-related incidents over the next 30 days and confirming downtime drops to under 30 seconds per release.”

Problem → Steps → Metric. Every time.

4. Communication & Teamwork Questions: The Non-Technical Test

This type of question often involves a scenario like:

“Explain how a recommendation system works to a marketing manager.”

It sounds random, but the purpose is deliberate: AI is measuring whether you can translate complex concepts into business language for non-technical stakeholders. In real jobs, this skill is priceless.

The trap most engineers fall into: explaining the algorithm. The ML model, the collaborative filtering, the vector embeddings. That’s the wrong frame.

What the AI wants to see: Focus on what the technology does for the business or the user.

Good answer: “A recommendation system looks at what similar users have liked in the past and uses that to predict what a specific user is most likely to engage with next. For a marketing manager, think of it as an automated way to show each customer the most relevant product at the right moment — which increases click-through rates and reduces the cost of generic, untargeted campaigns.”

No jargon. Real-world results. Business language. That’s the winning formula.

5. Motivation & Personality Fit: Be Specific, Be Genuine

When asked about your motivations or opinions on big topics — like “What are the risks of AI in healthcare?” — vague answers will hurt you.

AI scoring systems flag answers that are too broad or too safe. Don’t say: “AI has many risks and also many benefits.” That’s filler.

Instead, pick a specific angle and own it. For healthcare AI, for instance:

• Data privacy — patient data is among the most sensitive data that exists, and AI models trained on it create real exposure if not properly governed.
• Safety and validation — unlike a consumer app, a wrong prediction in a clinical setting can have life-or-death consequences. Models need rigorous validation pipelines before deployment.

Naming concrete dimensions shows you’ve actually thought about the topic. It also makes your answer memorable — AI scoring rewards specificity.

6. The Universal Answer Framework: Situation → Action → Result

Regardless of question type, the highest-scoring answers follow a simple structure:

• Situation: Set the context. What was the problem or challenge?
• Action: What did you specifically do to address it?
• Result: What happened? Quantify it if you can.

“Our data ingestion pipeline was dropping roughly 5% of events during peak hours (Situation). I profiled the bottleneck, identified that our single-threaded consumer was the culprit, and refactored it into a multi-threaded implementation with a bounded queue (Action). After the fix, we saw zero event loss across the next 30 days and processed 3x the previous peak volume (Result).”

Notice the number: 3x. AI systems are trained to look for quantified business outcomes. If you improved something, say by how much. If you reduced something, say the percentage. If you built something, mention the scale.

A vague answer will prompt follow-up questions. If you say “I use Excel for data analysis,” the AI will ask: “Which functions? What method?” Be specific upfront and save everyone the time.

7. Time Management: The 2.5-Minute Rule

Here’s something most people don’t know: if your answer runs past about 2.5 minutes, AI systems start losing scoring confidence.

They’re optimized to capture structured, focused responses — not monologues. Long answers tend to drift, and drift hurts your score.

The fix is discipline:

• Use your structure (Situation → Action → Result) to stay on track.
• Lead with the most important point, not background context.
• Use numbers to compress information. “Reduced latency by 60%” says more in five words than a two-minute explanation.

8. Handling Questions You Don’t Understand

Don’t panic. Don’t guess. Don’t stay silent.

The right move is to pause and ask for clarification — genuinely and without apology:

“Could you please clarify that question? I want to make sure I’m answering what you’re actually asking.”

This is not a weakness. It’s a communication signal. In a real team environment, asking for clarity before diving into a solution is exactly what senior engineers are supposed to do.

9. The Silence Trap (And How to Escape It)

Here’s a quirk of AI interview systems that catches a lot of people off guard: silence reads as hesitation or disengagement.

If the AI asks a question and you sit quietly for several seconds thinking, some systems will interpret it as a non-answer and move on — before you’ve even started.

The fix is simple: speak to pause.

Instead of silence, say:

• “Let me take a moment to think through that.”
• “That’s a great question — give me a second to structure my answer.”
• “Can you rephrase that slightly? I want to make sure I’m addressing the right thing.”

Talking while you think — even briefly — keeps the AI engaged and shows self-awareness.

10. Body Language Still Matters

Even in a fully AI-powered video interview, your physical presence is being analyzed. Here’s what the system is actually watching for:

• Eye contact with the camera — not the screen. This reads as direct, confident communication.
• Posture — sitting upright signals engagement and professionalism.
• Natural smiling — forced smiles read as anxiety; genuine ones read as confidence.
• Calm hand movements — expressive but controlled gestures signal engagement; excessive fidgeting signals nervousness.

It sounds simple, but these nonverbal signals make up a meaningful portion of your overall score. Set up your environment well: good lighting, camera at eye level, minimal background distractions.

The Short Version

If you take nothing else from this article, take this:

• Be structured. Every answer should have a clear beginning, middle, and end.
• Be specific. Numbers, tool names, real outcomes — they all beat vague generalities.
• Be concise. Under 2.5 minutes, every time.
• Never go silent. Speak to pause if you need time to think.
• Mirror the job description. Use the keywords from the role you’re applying for — they matter more than you think.

AI interviews aren’t about tricking a machine. They’re about communicating clearly, thinking in structured steps, and showing the value you bring — just with a different audience on the other end of the camera.

Go nail it.

Found this helpful? Follow me for more content on navigating the modern tech job market.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! ❤️. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub
 — Noran 🌹

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community. Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community.

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter. And before you go, don’t forget to clap and follow the writer️!

How to Ace an AI Interview: The Complete Playbook for Tech Professionals was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’ve just started learning React, there’s a very high chance that useEffect confused you.

You watched a tutorial, copied some code, and suddenly:

• Your API request runs twice
• Your component keeps re-rendering
• Someone tells you, “Just add it to the dependency array,” without explaining why

This usually makes beginners feel like React is “magic” or “too complex”.

The truth is: useEffect is not hard at all — it’s just explained in a way that doesn’t match how beginners think.

In this article, we’ll explain useEffect slowly, visually, and in plain English, with simple code examples and real-life analogies.
By the end, you won’t just use useEffect — you’ll actually understand when and why it runs.

First: Forget React for a Second 🧠

Think about real life.

You do things in response to events:

• You open the fridge → the light turns on
• You click a button → something happens
• You enter a page → data is loaded

👉 These are called side effects.

In React:

• Rendering UI = main job
• Doing extra things = side effects

Examples of side effects:

• Fetching data from an API
• Adding an event listener
• Updating the document title
• Setting a timer

That’s exactly what useEffect is for.

What is useEffect In ONE sentence?

useEffect lets you run code after React renders the UI.

That’s it. Nothing more.

The Basic Shape of useEffect

useEffect(() => {
  // code you want to run
}, []);

Let’s break it slowly.

Part 1: The function

() => {
  console.log("Hello from useEffect");
}

This is what you want to run.

React says:

“I’ll run this function after rendering.”

Part 2: The dependency array []

This part controls WHEN the effect runs.

Think of it as:

“Hey React, run this effect WHEN these values change.”

Case 1: Empty dependency array []

useEffect(() => {
  console.log("Component mounted");
}, []);

What happens?

• Runs once
• After the component renders the first time
• Never again

Mental model 🧠

“Run this when the component appears on the screen.”

Common use cases:

• Fetch data
• Set up subscriptions
• Initialize something

Example:

useEffect(() => {
  fetch("/api/users")
    .then(res => res.json())
    .then(data => console.log(data));
}, []);

Case 2: Dependency array with values

useEffect(() => {
  console.log("Count changed");
}, [count]);

What happens?

• Runs on first render
• Runs again every time count changes

Mental model 🧠

“React, watch count. If it changes, run this.”

Example:

const [count, setCount] = useState(0);
useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]);

Now:

• Click button
• count changes
• Effect runs
• Title updates

Simple ✅

Case 3: No dependency array (❌ beginner trap)

useEffect(() => {
  console.log("Runs every render");
});

What happens?

• Runs after every render
• That means: state change → render → effect → state change → render → 💥 infinite loop

Rule:

🚫 Avoid this unless you REALLY know why you need it

Why does React need useEffect anyway?

Because React renders pure UI.

This is BAD:

function App() {
  fetch("/api/data"); // ❌ side effect during render
  return <div>Hello</div>;
}

This is GOOD:

function App() {
  useEffect(() => {
    fetch("/api/data");
  }, []);
return <div>Hello</div>;
}

React likes:

• Render first
• Do side effects occur after

Cleanup — Stop Effects Before Leaving

Sometimes you start something ongoing, like:

• A timer
• Listening for a change (like chat messages)

If you don’t clean up, problems happen:

• Memory leaks
• Multiple timers stacking
• Event handlers running multiple times

Example with cleanup:

useEffect(() => {
  const interval = setInterval(() => {
    console.log("Tick");
  }, 1000);

  return () => {
    clearInterval(interval); // stop the timer when component leaves
  };
}, []);

Mental model 🧠

“When this component leaves the screen, clean up.”

The GOLDEN RULE of useEffect

Everything you use inside useEffect that can change
MUST be in the dependency array.

Example:

useEffect(() => {
  console.log(userId);
}, [userId]);

This keeps your app predictable and bug-free.

One Last Simple Analogy 💡

Think of useEffect like this:

Final Checklist ✅

Before writing useEffect,Ask yourself:

1. Is this a side effect?
2. When should it run?

• Once → []
• When value changes → [value]

Do I need cleanup?

If you answer these, useEffect becomes easy.

Conclusion + Tiny Exercise ✅

useEffect is React’s way of saying:

“Run this side effect after rendering, watch the things you care about, and clean up when leaving.”

Once you understand the timing, dependency array, and cleanup, useEffect becomes predictable — not scary.

Exercise for you:

1. Create a state name with useState("").
2. Use useEffect to update document.title whenever name changes.
3. Add a timer inside the effect and clean it up when the component unmounts.

This small practice will cement your understanding immediately.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! ❤️. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹

React Behind the Scenes, useEffect() was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome back to our React learning journey! 🔥
In this part, we’re going to uncover one of the most fundamental — yet often misunderstood — concepts in React: the useState() Hook.

If you’ve ever wondered how your React component “remembers” a user’s input, keeps track of a counter, or updates instantly when something changes — that’s all thanks to useState().

In this guide, we’ll explore:

• What useState() Really does under the hood.
• Why normal variables don’t work the same way in React.
• How React keeps track of your component’s memory using hook order.
• And the golden rules every developer must follow to avoid those scary “Invalid Hook Call” errors.

So grab your coffee ☕, get comfy, and let’s open the locker door to React’s memory system — one hook at a time. 🔐✨

🧩 1. What is useState()?

useState() is a React Hook that lets your function components remember data between renders.

It allows your component to have its own internal memory (called state).

In plain words:

It’s how React components can “remember things” — like user input, toggle status, count, or fetched data.

🧠 Example

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

return (
    <button onClick={() => setCount(count + 1)}>
      You clicked {count} times
    </button>
  );
}

📍 Here’s what’s happening:

• useState(0) — tells React:
• “Hey, I want a piece of memory called count, starting at 0.”
• React saves 0 in a hidden memory slot (position/spot).
• setCount — gives you a way to update that memory later.
• When you click the button:
• React updates the stored value (to count + 1).
• Then React re-renders the component to show the new number.

🧠 2. Why do we need useState()?

Because normal variables don’t persist between renders.

For example:

function Counter() {
  let count = 0;
  const increment = () => {
    count++;
    console.log(count);
  };
  return <button onClick={increment}>Click</button>;
}

This looks fine — but it doesn’t work in React. 😅 Why?

Because every time React re-renders this component, it runs the function from scratch, so count is reset to 0.

That’s why we need React to remember the variable for us → that’s what it useState() does.

⚙️ 3. How to use useState()

🧩 Syntax

const [state, setState] = useState(initialValue);

🧪 Example

const [name, setName] = useState("Noran");

// Access current state
console.log(name); // "Noran"
// Update state
setName("Sara");

🧠 Rules for using useState

1. ✅ Only call it at the top level of your component.
   (No loops, conditions, or nested functions.)
2. ✅ Call it in the same order on every render.
   (React relies on this order to match state slots.)
3. ✅ Use it only inside React components or custom hooks.

🔍 Curiosity mood on🔥

1. Why useState (and other hooks) must be called at the top level
2. Why only inside React components or custom hooks?
3. Why order matters
4. So what happens if you call hooks inside conditions or loops?

🧩 Why useState (and other hooks) must be called at the top level

Let’s start by understanding how React tracks hooks internally.

React keeps an internal array (or linked list) of hook “slots” for each component — like this:

Component A memory:
Slot 0 → useState(count)
Slot 1 → useEffect(...)
Slot 2 → useState(name)

When your component renders, React walks through your code line by line, and each time it sees a Hook call (like useState), it says:

“Okay, that’s hook #1 → I’ll use slot 0.”
“Next hook → slot 1.”
“Next hook → slot 2.”

React doesn’t use variable names (count, name, etc.) to track state — It only depends on the order of hook calls.

🧠 So what happens if you call hooks inside conditions or loops?

if (isLoggedIn) {
  useState("user");
}
useState("theme");

Imagine on the first render, isLoggedIn = true, so:

Slot 0 → useState("user")
Slot 1 → useState("theme")

But on the next render, isLoggedIn = false, so the first useState is skipped:

Slot 0 → useState("theme") ❌ (wrong!)

Now React is totally confused 😵 — The slots got shifted, so it gives the wrong state value to the wrong variable!

That’s why React says

❌ Don’t call hooks inside conditions, loops, or nested functions.
✅ Always call them at the top level, in the same order every render.

🧩 Why only inside React components or custom hooks?

Hooks are a bridge to React’s internal memory system — That memory only exists while React is rendering a component.

If you call a hook outside of a React component (like in plain JS code):

const [count, setCount] = useState(0); // ❌ outside a component

React will say:

“Wait — I’m not rendering anything right now!
There’s no component context, no memory slot to attach this to.”

So you’ll get an error like:

Invalid hook call. Hooks can only be called inside the body of a function component.

Because React can’t store that state anywhere — 
No “memory box” exists outside the component render cycle.

🧩 Why order matters

Hooks are position-based, not name-based.

So if on one render, you call:

useState("count");
useState("theme");

React assumes:

• slot 0 → count
• slot 1 → theme

If on the next render, you call:

useState("theme");
useState("count");

React will assign:

• slot 0 → theme
• slot 1 → count

Now your states are swapped 😬 — it’s chaos.

That’s why the order must always stay the same every render.

🧠 Analogy: “Hook lockers in a gym”

Imagine React gives every component a row of lockers.

• Each useState gets one locker.
• React remembers which locker number belongs to which state by order (not name).

If you sometimes skip locker #1 or open a new locker mid-way,
React will start putting your stuff in the wrong lockers.

That’s why React says:

Always open the lockers in the same order every time!

💬 Real-world analogy (super simple)

Imagine React as a locker system at the gym 🏋️‍♀️

• Each hook call gets a locker.
• The locker has a number (its index).
• useState() Put your stuff in that locker (the data).
• When you come back (re-render), React remembers which locker belongs to you and retrieves your stuff.
• When you call setStateYou replace what’s inside the locker — and React refreshes your view to match what’s new inside.

🧠 In One Sentence

useState() gives React components the power to remember values between renders and update the UI automatically when those values change.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! ❤️. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹

React Behind the Scenes, useState() was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

I still remember staring at my screen, feeling a mix of excitement and panic. A browser extension I wanted to contribute to wasn’t working, and I had no idea if I could actually fix it. My hands hovered over the keyboard, heart racing, thinking, “What if I break everything? What if I can’t figure this out?” Little did I know, this one small bug would not only get fixed but also give me a confidence boost I’ll never forget — and spark my first real journey into open source.

The Nervous First Steps

I forked the repository, cloned it, installed the dependencies… and instantly got stuck. The development setup wasn’t something I’d ever done in this exact way. Vite, Vitest, web extension polyfills — it was a lot to take in.

I felt nervous, honestly. I kept thinking, “Am I even capable of understanding this codebase? Everyone contributing here must be super experienced.”

But I started small: exploring the folder structure, reading the docs, and understanding how actions were recorded. I wanted to see the bigger picture — how clicks, inputs, navigation, scrolls, and form submissions were captured and then transformed into JSON files.

And slowly, the intimidating became exciting. Every function I read, every TypeScript type I understood, gave me a tiny spark of confidence.

That One Bug That Made Me Feel Alive

Then came the real test: there was a bug in the extension. The recorder wasn’t capturing clicks on a dropdown menu item. For most people, it might have been just another GitHub issue. For me, it felt like a challenge, a puzzle waiting to be solved.

I dove into the code, tracing how events were captured by the extension. Hours passed. I tried different approaches, looked at event listeners on the website, and then… I noticed it.

The extension was listening for click events, but the website used mousedown for that dropdown. That tiny mismatch was why the recorder failed.

My heart raced as I implemented the fix, ran the extension, and… it worked. The dropdown item was finally being recorded perfectly.💥

I can’t describe the feeling — pure joy mixed with disbelief. “I did it. I actually did it.”

That moment hit me like a wave. I felt a surge of confidence I hadn’t felt before. I realised: if I can solve this, I can solve more. I can contribute meaningfully.

From Fixing Bugs to Understanding the Platform

After that, I started exploring more of the project. I worked on multi-page recording, overlay controls, multi-selector strategies, and real-time feedback.

I collaborated with other contributors via GitHub: branching, pull requests, code reviews, and issue tracking.

I also contributed to the main SaveAction platform, the no-code automated testing system that reads the JSON from the recorder and replays user interactions. I debugged core algorithms, optimized workflows, and improved documentation for future contributors.

Each task, no matter how small, reinforced something crucial: open source isn’t just about writing code. It’s about learning, problem-solving, and growing your confidence.

What I Learned

1. It’s okay to be nervous. Every contributor starts somewhere. Feeling unsure is part of the process.
2. Persistence pays off. That dropdown bug could have defeated me if I had given up. But taking it step by step, reading the code carefully, and testing assumptions made all the difference.
3. Collaboration is priceless. Code reviews, discussions, and feedback from other contributors were eye-opening. You learn more by working with others than by working alone.
4. Confidence is built in small wins. Fixing that one bug didn’t just solve a problem — it made me believe in my abilities.

Why I’ll Keep Contributing

Contributing to SaveAction taught me more than any tutorial or course could. It gave me confidence in my skills as a frontend engineer and showed me the joy of being part of a community.

Every pull request merged felt like a tiny victory, every bug fixed felt like levelling up. I now look at open source not as an intimidating world of experts but as a playground for learning, experimenting, and growing.

For anyone thinking about contributing for the first time, here’s what I’d say:

Start small. Explore the code. Don’t be afraid to ask questions. And when you solve that first real problem? Trust me, you’ll never forget it.

Open source is more than code. It’s confidence, curiosity, and the joy of building something bigger than yourself. And once you experience that first “I did it” moment, you realise — you can do so much more than you ever imagined.

And this is just the beginning! I’m already looking forward to my next contribution. In my upcoming article, I’ll share more about the SaveAction project, dive into the next bug I’m going to fix, and maybe even reveal a new feature I’ll be adding. I can’t wait to continue this journey, and I’m thrilled to take you along as I learn, debug, and grow even more in open source.

You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹

Introduction

The state in React is sneaky.

You think it’s a normal variable… until it smiles at you and says, “Haha, not so fast.”

Don’t worry — we’ll decode this mystery together. By the end of this article, you’ll know exactly why your console.log keeps lying to you (and you’ll never fall for its tricks again).

🧠 Understanding “State as a Snapshot” in React

When you first start using React, state variables

const [count, setCount] = useState(0) 

— look like regular JavaScript variables.

But here’s the catch:
👉 They don’t behave like normal variables at all.

🧩 Normal JS variables vs React state

In regular JavaScript:

let number = 0;
number = number + 1;
console.log(number); // 1

When you change a variable, its value updates immediately.

But in React:

const [number, setNumber] = useState(0);
setNumber(number + 1);
console.log(number); // still 0!

Even though you just “set” it, number hasn’t changed yet.

That’s because React treats state differently — it treats it as a snapshot in time.

📸 What does “snapshot” mean?

Imagine React takes a photo of your component every time it renders.

That photo (the “snapshot”) captures:

• All your state variables (like number)
• All your props
• All your event handlers

When your component is running (during one render), it’s looking at that frozen photo — even if you callsetState(), you’re just asking React to take a new photo next time.

🧠 Key idea:

Setting state doesn’t change the state right away.
It just requests React to re-render with a new snapshot.

⚙️ Example: The +3 Counter

export default function Counter() {
  const [number, setNumber] = useState(0);

return (
    <>
      <h1>{number}</h1>
      <button onClick={() => {
        setNumber(number + 1);
        setNumber(number + 1);
        setNumber(number + 1);
      }}>+3</button>
    </>
  )
}

When you click the button, you might expect the number to go up by 3.
But it only increases by 1. Why?

Because during that one “photo” (render), number is still 0.
So each line effectively does:

setNumber(0 + 1); // sets to 1
setNumber(0 + 1); // sets to 1 again
setNumber(0 + 1); // sets to 1 again

After React finishes running your event handler, it takes a new photo — and now number is 1.

That’s why you only see it increase once.

🕰️ State over Time

React doesn’t update state instantly — it updates it over time, between renders.

For example:

<button onClick={() => {
  setNumber(number + 5);
  alert(number);
}}>+5</button>

This alert shows 0, not 5, because number in this render is still 0.
React hasn’t re-rendered yet.

Even if you delay the alert:

setNumber(number + 5);
setTimeout(() => alert(number), 3000);

You’ll still see 0, because the function “remembers” the state from the render it was created in.

💡 Why React Does This

This “snapshot” behaviour isn’t a bug — it’s a design choice.
It helps React keep your UI predictable and stable.

• Each render is self-contained — everything inside it is consistent.
• You never get “half updated” UIs where only some parts have changed.
• You can trust that your event handlers always use the state that existed when they were created.

🧰 How React Manages It

Think of React’s state as being stored outside your component, like on a shelf.

1. Every time React renders, it reads the state value from that shelf.
2. Your component gets a copy (snapshot) of that value for that render.
3. When you call setState, React doesn’t change the snapshot — it just says:

• “Hey React, next time you render, use this new value.”

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! 🌹.

You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, Instagram. You can also subscribe to our weekly newsletter.

And before you go, don’t forget to clap and follow the writer️!

🧠 Understanding “State as a Snapshot” in React was originally published in JavaScript in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome back to a new journey with React.🔥

🧭 What’s Really Happening Inside React?

If you’ve ever used useState() or useEffect() and wondered,
“Wait — how does React actually remember this data between renders?”,
You’re in the right place.

Most developers learn Hooks by example — they use them, but don’t truly understand what’s happening behind the scenes.

In this deep dive, we’ll lift the curtain on React’s internal memory system — 
how Hooks “hook into” React’s brain,
how state actually persists when your component re-renders,
and why the order of your Hooks matters more than you might think.

By the end of this article, you won’t just know how to use Hooks — 
You’ll understand how React thinks when running them.

Welcome to the inner workings of React Hooks — 
where simple functions gain memory, and React’s magic becomes logic. ⚙️✨

🧠 1. What is a Hook?

A Hook in React is a special function that lets you “hook into” React’s internal features — like state, lifecycle, and context — inside functional components.

In other words, Hooks let functions act like classes — they can now store data, handle events, and react to changes.

🧩 Example Hooks:

• useState() → for state (data that changes)
• useEffect() → for side effects (fetching data, timers, etc.)
• useContext() → for global data
• useRef() → for referencing DOM elements

⚙️ 2. What is useState()?

useState() is a React Hook that lets your component remember values between renders.

Without it, every time your component re-renders, all variables would reset to their default.

So useState gives your component memory 💾.

🧩 Syntax:

const [state, setState] = useState(initialValue);

💬 Example:

function Counter() {
  const [count, setCount] = useState(0); // 👈 initialize state with 0
return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>
        Click Me
      </button>
    </div>
  );
}

🧠If it still isn’t clear — that’s perfectly normal. Let’s switch on curiosity mode🔍 and walk through what’s happening, step by step:

When the component first renders, React calls useState(0) and remembers:

• the current value → 0
• the updater function → setCount
• When you click the button, React calls setCount(count + 1)
  That tells React:
• “Hey, I have new data — please re-render me with count = 1.”
• React re-renders the component, and now count becomes 1.

So every render → React gives you the latest state value.

🧠 What does “Hook into React’s internal features” mean?

Think of React as a machine that:

• Keeps track of state (data)
• Watch for changes
• Re-renders your UI when data changes

But by default, JavaScript functions are stateless — 
Every time you call a function, it forgets everything from before.

So, React gives you a way to “hook into” its internal system of memory and updates.

💡 That’s why they’re called Hooks — 
They hook your function component into React’s internal memory system, which keeps track of data between renders.

🧩 Simple analogy:

Imagine React as a notebook 📒

• Normally, when you run a JS function, you write something and throw away the page.
• But React keeps a notebook for each component.
  Each time your function runs again, it opens the same notebook and looks up what you wrote before (your state).

useState, useEffect, etc., are like pages in that notebook.

⚙️ Why do we say “Hooks let functions act like classes”?

Before Hooks, only class components could use:

• State (this.state)
• Lifecycle methods (componentDidMount, componentDidUpdate, etc.)

But functional components couldn’t — they were just dumb renderers.

Hooks changed that.
Now a functional component can store state and react to changes — just like a class component — but with simpler syntax.

Compare 👇

🧩 Before (Class Component):

class Counter extends React.Component {
  state = { count: 0 };

increment = () => this.setState({ count: this.state.count + 1 });
  render() {
    return (
      <button onClick={this.increment}>
        Count: {this.state.count}
      </button>
    );
  }
}

🧩 After (Functional + Hook):

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
}

Both do the same thing — 
The Hook version is just shorter, cleaner, and more “functional”.

⚙️How Hooks work internally

Let’s demystify this 👇

• When React renders your component, it keeps a hidden array of states inside it.
• Each time you call useState(), React adds one item to that list.

Example:

function Profile() {
  const [name, setName] = useState("Noran");   // 1️⃣ stored at index 0
  const [age, setAge] = useState(22);          // 2️⃣ stored at index 1
// render logic...
}

React internally keeps something like:

let hookStates = [
  "Noran", // index 0
  22       // index 1
]

When you call setName("Noor"), React:

1. Updates hookStates[0] = "Noor"
2. Re-renders your component
3. Reads from hookStates again → now name = "Noor"

So React knows which Hook value to return by the order you call them — 
That’s why Hooks must be at the top level and not inside conditions.

🧠 The Core Idea of Hooks

1️⃣ Normal JavaScript functions:

• Run → do their job → forget everything.
• Variables inside them vanish after the function ends.

function sayHi() {
  let count = 0;
  count++;
  console.log(count);
}
sayHi(); // 1
sayHi(); // 1 again (it forgets)

Every call starts fresh, because functions in JS don’t have memory by default.

2️⃣ React components re-render

React needs to:

• Remember some data between renders (like a counter, input value, toggle)
• Re-render when that data changes.

Therefore, it requires functions that can retain information across multiple executions.

3️⃣ That’s why Hooks exist

Hooks are like functions with memory — 
They “hook into” React’s hidden memory system, allowing data to persist between renders.

When you use a Hook like useState:

• React remembers your variable (state)
• Gives you a way to update it (setState)
• And when you update → React re-runs the component with new data

function Counter() {
  const [count, setCount] = useState(0); // 👈 Hook with memory
return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

Now:

• When the component re-renders, React doesn’t reset count to 0.
• It looks up the previous value from its internal memory.
• That’s how it remembers and reacts to changes.

They “hook into” React’s hidden memory system, allowing data to persist between renders. How do hooks hook into the React memory system?

⚙️ React’s “hidden memory system”

• React’s genius solution is to give every component its own internal memory.
• You can think of it as an array that React keeps secretly for each component.

For example, if you have:

function Profile() {
  const [name, setName] = useState("Noran");
  const [age, setAge] = useState(22);
  return <h1>{name} - {age}</h1>;
}

React internally keeps something like:

componentMemory = [
  "Noran", // 0th Hook → name
  22       // 1st Hook → age
];

So, React doesn’t forget — it keeps your data in that “hidden memory array.”

🪝 How Hooks “hook” into that memory

Here’s what happens behind the scenes when React renders your component:

• React starts rendering your component and sets a pointer to track which Hook is being used (like an index starting at 0).

currentHookIndex = 0;

• You call the first Hook:

const [name, setName] = useState("Noran");

• React looks at its memory at the index 0.
• If it’s the first render, it stores "Noran" there.
• On later renders, it retrieves the existing value.
• Then React increments the index:
• currentHookIndex++;

Next Hook

const [age, setAge] = useState(22);

1. React looks at its memory at the index 1 this time, and does the same.
2. After rendering finishes, React resets the currentHookIndex back to 0 for the next render.

• So, Hooks “hook into” React’s memory because each one is linked to a specific slot in that memory array.
• React knows which state belongs to which Hook by the order they’re called.
• That’s why you must not put Hooks inside if or for —
  It would mess up the order, and React would lose track of which memory slot belongs to which state.

🧩 4️⃣ When you call setState()

When you call something like:

setName("Noor");

React:

1. Updates that internal memory slot (e.g., index 0 → “Noor”)
2. Marks the component as “dirty” (needs re-render)
3. Call your component function again
4. When it runs again, React starts from hookIndex = 0
   and gives you back "Noor" as the first Hook’s value.

This loop repeats — 
And that’s how Hooks keep your data alive between renders.

🔍 5️⃣ In plain JS (simplified example)

Here’s a tiny fake version of how React might implement this:

let componentMemory = [];  // React’s internal memory
let currentHook = 0;


function useState(initialValue) {
  const hookIndex = currentHook;
  componentMemory[hookIndex] = componentMemory[hookIndex] ?? initialValue;
  const setValue = (newValue) => {
    componentMemory[hookIndex] = newValue;
    render(); // triggers re-render
  };
  currentHook++;
  return [componentMemory[hookIndex], setValue];
}
function render() {
  currentHook = 0; // reset before rendering
  Counter();       // re-run component
}
function Counter() {
  const [count, setCount] = useState(0);
  console.log(count);
  // simulate click
  setCount(count + 1);
}

Each time Counter() runs, React pulls the right value from its internal componentMemory.

🧭 So in short

Hooks “hook into” React’s internal memory system because React keeps a hidden array of Hook values per component,
and every time you call a Hook, React knows which memory slot that Hook is tied to — by call order.

That’s how:

• Data persists between renders ✅
• Functions can “remember” their state ✅
• React knows when to re-render ✅

Summary diagram

🏪 React Hooks Analogy — “The Hook Store”

Think of React as managing a mall full of tiny stores 🏬
Each component (like Counter, Profile, etc.) has its own mall section.
Inside that section, React opens one store for every Hook you call.

🎯 How It Works Step-by-Step

1. 🏗️ Render starts
   React says: “Okay, time to render the Profile component. Let’s open its memory mall.”
2. 🧾 React assigns store IDs (indexes)
   Each hook gets a unique store ID based on its order in the code:

const [name, setName] = useState("Noran"); // Store #0
 const [age, setAge] = useState(22) // Store #1

1. 📦 Each store saves data
   React puts your data into the correct store:

Store #0 → "Noran"
Store #1 → 22

1. 🔍 React remembers the location (ID)
   When React renders again, it goes to the same stores in the same order
   (That’s why hooks must always be called in the same order — React relies on store #0, #1, #2, etc.).
2. 🧮 When you update state (setState)
   React goes to that exact store ID, updates the stored value,
   and says: “Hey, something changed — let’s re-render this component.”
3. 🔁 Re-render time!
   During re-render:

• React reopens the same “mall section” for that component.
• Goes to each store (Hook slot) in order.
• Reads the updated values from each one.
• Then re-renders the UI using those fresh values

Hooks in a Nutshell

• React gives each component its own hidden memory array.
• Each Hook (like useState) gets a fixed slot in that array, in call order.
• On re-render, React reads and updates values from those same slots.
• That’s why Hooks must always be called in the same order — it’s how React knows which state belongs where.
• In essence, Hooks turn ordinary JS functions into stateful, reactive components.

🔥 What’s Next?

This was just the beginning of our deep dive into React Hooks — 
We uncovered how React secretly remembers your data and keeps your components alive between renders.

In the next articles, we’ll explore each Hook step by step — starting with the most essential ones:
useState, useEffect, and useContext.
You’ll learn how they work, when to use them, and the hidden rules that make them so powerful.

So… are you ready to go deeper into the React world? 🔥🔥
Follow along — the next chapter drops soon. 🚀

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! ❤️.

You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹

Welcome back to a new journey with React.🔥

If you’ve ever written React code and wondered “how does map() really work under the hood?”, or “why do events bubble up to their parents?”, you’re in the right place.

In this guide, we’ll break down three core concepts every front-end developer should master:

1. map() — how we transform and render data efficiently in JavaScript and React.
2. Props — how React components talk to each other by passing data and functions.
3. Event Handling & Propagation — how user actions flow through the DOM and how React manages them.

Think of this as understanding how your app listens, talks, and reacts — the foundation of everything you’ll build with React.

Grab your coffee, get comfortable, and join me on this next step of our React journey.☕

🔍 Whenever you spot this symbol, it means the curiosity mode is on ✨🔥

🔍🧭 What is map() in JavaScript?

👉 map() is a built-in array method that allows you to:

Transform each item in an array into something new,
and return a new array with the transformed results.

It does not change (mutate) the original array — it creates a new one.

💡 Simple Example

const numbers = [1, 2, 3, 4];
const doubled = numbers.map(num => num * 2);
console.log(doubled); // [2, 4, 6, 8]
console.log(numbers); // [1, 2, 3, 4]  (original not changed)

So:

• Input: [1, 2, 3, 4]
• Output: [2, 4, 6, 8]
• Action: multiply every item by 2.

⚙️🔍 What does it do?

It loops through each element of the array, applies a function you provide (called the callback function) to each element, and collects the results into a new array.

Think of it as a machine:

[1, 2, 3]  →  map(fn)  →  [fn(1), fn(2), fn(3)]

🧠 How it works internally

You can imagine map() doing this behind the scenes:

function customMap(array, callback) {
  const newArray = [];
  for (let i = 0; i < array.length; i++) {
    const result = callback(array[i], i, array);
    newArray.push(result);
  }
  return newArray;
}

That’s basically how it’s implemented in JS!

🧩 Syntax

array.map(function(element, index, array) {
  // return something new
});

Or using an arrow function:

array.map((element, index, array) => expression);

📦 The map() arguments

Example:

[10, 20, 30].map((num, index, arr) => {
  console.log(num, index, arr);
  return num + 5;
});

🧰 When do we need map()?

✅ In general JavaScript:

• When you want to transform data from one form to another.
  Example:

const names = ["noran", "ali", "sara"]; 
const upper = names.map(name => name.toUpperCase());
 console.log(upper); // ["NORAN", "ALI", "SARA"]

⚛️ In React:

map() is essential when rendering lists.

Example:

const users = ["Noran", "Ali", "Sara"];
function UserList() {
  return (
    <ul>
      {users.map(user => (
        <li key={user}>{user}</li>
      ))}
    </ul>
  );
}

React will render:

• Noran
• Ali
• Sara

Here, map() transforms an array of data → into an array of JSX elements.

⚛️ Why in React we “just give it the element”, not the index or array?

When you write this:

const users = ["Noran", "Ali", "Sara"];
function UserList() {
  return (
    <ul>
      {users.map(user => (
        <li key={user}>{user}</li>
      ))}
    </ul>
  );
}

You only use the first parameter — user.
But remember: map() still passes three arguments under the hood:

array.map((element, index, array) => { ... })

You’re simply choosing to use only the first one.

🧠 Why do we usually only use the element in React?

Because in most cases:

• We only need the data (user) to display it.
• We don’t care about the position (index) unless it’s for something like a key or styling.
• The array itself is already available in scope (users), so we don’t need it either.

So React devs often do this:

✅ Use only the element

users.map(user => <li>{user}</li>)

But we could do this if we wanted:

✅ Use element + index

users.map((user, i) => <li key={i}>{i + 1}. {user}</li>)

💡 The reason map() works perfectly in React

Because map() always returns a new array,
and React needs exactly that — an array of JSX elements to render.

Example:

users.map(user => <li>{user}</li>)

returns:

[
  <li>Noran</li>,
  <li>Ali</li>,
  <li>Sara</li>
]

React then takes that array and renders each <li> to the real DOM.

⚠️ But what about the key?

React requires a key prop when rendering lists because it needs to track elements efficiently during re-renders (for diffing).

Example:

users.map((user, index) => (
  <li key={index}>{user}</li>
))

✅ This works, but key={index} is only safe if:

• The list order never changes.

If items can be reordered or deleted, you should use a unique ID instead of the index:

users.map(user => <li key={user.id}>{user.name}</li>)

⚙️ 1️⃣ What is an event handler?

An event handler is just a function that runs when a specific event happens — like a click, typing, mouse move, submit, etc.

🧠 Think of it like:

“When this happens → do that.”

Example (plain JS):

const button = document.querySelector("button");
button.addEventListener("click", () => {
  alert("Button clicked!");
});

Here, the arrow function is your event handler.
It “handles” the click event.

⚛️ 2️⃣ In React, it’s the same idea

React gives you an easier, declarative way to attach event handlers.

Example:

function App() {
  function handleClick() {
    alert("Button clicked!");
  }
return <button onClick={handleClick}>Click Me</button>;
}

✅ Here:

• onClick is a JSX attribute (like className, id, etc.).
• handleClick is your event handler function.
• React listens for clicks on that button, and when it happens, it calls handleClick().

🧩 3️⃣ But wait — how does it actually work?

JSX is just syntax sugar.
This:

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

is translated by Babel into:

React.createElement("button", { onClick: handleClick }, "Click Me");

So when React creates the real DOM element under the hood, it:

1. Creates a <button> element.
2. Adds a real browser event listener to it (element.addEventListener("click", handleClick)).
3. So when you click → React calls your function.

That’s why it feels like magic, but it’s actually plain JS happening under the hood.

💬 What is a prop?

Props (short for properties) are inputs to components.

They allow you to pass data or functions (such as event handlers) from parent to child components.

Think of props like function parameters.

Example:

function Greeting(props) {
  return <h1>Hello, {props.name}!</h1>;
}

function App() {
  return <Greeting name="Noran" />;
}

Babel turns it into:

React.createElement(Greeting, { name: "Noran" });

in plain JS

Greeting({ name: "Noran" });

✅ What happens:

• App passes a prop: name="Noran".
• Inside GreetingYou can access it via props.name.

🧠 How can props hold functions (like event handlers)?

Props can hold any JavaScript value, including strings, numbers, arrays, functions, and more.

So, when you pass an event handler:

function App() {
  function sayHello() {
    alert("Hello!");
  }

return <Button onClick={sayHello} />;
}

✅ Here:

• onClick is a prop passed to the Button component.
• Inside ButtonYou can use it like this:

function Button(props) 
{   
    return <button onClick={props.onClick}>Click me</button>; 
}

• When the <button> is clicked, React calls props.onClick() — which is your sayHello function.

So, React doesn’t care what the function is doing; it just passes it down and runs it when needed.

🎯 Why do we use props?

Because they make components reusable and dynamic.

Example:

function Button({ label, onClick }) {
  return <button onClick={onClick}>{label}</button>;
}

function App() {
  return (
    <>
      <Button label="Say Hello" onClick={() => alert("Hello!")} />
      <Button label="Say Bye" onClick={() => alert("Bye!")} />
    </>
  );
}

Now the same A Button component can behave differently depending on the props it receives.
That’s reusability — a core React principle.

💬 3️⃣ Props are read-only

This is important. The child component (that receives props) cannot modify them — it can only read them.

Example:

function Greeting({ name }) {
  name = "Sara"; // ❌ bad practice — props should not be changed
  return <h1>Hello, {name}</h1>;
}

React follows a one-way data flow:

Parent → Child (downward only)

⚛️ How props make components reusable

Let’s take an example:

function Button({ label, color }) {
  return <button style={{ background: color }}>{label}</button>;
}

function App() {
  return (
    <>
      <Button label="Save" color="green" />
      <Button label="Cancel" color="red" />
    </>
  );
}

• App passes different props each time (label, color).
• The same Button component behaves differently → reusability.

React renders each <Button> separately with the props it got.

🧩 Props can be any data type

⚙️ Destructuring props

Instead of always writing props.name, props.age...

You can destructure:

function Greeting({ name, age }) {
  return <p>Hello {name}, you’re {age} years old!</p>;
}

Same result, cleaner code.

🔁 7️⃣ How props flow in React tree

Let’s visualise:

App
 ├── Header title="My App"
 ├── User name="Noran"
 │     └── Avatar src="profile.jpg"
 └── Footer year={2025}

Here:

• App passes props down.
• Each child receives their own props.
• Data flows one way → downward.
• If something needs to go up (like a button click), we pass a function as a prop (the event handler idea).

Simply, think about it like a parent is giving their child a gift

Imagine a parent gives their child a gift — let’s say a toy car.
Now, think of the parent as the parent component and the child as the child component.

• The parent says, “Here’s your toy car 🚗.”
  → This is like passing a prop
• <Child gift="toy car" />
• The child receives the toy car and can play with it, show it, or use it in any way.
  → That means the child component can use the prop:

function Child(props) {
   return <p>I'm playing with my {props.gift}!</p>; 
}

• But the child can’t change the gift itself — they can’t turn the toy car into a bike 🚲.
  → Because props are read-only, the child can use them, but not modify them.

🧠 So in React terms:

• Parent → passes data = props
• Child → receives data = via function parameters
• Child → can use the prop but not modify it.

⚙️ 1️⃣ What is Event Propagation?

Event propagation describes how events travel through the DOM tree when something happens — like a click.

🧠 Think of it like ripples in water:

You click a button → that click “bubbles” up through its parent elements → and each parent can also react to it.

🧭 2️⃣ The 3 Phases of Event Propagation

When an event (like a click) happens, the browser processes it in three phases:

window
  ↓
document
  ↓
html
  ↓
body
  ↓
div
  ↓
button (you clicked here)

🔹 Phase 1 — Capturing (Trickling Down)

The event starts from the top (window) and goes down to the target.
Like someone walking from the roof to the room where the click happens.

🔹 Phase 2 — Target

The event reaches the exact element that was clicked (the button itself).

🔹 Phase 3 — Bubbling (Going Up)

Then the event “bubbles” back up from the target to the top.
So the parent <div>, <body>, and even <html> can all “see” that event.

💡 3️⃣ Example: Bubbling in Action

HTML:

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

JS:

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

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

🖱️ When you click the button:

Child clicked
Parent clicked

✅ The event first triggers on the child,
then bubbles up to the parent.

🔁 4️⃣ React and Event Propagation

React uses a synthetic event system — a wrapper around the browser’s native events to make them consistent across browsers.

But propagation still works the same!

Example:

function App() {
  function handleParentClick() {
    console.log("Parent clicked");
  }

function handleChildClick() {
    console.log("Child clicked");
  }
  return (
    <div onClick={handleParentClick}>
      <button onClick={handleChildClick}>Click Me</button>
    </div>
  );
}

🖱️ Clicking the button logs:

Child clicked
Parent clicked

Because the event bubbles up through React’s virtual DOM system.

🚫 5️⃣ Stopping Event Propagation

Sometimes you don’t want the parent to react to a child’s event.

You can stop the bubbling using:

event.stopPropagation();

Example:

function App() {
  function handleParentClick() {
    console.log("Parent clicked");
  }
function handleChildClick(e) {
    e.stopPropagation();
    console.log("Child clicked");
  }
  return (
    <div onClick={handleParentClick}>
      <button onClick={handleChildClick}>Click Me</button>
    </div>
  );
}

🖱️ Now, clicking the button only logs:

Child clicked

⚠️ 6️⃣ What can cause event propagation issues?

1. Nested event listeners (like parent & child both have onClick).
2. Not using stopPropagation() when you should.
3. Accidentally stopping propagation when you shouldn’t (breaking other features).
4. Event delegation — where you rely on bubbling to handle many child elements from one parent listener.

🎯 7️⃣ The Effect of Event Propagation

✅ Pros:

• Enables event delegation → attach one listener to a parent instead of many children.
• Efficient — React attaches events at the root, not on every single element.

❌ Cons:

• It can cause unexpected multiple triggers if you forget how bubbling works.
• Need to manually control flow with stopPropagation() or preventDefault().

🧭 8️⃣ Summary Table

Maybe you are asking now

🔁 When to use stopPropagation()

Use it when you don’t want parent elements to react to an event that happened inside their child.

✅ Example 1: A modal with a background

You want to close the modal when you click the background,
but not when you click inside the modal content.

function Modal({ onClose }) {
  return (
    <div className="backdrop" onClick={onClose}>
      <div
        className="modal-content"
        onClick={(e) => e.stopPropagation()}
      >
        <h2>Modal</h2>
        <p>Clicking here shouldn't close the modal!</p>
      </div>
    </div>
  );
}

🧠 Here’s what happens:

• Click on backdrop → triggers onClose → closes modal.
• Click inside the modal → stopPropagation() stops the event → doesn’t bubble to backdrop.

✅ That’s the perfect use case.

✅ Example 2: Nested interactive elements

You have a parent with a click handler and a button inside it that should do something different.

function Card() {
  function handleCardClick() {
    console.log("Card clicked");
  }

function handleButtonClick(e) {
    e.stopPropagation();
    console.log("Button clicked");
  }
  return (
    <div onClick={handleCardClick}>
      <button onClick={handleButtonClick}>Click</button>
    </div>
  );
}

🖱️ Clicking the button now only prints:

Button clicked

without also triggering "Card clicked" — because you stopped the event from bubbling.

🚫 4️⃣ When you should not use stopPropagation()

Avoid it when:

1. You’re handling global behaviours (like closing dropdowns when clicking anywhere else). You might accidentally block those global listeners.
2. You don’t need to — React’s event system is already optimised.
3. It hides bugs (you’re “silencing” something instead of understanding why it bubbles).

In short:

❌ Don’t use stopPropagation() to fix a logic bug.
✅ Only use it when you intentionally need to isolate an event.

💡 5️⃣ Important: Event target vs where it’s attached

Let’s say:

<div onClick={handleParentClick}>
  <button onClick={handleButtonClick}>Click</button>
</div>

• Clicking the button → triggers both handlers (button, then div — bubbling phase).
• Clicking the div (outside button) → triggers only handleParentClick.

So, the event target is where you actually clicked,
But propagation allows parent listeners to fire afterwards.

Recall

This is what happens when you click a button, even when travelling from top to bottom

Bubbles up

💧 Life Example: for a better understanding

Imagine you throw a small stone into a calm lake 🪨🌊.

What happens?

1. The stone hits one small spot first — that’s the event starting point (like clicking a button).
2. Then, ripples start spreading outward — small circle → bigger circle → even bigger circle.
3. Each ripple touches a wider area — just like the event moves from the target element up to its parent, then grandparent, and so on.

🔍🧠 addEventListener() under the hood

💡 What it is:

addEventListener() is a built-in DOM method in plain JavaScript used to attach an event handler (function) to an element.

So when something happens — like a click, scroll, input, etc. — the function you attached will run.

element.addEventListener(eventType, handler, options);

🧩 Example:

const btn = document.querySelector("button");
btn.addEventListener("click", function (event) {
  console.log("Button clicked!");
});

✅ When you click the button → "Button clicked!" logs in the console.

🧠 Optional third parameter (options)

You can control how and when the listener fires:

element.addEventListener("click", handler, {
  capture: false, // default = bubbling phase
  once: true,     // handler runs once only
  passive: true   // improves performance for scroll/touch
});

OR you can pass true instead of an object:

element.addEventListener("click", handler, true); // capture phase

🔁 2. stopPropagation()

💡 What it is:

A method available on the event object (event.stopPropagation()).

It tells the browser:

“Stop this event from moving further up (or down) the DOM tree.”

🧱 Syntax:

event.stopPropagation();

⚙️ Example:

<div class="parent">
  <button class="child">Click me</button>
</div>
<script>
  const parent = document.querySelector(".parent");
  const child = document.querySelector(".child");
  parent.addEventListener("click", () => {
    console.log("Parent clicked");
  });
  child.addEventListener("click", (event) => {
    event.stopPropagation(); // stop the bubbling here!
    console.log("Child clicked");
  });
</script>

🧩 Output when clicking the button:

Child clicked

“Parent clicked” won’t run because the event stopped bubbling upward.

🧩 . Summary

In this article, we explored how React brings JavaScript’s fundamentals to life inside your UI:

• map() helps React efficiently render dynamic lists by transforming data into JSX.
• Props connect components, allowing information and behaviour to flow in one direction — from parent to child.
• Event handling & propagation show how React listens, manages, and optimises user interactions using its synthetic event system.

If you feel like you missed any concept, don’t hesitate to reach out — your feedback means a lot to me! ❤️. You can also connect with me on 🌹

Twitter | LinkedIn | GitHub | Facebook
 — Noran 🌹