DEV Community: Alaa Samy

[Boost]

Alaa Samy — Wed, 09 Sep 2026 13:38:43 +0000

Alaa Samy

Sep 4

Understanding the DOM, Event Propagation, and Event Delegation in JavaScript 🚀

#javascript #webdev #frontend #interview

5 min read

Understanding the DOM, Event Propagation, and Event Delegation in JavaScript 🚀

Alaa Samy — Fri, 04 Sep 2026 12:48:23 +0000

If you've interviewed for a Frontend Developer role, chances are you've been asked at least one of these questions:

What is the DOM?
What is Event Propagation?
What's the difference between Event Bubbling and Capturing?
What is Event Delegation?
What's the difference between event.target and event.currentTarget?

These concepts are closely related, yet they're often explained separately. Once you understand how they connect, JavaScript's event system becomes much easier to reason about.

In this article, we'll walk through these concepts step by step, using practical examples to understand not only what they are, but also why they exist.

🌳 What is the DOM?

Before JavaScript can interact with a webpage, the browser needs a way to represent the HTML document.

That's where the Document Object Model (DOM) comes in.

When the browser loads an HTML page, it parses the HTML and builds an in-memory tree structure called the DOM.

Every HTML element becomes a Node, allowing JavaScript to read, modify, create, or remove elements dynamically.

For example:

<html>
  <body>
    <h1>Hello</h1>
    <p>Welcome!</p>
  </body>
</html>

becomes something similar to:

Document
│
└── HTML
    ├── HEAD
    └── BODY
        ├── H1
        └── P

This is why methods like:

document.getElementById()
document.querySelector()
document.createElement()

work—they're interacting with the DOM, not the original HTML file.

Because of the DOM, JavaScript can:

Change content
Update styles
Create new elements
Remove existing elements
Listen for user interactions

Example:

document.querySelector("h1").textContent = "Hello JavaScript!";

Without the DOM, JavaScript wouldn't be able to manipulate the page after it has loaded.

⚡ What is Event Propagation?

One common misconception is that clicking an element only affects that element.

That's not actually how browsers work.

Whenever an event occurs (such as clicking a button), the browser makes that event travel through the DOM tree before JavaScript finishes processing it.

This journey is called Event Propagation.

Every event goes through three phases.

1️⃣ Capturing Phase

The event starts at the top of the DOM hierarchy and travels downward toward the clicked element.

Window
 ↓
Document
 ↓
HTML
 ↓
BODY
 ↓
Grandparent
 ↓
Parent
 ↓
Child

Although developers don't use this phase very often, the browser always performs it.

If needed, we can listen during this phase by passing:

{ capture: true }

to addEventListener().

Example:

parent.addEventListener(
  "click",
  () => {
    console.log("Capturing");
  },
  { capture: true }
);

2️⃣ Target Phase

The event reaches the element that actually triggered it.

For example:

<div id="child">Child</div>

If we click on Child, then Child becomes the event target.

3️⃣ Bubbling Phase

After the target phase finishes, the event starts moving back up through the DOM.

Child
 ↑
Parent
 ↑
Grandparent
 ↑
BODY
 ↑
HTML
 ↑
Document
 ↑
Window

This is known as Event Bubbling, and it's the default behavior in JavaScript.

Most applications rely on bubbling every single day—even if we don't realize it.

Let's See It in Action

HTML:

<div id="grandparent">
  Grandparent
  <div id="parent">
    Parent
    <div id="child">
      Child
    </div>
  </div>
</div>

JavaScript:

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

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

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

Clicking the Child prints:

Child clicked
Parent clicked
Grandparent clicked

Why?

Because after the click reaches the target, the event bubbles upward through every parent element.

`event.target` vs `event.currentTarget`

This is another interview favorite.

Suppose we attach the listener to the parent.

parent.addEventListener("click", function (event) {
  console.log(event.target);
  console.log(event.currentTarget);
});

If we click on Child:

event.target

returns

<div id="child">

because that's where the event started.

While

event.currentTarget

returns

<div id="parent">

because that's the element whose event listener is currently executing.

`event.target`	`event.currentTarget`
Element that triggered the event	Element that owns the current listener

Understanding this difference makes debugging event-related issues much easier.

Stopping Event Propagation

Sometimes we don't want an event to continue propagating through the DOM.

JavaScript provides two methods for this:

event.stopPropagation() – Prevents the event from bubbling (or capturing) to ancestor elements, but other event listeners attached to the same element will still execute.
event.stopImmediatePropagation() – Prevents the event from propagating and stops any remaining event listeners on the current element from executing.

Using `stopPropagation()`

child.addEventListener("click", function (event) {
  event.stopPropagation();

  console.log("Child clicked");
});

Now clicking the child won't trigger the parent's or grandparent's click handlers.

Using `stopImmediatePropagation()`

Suppose we have multiple listeners attached to the same element:

child.addEventListener("click", function (event) {
  event.stopImmediatePropagation();

  console.log("First listener");
});

child.addEventListener("click", function () {
  console.log("Second listener");
});

Clicking the child prints:

First listener

The second listener never runs because stopImmediatePropagation() stops both the event's propagation and any remaining listeners on the current element.

Method	What it does
`stopPropagation()`	Stops the event from reaching ancestor elements, but other listeners on the same element still run.
`stopImmediatePropagation()`	Stops the event from reaching ancestor elements and prevents any remaining listeners on the same element from executing.

🎯 What is Event Delegation?

Imagine building a Todo application.

Every time the user adds a task, a new <li> is created.

A common approach is:

items.forEach(item => {
    item.addEventListener("click", ...);
});

This means creating one event listener for every item.

That works...

Until your application has hundreds—or even thousands—of elements.

A much better solution is to attach one listener to the parent.

const parent = document.querySelector("ul");

parent.addEventListener("click", function (event) {
    const item = event.target.closest("li");

    if (!item) return;

    console.log("Clicked:", item.textContent);
});

Now we only have one event listener, regardless of how many list items exist.

Why does this work?

Because of Event Bubbling.

The click starts on the <li>.

Then it bubbles to the <ul>.

The parent receives the event and checks:

event.target

to determine which child triggered it.

This technique is called Event Delegation.

Why use `closest()` instead of `tagName`?

Consider this HTML:

<li>
    <span>🗑 Delete</span>
</li>

If the user clicks on the <span>:

event.target.tagName

returns:

SPAN

not

LI

So checking:

event.target.tagName === "LI"

would fail.

Using:

event.target.closest("li")

searches upward until it finds the nearest <li>, making the solution much more reliable.

Why is Event Delegation useful?

Instead of writing:

li.addEventListener(...)
li.addEventListener(...)
li.addEventListener(...)

we simply write:

ul.addEventListener(...)

Benefits include:

Better performance
Lower memory usage
Cleaner code
Easier maintenance
Works automatically for dynamically added elements

For example:

const li = document.createElement("li");

li.textContent = "Item 4";

parent.appendChild(li);

Even though Item 4 didn't exist when the event listener was registered, clicking it still works because the parent is listening for all click events.

Quick Summary

Concept	Description
DOM	A tree representation of the HTML document that JavaScript can manipulate
Event Propagation	The journey an event takes through the DOM
Capturing	Event travels from the Window down to the target
Target	The element that originally triggered the event
Bubbling	Event travels back up through the DOM
Event Delegation	Attaching a single event listener to a parent instead of multiple child elements
`event.target`	The element that triggered the event
`event.currentTarget`	The element whose listener is currently executing

Final Thoughts

The biggest realization for me was that these aren't separate JavaScript topics—they're all different pieces of the same mechanism.

The browser builds the DOM, events travel through that DOM using Event Propagation, and Event Delegation takes advantage of Event Bubbling to reduce the number of event listeners we need.

Once you connect these ideas together, JavaScript's event system becomes much easier to understand, and many frontend interview questions suddenly have straightforward answers.

If you're preparing for frontend interviews, mastering these concepts will give you a much deeper understanding of how browsers handle user interactions—not just how to write event handlers.

Happy coding! 🚀

I built a tiny permission-checking library because our backend's permission strings never matched what the UI expected

Alaa Samy — Sat, 11 Jul 2026 11:28:22 +0000

A few weeks ago I was working on an internal admin dashboard (Next.js, Redux, the usual stack) and kept running into the same annoying pattern: the backend didn't hand out permission strings like orders.read. It handed out stuff like Orders.GetAll_GET and Orders.Create_POST — literally named after the endpoint. Every module had its own slightly different set of these too.

So every "can the user do X" check in the UI ended up looking like this:

const canRead = userPermissions.includes("Orders.GetAll_GET");

Copy that forty times across a dashboard with modules for orders, deals, users, roles, promo codes... and you've got forty places where a backend rename silently breaks a permission check, and nobody notices until QA does.

I looked around for something to fix this and everything I found was either React/Next.js-only or big enough that I'd have spent longer reading the docs than fixing the actual problem. I wanted something small enough to read in one sitting.

So I wrote permission-access. It's tiny, has zero runtime dependencies, and the core doesn't know or care that React exists.

The actual idea

The one thing I wanted to solve for real: let the UI ask a semantic question ("can they read Orders?") without hardcoding whatever ugly endpoint name the backend picked for that module.

import { createAccessChecker, createActionMap } from "permission-access";

const actionMap = createActionMap({
  read: ["GetAll_GET", "GetList_GET"],
  create: ["Create_POST"],
});

const checker = createAccessChecker(
  { permissions: ["Orders.GetAll_GET"] },
  { actionMap },
);

checker.can("Orders", "read"); // true

The actionMap is completely optional though. If you don't pass one, canRead("Orders") just checks the literal string "Orders.read" — no assumptions baked in about your backend's naming. I went back and forth on this because my first draft did ship a default REST-shaped map, and someone pointed out (rightly) that baking in an opinionated default is exactly the kind of thing that silently breaks for anyone whose backend isn't shaped like mine. So now it's opt-in, via a preset called REST_ACTION_MAP if you want it.

Using it without React

const checker = createAccessChecker({
  permissions: ["Orders.read", "Orders.create"],
  isAdmin: false,
});

checker.canRead("Orders");   // true
checker.canCreate("Orders"); // true
checker.canUpdate("Orders"); // false

Using it with React

import { PermissionsProvider, usePermissions, Can } from "permission-access/react";

function App({ user }) {
  return (
    <PermissionsProvider permissions={user.permissions} isAdmin={user.isAdmin}>
      <OrdersPage />
    </PermissionsProvider>
  );
}

function OrdersPage() {
  const { canCreate } = usePermissions();

  return (
    <div>
      <Can module="Orders" action="read" fallback={<p>No access</p>}>
        <OrdersTable />
      </Can>
      {canCreate("Orders") && <CreateOrderButton />}
    </div>
  );
}

That's basically the whole API surface: createAccessChecker, has, can, a handful of canRead/canCreate/canUpdate convenience wrappers, and <PermissionsProvider> / <Can> on the React side.

What it isn't

I want to be upfront that this is a small library. No wildcard permissions, no feature flags, no explainable "why was this denied" output — just boolean checks. It's v0.1.x, I wrote the test suite myself, and it hasn't been battle-tested outside my own project yet.

If you just want a small, framework-agnostic permission checker that doesn't assume anything about your backend's naming, it's on npm:

npm install permission-access

Repo's here if you want to poke at the source or file an issue: https://github.com/alaasamy347/permission-access

Happy to hear what breaks for you if you try it.

SSR, CSR, SSG, ISR — I Was Confused Too. Here's What Actually Matters.

Alaa Samy — Fri, 12 Jun 2026 20:48:19 +0000

I had a senior dev ask me "what rendering strategy would you use here?" and I said "...SSR?" with zero confidence. I'd heard the acronyms everywhere but never actually understood the tradeoffs.

This is the explanation I wish someone had given me back then — concrete, with real examples, no hand-waving.

The one question that unifies everything

Every rendering strategy is answering the same question: when and where does your HTML get built?

On your server, fresh for every request? → SSR
In the user's browser after downloading JavaScript? → CSR
Once at build time, before any user ever visits? → SSG
Built at deploy time but refreshed in the background? → ISR

That's it. Every performance, SEO, and cost tradeoff follows from this one decision.

Server-Side Rendering (SSR)

Your server builds the HTML fresh on every single request.

User clicks link
→ Request hits your server
→ Server queries the database
→ HTML is built with fresh data
→ Browser gets a complete page
→ User sees content instantly

This is the OG approach. PHP, Ruby on Rails, Django — all of these work this way by default.

// Next.js SSR
export async function getServerSideProps({ params }) {
  // This runs on the SERVER for every request
  const product = await db.products.findOne(params.id);
  const inventory = await db.inventory.getCurrent(params.id);

  return { props: { product, inventory } };
}

export default function ProductPage({ product, inventory }) {
  return (
    <div>
      <h1>{product.name}</h1>
      <p style={{ color: inventory.count === 0 ? 'red' : 'green' }}>
        {inventory.count === 0 ? 'Out of stock' : `${inventory.count} remaining`}
      </p>
    </div>
  );
}

Every page load hits your database. Inventory is always accurate. User always gets the real-time truth.

When SSR is the right call:

Search results (every query is different, can't cache)
User-specific pages ("your orders", account settings)
Real-time data (live auction prices, active game scores)
Anything where stale data causes real problems

The honest tradeoff: If 20,000 people hit the same page at the same time, your server handles 20,000 individual database queries. That's expensive infrastructure to get right, and you feel it in your cloud bill.

Client-Side Rendering (CSR)

Your server serves an almost empty HTML file. The browser downloads JavaScript, runs it, calls APIs, and builds the page itself.

User clicks link
→ Server sends: <div id="app"></div> + bundle.js
→ Browser downloads ~300KB of JavaScript
→ JavaScript parses and executes
→ API calls go out to fetch data
→ React renders the DOM
→ User finally sees something (2-4 seconds later)

This is the default behavior of Create React App. No framework magic, just a browser doing all the work.

// Pure CSR — everything happens in the browser
export default function Dashboard() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('/api/dashboard-stats')
      .then(r => r.json())
      .then(data => {
        setData(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <DashboardSkeleton />;
  return <DashboardGrid data={data} />;
}
// No getServerSideProps. No getStaticProps. Just browser logic.

Server barely breaks a sweat — it just delivers a static file. The user's device does all the rendering work.

When CSR makes sense:

Behind a login (SEO doesn't matter if only authenticated users see it)
Highly interactive tools — Figma, Notion, Gmail-style apps
Real-time collaborative features
Admin dashboards and internal tooling

The honest tradeoff: Google crawls your page and sees <div id="app"></div>. No content. No SEO. That blank white flash while JavaScript loads is also genuinely bad UX on slow connections.

Static Site Generation (SSG)

You build every page once at deploy time. Ship the HTML files to a CDN. Done.

npm run build  (runs once at deploy)
→ Framework reads all your content
→ Generates one complete HTML file per page
→ Files go to CDN edge servers worldwide

User requests any page later
→ CDN returns pre-built HTML in ~50ms
→ No server touched. No database hit.

// Next.js SSG — data fetched at BUILD TIME, not request time
export async function getStaticPaths() {
  const posts = await getAllBlogPosts();
  return {
    paths: posts.map(p => ({ params: { slug: p.slug } })),
    fallback: false
  };
}

export async function getStaticProps({ params }) {
  const post = await getBlogPost(params.slug); // Runs ONCE at build
  return {
    props: { post }
    // No revalidate = frozen until next deploy
  };
}

export default function BlogPost({ post }) {
  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </article>
  );
}

Build once, serve for free, to millions of people. For a blog or documentation site, this is genuinely hard to beat.

When SSG is the right call:

Blogs and personal sites
Documentation sites
Marketing and landing pages
Content that changes weekly at most

The honest tradeoff: Content is frozen in time. Fix a typo? Redeploy. Have 10,000 products with prices that update hourly? You're rebuilding the entire site every hour — a 15-minute deploy cycle just to update a dollar amount. That's where SSG breaks down.

Incremental Static Regeneration (ISR)

This is the one that made me stop and re-read the docs.

ISR gives you SSG's speed (CDN delivery) but lets individual pages regenerate in the background without rebuilding everything. Fast serving AND fresh data.

Normal flow (page is cached):
User request → CDN returns pre-built HTML → ~50ms

When data changes:
Database update
→ Call revalidatePath('/products/123')
→ Server regenerates just that one page (~2 seconds)
→ Next user gets fresh HTML from CDN → still ~50ms

// Next.js ISR — static but refreshable
export async function getStaticProps({ params }) {
  const product = await getProduct(params.id);

  return {
    props: { product },
    revalidate: 3600 // Rebuild every hour OR trigger manually
  };
}

export async function getStaticPaths() {
  // Pre-build your 100 most visited products at deploy time
  const topProducts = await getTopProducts(100);
  return {
    paths: topProducts.map(p => ({ params: { id: p.id } })),
    fallback: 'blocking' // Others: generate on first request, cache after
  };
}

And the on-demand version — this is what makes it genuinely powerful:

// Called from your webhook when inventory changes
async function onInventoryUpdate(productId, newCount) {
  await db.inventory.update(productId, newCount);

  // Tell Next.js to regenerate this specific page only
  await fetch(`${process.env.SITE_URL}/api/revalidate`, {
    method: 'POST',
    body: JSON.stringify({ path: `/products/${productId}` }),
  });
}

// pages/api/revalidate.js
export default async function handler(req, res) {
  await res.revalidate(req.body.path);
  return res.json({ revalidated: true });
}

Inventory changes → webhook fires → that one product page regenerates → next visitor gets accurate stock count, still from CDN in 50ms.

When ISR is the sweet spot:

E-commerce with hundreds or thousands of product pages
News sites where articles get updates but aren't live
Real estate listings, job boards, classified ads
Any content with too many pages for full rebuilds but not so volatile it needs SSR

The honest tradeoff: The first visitor to an uncached page waits like SSR (1-2 seconds). And ISR isn't right if your data changes every few seconds — at that volatility, just use SSR.

Hybrid (What production apps actually do)

Nobody sane uses one strategy for their whole app. The smart move is matching each page to what it actually needs.

Here's a realistic e-commerce breakdown:

Route	Strategy	Why
`/`	SSG	Homepage barely changes
`/products/:id`	ISR	Regenerate when inventory updates
`/search?q=shoes`	SSR	Every query is unique, can't cache
`/blog/:slug`	SSG	Posts don't change after publish
`/account/orders`	SSR	User-specific, must be current
`/cart`	CSR	Client-side state, no server needed

In Next.js, this is just different files using different get*Props functions. One codebase, multiple strategies.

The cost profile ends up roughly:

75% of traffic → CDN (nearly free, instant)
20% → server (search results, auth pages)
5% → browser-rendered (cart, settings, dashboard)

Compared to all-SSR: dramatically cheaper, faster for users, and your server isn't the bottleneck anymore.

How I actually decide

When someone asks which strategy to use for a given page, here's the actual thought process:

Does SEO matter for this page?
No → CSR. Done.

Is the content personalized per user?
Yes → SSR. You can't cache personal data.

How often does the data actually change?
Every second → SSR
Every hour/day → ISR
Every week or less → SSG

How many pages are there?
Under 500 → SSG is easy, builds are fast
Over 500 → ISR, or your builds become a scheduling problem

For most content sites this shakes out to: SSG for marketing and docs, ISR for product and content pages, SSR for search and user-specific pages, CSR for authenticated dashboards.

Closing thought

The thing that finally clicked for me was stopping thinking about this as a framework choice and starting to think about it as a question about data.

When does your data change? Who sees it? How bad is it if a user sees something 10 minutes stale?

Answer those honestly and the right strategy usually picks itself. Next.js, Remix, Astro — they've all made hybrid rendering easy. You're not locked into one approach for your whole codebase.

SSR for things that must be live. SSG for things that never change. ISR for everything in between. CSR for pages behind a login where interactivity matters more than SEO.

Once that mental model is in place, the acronyms stop being confusing jargon and start being genuinely useful tools.

JavaScript Under the Hood: Understanding the Core Mechanics ✨

Alaa Samy — Sun, 09 Mar 2025 20:23:25 +0000

JavaScript is an incredible language that powers the web, yet many of us interact with it daily without understanding what’s happening behind the scenes. Let’s dive into the mechanics of how JavaScript works under the hood and uncover the magic that makes it so dynamic.

The Foundation: Single-Threaded Execution

At its core, JavaScript is a single-threaded, synchronous language, meaning it processes one task at a time, line by line, in a single thread.

Despite being single-threaded, JavaScript has asynchronous capabilities that make it appear multi-threaded.
This is possible through Web APIs provided by browsers (or Node.js in server environments), which allow operations to happen outside the main thread.

JavaScript's Runtime Anatomy:

Every JavaScript runtime consists of three key components that work together:

1- Call Stack:

A data structure that tracks the functions being executed. It follows the LIFO (Last In, First Out) principle—functions added last are removed first.
At the bottom of the stack is the Global Execution Context, the environment for global code, and as the functions are invoked, their execution contexts are stacked on top.

2- Memory Heap:

Stores objects, arrays, and other complex data structures in memory during program execution.
JavaScript uses automatic garbage collection to free memory when objects are no longer referenced.

3- Execution Context:

An execution context is a special environment created to handle the transformation and execution of JavaScript code. It contains the currently running code and everything that aids in its execution.
JavaScript has a Global Execution Context for the main script and Function Execution Contexts for each invoked function.

- Phases of Execution Context:

1- Memory Creation Phase:

Create the global object (window in browsers, global in Node.js).
Bind the this keyword to the global object.
Create the variable environment and process variable declarations:
- For var declarations: allocate memory and initialize with undefined (hoisting)
- For let and const declarations: allocate memory but leave in temporal dead zone (uninitialized)

2- Execution Phase:

Execute the code line by line.
Assign actual values to variables.
Create new execution contexts for function calls.

Asynchronous JavaScript: Event Loop & Queues

JavaScript's asynchronicity is managed through:

Task Queue (Macrotask Queue)

A FIFO (First In, First Out) queue that holds callbacks from asynchronous operations ready to be executed.

Microtask Queue

A higher-priority queue for promises and other microtasks that need to be processed before the next task.

Event Loop

The event loop is what makes asynchronous programming possible in JavaScript:
It continuously checks if the call stack is empty.
If the stack is empty, it looks at the microtask queue first.
After microtasks are processed, it checks the task queue.
It takes the first callback from the queue and pushes it onto the call stack.

Conclusion

Understanding JavaScript's inner workings helps you write more efficient code and debug complex issues. From its single-threaded nature to the event loop, and execution contexts, these fundamental concepts form the backbone of JavaScript's behavior.

By mastering these concepts, you'll gain deeper insights into how your JavaScript code is actually executed and be better equipped to write optimal, high-performance applications.

Happy Coding 😊

Clean Code in JavaScript: A Comprehensive Guide 🚀

Alaa Samy — Sat, 22 Feb 2025 20:03:29 +0000

Writing clean code is an essential skill for any developer. Clean code isn't just about making your code work—it's about making it work elegantly, efficiently, and in a way that other developers (including your future self) can easily understand and maintain. In this comprehensive guide, we'll explore the principles and best practices of writing clean JavaScript code.

What is Clean Code?

Clean code is code that is:

Readable: Easy to understand at a glance
Maintainable: Simple to modify and debug
Reusable: Can be repurposed for different scenarios
Testable: Easy to write unit tests for
Scalable: Can grow without becoming complex

1. Variables: The Building Blocks of Clean Code

- Use Meaningful Variable Names

Your variable names should clearly indicate their purpose and context.

// Bad
const d = new Date();
let u = getUser();
const arr = ['Apple', 'Banana', 'Orange'];

// Good
const currentDate = new Date();
let currentUser = getUser();
const fruitList = ['Apple', 'Banana', 'Orange'];

- Use Constants for Fixed Values

When a value won't change, use const instead of let or var.

// Bad
var API_ENDPOINT = 'https://api.example.com';
var MAX_ITEMS = 100;

// Good
const API_ENDPOINT = 'https://api.example.com';
const MAX_ITEMS = 100;

- Maintain Consistent Naming Convention

Use consistent naming patterns throughout your codebase.

// Bad - Inconsistent naming
getUserInfo()
getClientData()
getCustomerRecord()

// Good - Consistent naming
getUser()
updateUser()
deleteUser()

- Use Searchable Names

Make your variables and constants easily searchable.

// Bad
setTimeout(doSomething, 86400000);

// Good
const MILLISECONDS_IN_A_DAY = 86400000;
setTimeout(doSomething, MILLISECONDS_IN_A_DAY);

2. Objects: Organizing Data Cleanly

- Use Getters and Setters

Encapsulate object properties using getters and setters.

// Bad
class User {
  constructor(name) {
    this.name = name;
  }
}

// Good
class User {
  #name;  // Private field

  constructor(name) {
    this.#name = name;
  }

  getName() {
    return this.#name;
  }

  setName(name) {
    this.#name = name;
  }
}

- Implement Private Members

Use private fields and methods to protect object data.

class BankAccount {
  #balance = 0;  // Private field

  deposit(amount) {
    if (this.#validateAmount(amount)) {
      this.#balance += amount;
    }
  }

  #validateAmount(amount) {  // Private method
    return amount > 0;
  }
}

3. Functions: The Heart of Clean Code

- Keep Functions Small and Focused

Each function should do exactly one thing.

// Bad
function processUserData(user) {
  validateUser(user);
  updateUserInDatabase(user);
  sendWelcomeEmail(user);
  updateUIWithUserData(user);
}

// Good
function processUserData(user) {
  if (validateUser(user)) {
    saveUserData(user);
  }
}

function saveUserData(user) {
  updateUserInDatabase(user)
    .then(sendWelcomeEmail)
    .then(updateUIWithUserData);
}

- Limit Function Parameters

Use objects to pass multiple parameters.

// Bad
function createUser(firstName, lastName, email, age, location) {
  // ...
}

// Good
function createUser(userConfig) {
  const { firstName, lastName, email, age, location } = userConfig;
  // ...
}

- Use Descriptive Function Names

Function names should clearly describe what they do.

// Bad
function proc(data) { /* ... */ }

// Good
function processUserPayment(paymentData) { /* ... */ }

4. Comments: When and How to Use Them

- Write Self-Documenting Code

Your code should be clear enough that it doesn't need extensive comments.

// Bad
// Check if user is adult
if (user.age >= 18) { /* ... */ }

// Good
const isAdult = user.age >= 18;
if (isAdult) { /* ... */ }

- Use Comments for Complex Logic

Comments should explain "why" not "what".

// Bad
// Iterate through users
users.forEach(user => { /* ... */ });

// Good
// Filter inactive users before sending notifications to avoid
// overwhelming users who haven't logged in for 30+ days
const activeUsers = users.filter(user => user.lastLogin > thirtyDaysAgo);

5. Testing: Ensuring Code Quality

- Write Tests First (TDD)

Consider writing tests before implementing features.

// Example test
describe('User Authentication', () => {
  it('should successfully login with valid credentials', () => {
    const user = new User('test@example.com', 'password123');
    expect(user.login()).toBeTruthy();
  });
});

- Test Edge Cases

Always test boundary conditions and error cases.

describe('Array Utility', () => {
  it('should handle empty arrays', () => {
    expect(processArray([])).toEqual([]);
  });

  it('should handle null input', () => {
    expect(() => processArray(null)).toThrow('Invalid input');
  });
});

6. Modern JavaScript Features for Cleaner Code

- Use Optional Chaining

// Bad
const streetName = user && user.address && user.address.street;

// Good
const streetName = user?.address?.street;

- Utilize Destructuring

// Bad
const firstName = user.firstName;
const lastName = user.lastName;

// Good
const { firstName, lastName } = user;

- Implement Default Parameters

// Bad
function greet(name) {
  name = name || 'Guest';
  return `Hello, ${name}!`;
}

// Good
function greet(name = 'Guest') {
  return `Hello, ${name}!`;
}

Conclusion

Writing clean code is an ongoing journey of improvement. It's not just about following rules—it's about developing a mindset that values clarity, simplicity, and maintainability. Remember:

Write code for humans first, computers second
Keep your functions small and focused
Use meaningful names for variables and functions
Test thoroughly
Refactor regularly
Stay consistent with your coding style

By following these principles and continuously refining your approach, you'll write code that's not just functional, but truly professional and maintainable.

References

Understanding AI, Machine Learning, and Deep Learning: A Comprehensive Guide 🚀

Alaa Samy — Fri, 14 Feb 2025 22:36:32 +0000

Artificial Intelligence (AI) and its related fields are transforming industries, but understanding the basics can be overwhelming. Let’s break down key concepts to help you navigate this exciting world!

✔Artificial Intelligence: An Overview

The theory and development of computer systems able to perform tasks normally requiring human intelligence, These tasks include:

Visual perception
Speech recognition
Decision-making
Language translation
Problem-solving

✔Types of AI

1. Artificial narrow intelligence

Also known as Weak AI, it is designed to perform a narrow task (e.g., facial recognition or internet searches)
Examples: Siri, Alexa, chess programs

2. Artificial general intelligence

Also known as Strong AI or AGI (Artificial General Intelligence), it is a type of AI that has the capability to perform any intellectual task that a human can do.
Currently theoretical

3. Artificial super intelligence

This refers to AI that surpasses human intelligence in all aspects, including creativity and problem-solving.
Currently theoretical

✔Machine Learning: Foundation and Concepts

Machine Learning (ML) is a subset of AI that focuses on developing systems that can learn from and improve with experience. It enables computers to learn without explicit programming.

Data --> Training the machine --> Building a model --> Predict outcome

✔Common Parts of Machine Learning:

1. Datasets

Collections of data used for training and testing the machine learning models.

2. Algorithms

The mathematical models that make predictions or decisions based on the input data.

3. Model

The main component of a machine learning process and it's trained by using a machine learning algorithm

4. Features

The individual measurable properties or characteristics of the data used by the algorithms.

5. Labels

The outputs or results that the model is trying to predict or classify

6. Training

The process of teaching the model using a dataset so it can learn to make predictions.

7. Testing

Evaluating the model's performance on a separate dataset to ensure it generalizes well to new data.

✔Machine Learning Process

1. Defining the Objective

Clarify the business problem and goals (e.g., predicting sales, classifying images).
Determine success metrics (e.g., accuracy, speed, cost reduction).

2. Data Gathering

Collect relevant datasets from databases, APIs, or sensors.
Ensure data aligns with the problem (e.g., customer demographics for churn prediction).

3. Preparing Data

Clean data: Handle missing values, duplicates, and errors.
Preprocess: Normalize, encode categories, or split into training/testing sets.

4. Data Exploration (EDA)

Analyze patterns, correlations, and distributions using visualizations (e.g., histograms, heatmaps).
Identify outliers or biases that could skew results.

5. Building the Model

Select algorithms based on the problem (e.g., linear regression for predictions, CNN for images).
Train the model: Feed prepared data to learn patterns (e.g., using gradient descent).

6. Model Evaluation

Test performance on unseen data (test set).
Use metrics like accuracy, precision, recall, or F1-score.
Diagnose issues like overfitting (perfect on training data but fails on new data).

7. Predictions

Deploy the trained model to make real-world predictions (e.g., recommending products).
Monitor performance over time and retrain with new data as needed.

✔Types of Machine Learning

Machine learning can be classified into the following types:

1. Supervised Learning:

The model is trained on a labeled dataset, where the correct output is provided for each input.
Example algorithms include Linear Regression and Support Vector Machines.

2. Unsupervised Learning:

The model is trained on an unlabeled dataset and must find patterns or relationships within the data.
Example algorithms include K-Means Clustering and Principal Component Analysis (PCA).

3. Reinforcement Learning

The model learns by interacting with its environment and receiving feedback in the form of rewards or penalties.
Example algorithms include Q-Learning and Deep Q-Networks.

✔Common Machine Learning Problems and Classifications

1. Regression Problems

Supervised learning.
Predicting a continuous value.
Examples include predicting house prices or stock prices.
Algorithm -> Linear Regression

2. Classification Problems

Supervised learning
Categorizing data into discrete classes.
Examples include spam detection and image recognition.
Algorithm -> Logistic Regression

3. Clustering Problems

Unsupervised learning.
Grouping similar data points together.
Examples include customer segmentation and market research.
Algorithm -> K-means Clustering.

✔Deep Learning: Advanced Machine Learning

Deep Learning is a subset of machine learning that uses neural networks with many layers (hence "deep") to learn from data. It is particularly effective for tasks such as image and speech recognition, natural language processing, and playing complex games.
We use it whenever the data is very large and it has a lot of features and a lot of predictor variables.

✔Key Components of Deep Learning:

1. Neural Networks:

Composed of layers of interconnected neurons that process data.

2. Activation Functions:

Functions that determine the output of a neuron based on its input. Examples include ReLU (Rectified Linear Unit) and Sigmoid.

3. Training with Backpropagation:

A process of adjusting the weights of the network to minimize the error in predictions.

4. Convolutional Neural Networks (CNNs):

Specialized neural networks for processing grid-like data, such as images.

5. Recurrent Neural Networks (RNNs):

Specialized neural networks for sequential data, such as time series or text.

Conclusion ✨

The field of AI, particularly machine learning and deep learning, continues to evolve rapidly. Understanding these concepts and their relationships is crucial for anyone interested in artificial intelligence. Each component plays a vital role in developing intelligent systems that can learn from data and make informed decisions.

🛠️ SOLID Principles in JavaScript: Write Better Code with Examples

Alaa Samy — Sat, 08 Feb 2025 00:51:10 +0000

SOLID principles are a set of design guidelines that help you create maintainable, flexible, and scalable code.

Let’s break them down with JavaScript examples:

1. Single Responsibility Principle (SRP)

A class/function should have only one reason to change.

❌ Bad:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  saveToDatabase() {
    // Database logic here
  }

  sendEmail() {
    // Email logic here
  }
}

Problem: The User class handles both data management and email logic.

✅Good:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

class UserRepository {
  saveToDatabase(user) { /* DB logic */ }
}

class EmailService {
  sendEmail(user) { /* Email logic */ }
}

Benefit: Each class has a single responsibility.

2. Open/Closed Principle (OCP)

Entities should be open for extension but closed for modification.

❌ Bad:

class Logger {
  logToConsole(message) {
    console.log(message);
  }

  logToFile(message) {
    // Write to file
  }
}

// To add a new logger (e.g., HTTP), you must modify the Logger class.

✅ Good:

// Use a strategy pattern to extend behavior
class Logger {
  log(message, loggerStrategy) {
    loggerStrategy(message);
  }
}

// Define strategies (extensions)
const consoleStrategy = (msg) => console.log(msg);
const fileStrategy = (msg) => writeToFile(msg);
const httpStrategy = (msg) => fetch('/log', { body: msg }); // New logger added without changing Logger class

// Usage:
const logger = new Logger();
logger.log("Error!", httpStrategy); // No need to modify Logger

Benefit: Extend functionality without altering existing code.

3. Liskov Substitution Principle (LSP)

Subclasses should replace their parent class without breaking functionality.

❌ Bad:

class Rectangle {
  setWidth(w) { this.width = w }
  setHeight(h) { this.height = h }
}

class Square extends Rectangle {
  setSize(size) { // Violates LSP
    this.width = size;
    this.height = size;
  }
}

function resizeShape(shape) {
  shape.setWidth(10);
  shape.setHeight(5); // Breaks for Square
}

✅ Good:

class Shape {
  area() { /* Abstract */ }
}

class Rectangle extends Shape { /* Implement area */ }
class Square extends Shape { /* Implement area */ }

Benefit: Subclasses don’t break parent class behavior.

4. Interface Segregation Principle (ISP)

Clients shouldn’t depend on interfaces they don’t use.

❌ Bad:

class Worker {
  work() { /* ... */ }
  eat() { /* ... */ }
}

// Robot forced to implement eat()
class Robot extends Worker {
  eat() { throw Error("Robots don't eat!"); }
}

✅ Good:

class Workable {
  work() { /* Interface */ }
}

class Eatable {
  eat() { /* Interface */ }
}

class Human implements Workable, Eatable { /* ... */ }
class Robot implements Workable { /* ... */ }

Benefit: Avoid bloated interfaces.

5. Dependency Inversion Principle (DIP)

Depend on abstractions (interfaces), not concretions (specific implementations).

❌ Bad:

class MySQLDatabase {
  save(data) { /* MySQL-specific */ }
}

class UserService {
  constructor() {
    this.db = new MySQLDatabase(); // Tight coupling
  }
}

✅ Good:

class Database {
  save(data) { /* Abstract */ }
}

class MySQLDatabase extends Database { /* ... */ }
class MongoDB extends Database { /* ... */ }

class UserService {
  constructor(database) {
    this.db = database; // Injected dependency
  }
}

Benefit: Decoupled, testable code.

Why SOLID Matters in JavaScript 🚀

Easier Maintenance: Changes affect fewer components.
Better Testability: Isolated logic is easier to test.
Flexible Architecture: Adapt to new requirements without rewrites.
Reusability: Components can be reused across projects.

Understanding Event Propagation in JavaScript 🌐

Alaa Samy — Wed, 29 Jan 2025 16:31:17 +0000

Event propagation describes how events travel through the DOM tree. Mastering it helps you control event behavior and write efficient code. Let’s dive in!

The 3 Phases of Event Propagation:

When an event (e.g., a click) occurs, it goes through three phases:

1. Capturing Phase:

The event travels down from the root (window → document → parent elements) to the target.

2. Target Phase:

The event reaches the element that triggered it (e.g., a clicked button).

3. Bubbling Phase:

The event bubbles up from the target back to the root (default behavior).

Example: Visualizing Propagation Phases:

HTML (nested elements):

<div id="grandparent">
  Grandparent
  <div id="parent">
    Parent
    <div id="child">Child</div>
  </div>
</div>

JavaScript:

const grandparent = document.getElementById('grandparent');
const parent = document.getElementById('parent');
const child = document.getElementById('child');

// Listen during the CAPTURING phase (third argument = true)
grandparent.addEventListener('click', () => {
  console.log('Capturing: Grandparent');
}, true);

parent.addEventListener('click', () => {
  console.log('Capturing: Parent');
}, true);

// Listen during the BUBBLING phase (default)
grandparent.addEventListener('click', () => {
  console.log('Bubbling: Grandparent');
});

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

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

Output when clicking the child div:

Capturing: Grandparent  
Capturing: Parent  
Target: Child  
Bubbling: Parent  
Bubbling: Grandparent

Controlling Propagation

1. Stop Bubbling

Use event.stopPropagation() to halt the event’s upward travel:

child.addEventListener('click', (e) => {
  console.log('Child clicked!');
  e.stopPropagation(); // Stops the event from bubbling further
});

Result: Only Capturing: Grandparent, Capturing: Parent, and Target: Child will log.

2. Stop Immediate Actions

Use event.stopImmediatePropagation() to prevent other listeners on the same element from firing:

child.addEventListener('click', (e) => {
  console.log('First listener');
  e.stopImmediatePropagation();
});

child.addEventListener('click', () => {
  console.log('Second listener (never runs)');
});

Key Takeaways

Bubbling is the default phase (events propagate upward).
Capturing is rarely used but can be enabled with addEventListener(..., true).
Use event delegation to optimize performance for dynamic content.
Control propagation with stopPropagation() and stopImmediatePropagation().

Understanding event propagation unlocks precise control over user interactions! 🚀

Happy Coding 😀😀

Did you find this helpful? Follow me for more web development tips and tutorials!

Elevate Your JavaScript: A Deep Dive into Object-Oriented Programming✨

Alaa Samy — Mon, 26 Aug 2024 20:49:43 +0000

Object-Oriented Programming (OOP) is a powerful paradigm that has revolutionized the way we structure and organize code.

While JavaScript began as a prototype-based language, it has evolved to embrace OOP principles, particularly with the introduction of ES6 and subsequent updates.

This post delves into the core concepts of OOP in JavaScript, exploring how they can be implemented to create more robust, maintainable, and scalable applications.

We'll journey through the four pillars of OOP - Inheritance, Abstraction, Encapsulation and Polymorphism - demonstrating how each principle can be applied in JavaScript. Along the way, we'll examine real-world examples and discuss the pros and cons of each concept.

Whether you're a seasoned developer looking to refine your OOP skills in JavaScript or a newcomer eager to grasp these fundamental concepts, this guide will provide valuable insights into harnessing the power of OOP in your JavaScript projects.

1. Inheritance:

Inheritance allows a class to inherit properties and methods from another class. It promotes code reusability and establishes a relationship between a parent class and a child class.

class Vehicle {
  constructor(make, model) {
    this.make = make;
    this.model = model;
  }

  getInfo() {
    return `${this.make} ${this.model}`;
  }

  start() {
    return "The vehicle is starting...";
  }
}

class Car extends Vehicle {
  constructor(make, model, doors) {
    super(make, model);
    this.doors = doors;
  }

  getCarInfo() {
    return `${this.getInfo()} with ${this.doors} doors`;
  }
}

const myCar = new Car("Toyota", "Corolla", 4);
console.log(myCar.getCarInfo()); // Output: Toyota Corolla with 4 doors
console.log(myCar.start()); // Output: The vehicle is starting...

In this example, Car inherits from Vehicle, gaining access to its properties and methods.

Pros:

Code reusability: Child classes inherit properties and methods from parent classes.
Establishes a clear hierarchy between objects.
Allows for method overriding and extension.

Cons:

Can lead to tight coupling between parent and child classes.
Deep inheritance hierarchies can become complex and hard to maintain.

2. Abstraction

Abstraction involves hiding complex implementation details and showing only the necessary features of an object. In JavaScript, we can achieve abstraction using abstract classes (though not natively supported) and interfaces.

class Shape {
  constructor() {
    if (new.target === Shape) {
      throw new TypeError("Cannot instantiate abstract class");
    }
  }

  calculateArea() {
    throw new Error("Method 'calculateArea()' must be implemented.");
  }
}

class Circle extends Shape {
  constructor(radius) {
    super();
    this.radius = radius;
  }

  calculateArea() {
    return Math.PI * this.radius ** 2;
  }
}

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
    this.height = height;
  }

  calculateArea() {
    return this.width * this.height;
  }
}

// const shape = new Shape(); // Throws TypeError
const circle = new Circle(5);
const rectangle = new Rectangle(4, 6);

console.log(circle.calculateArea()); // Output: 78.53981633974483
console.log(rectangle.calculateArea()); // Output: 24

In this example, Shape acts as an abstract class that can't be instantiated directly. It defines a common interface calculateArea that all subclasses must implement. This abstraction allows us to work with different shapes through a common interface without worrying about their specific implementations.

Pros:

Simplifies complex systems by hiding unnecessary details.
Improves code maintainability and reduces duplication.
Allows focusing on what an object does rather than how it does it.

Cons:

Can lead to over-simplification if not designed carefully.
Might introduce performance overhead in some cases.

3. Encapsulation

Encapsulation is the bundling of data and the methods that operate on that data within a single unit (object). In JavaScript, we can use closures and symbols to create private properties and methods.

class BankAccount {
  #balance = 0;  // Private field

  constructor(owner) {
    this.owner = owner;
  }

  deposit(amount) {
    if (amount > 0) {
      this.#balance += amount;
      return true;
    }
    return false;
  }

  withdraw(amount) {
    if (amount > 0 && this.#balance >= amount) {
      this.#balance -= amount;
      return true;
    }
    return false;
  }

  getBalance() {
    return this.#balance;
  }
}

const account = new BankAccount('John Doe');
account.deposit(1000);
console.log(account.getBalance()); // Output: 1000
console.log(account.#balance); // SyntaxError: Private field '#balance' must be declared in an enclosing class

In this example, #balance is a private field that can't be accessed directly from outside the class.

Pros:

Data protection: Prevents unauthorized access to internal data.
Modularity: Bundles related functionality together.
Easier maintenance: Changes to internal implementation don't affect external code.

Cons:

Can be complex to implement in JavaScript due to lack of true private members.
Might lead to verbose code when creating getters and setters.

4. Polymorphism

Polymorphism allows objects of different classes to be treated as objects of a common superclass. In JavaScript, this can be achieved through method overriding.

class Animal {
  speak() {
    return "The animal makes a sound";
  }
}

class Dog extends Animal {
  speak() {
    return "The dog barks";
  }
}

class Cat extends Animal {
  speak() {
    return "The cat meows";
  }
}

const animals = [new Animal(), new Dog(), new Cat()];

animals.forEach(animal => {
  console.log(animal.speak());
});

// Output:
// The animal makes a sound
// The dog barks
// The cat meows

In this example, each class implements the speak method differently, demonstrating polymorphism.

Pros:

Flexibility: Objects of different types can be treated uniformly.
Extensibility: New classes can be added without changing existing code.
Simplifies code by allowing use of a single interface for different types.

Cons:

Can make code harder to debug if overused.
Might lead to performance overhead in some languages (less so in JavaScript).

As we've explored, Object-Oriented Programming in JavaScript offers a robust toolkit for creating structured, maintainable, and scalable code. The four pillars of OOP - Inheritance, Abstraction, Encapsulation and Polymorphism - each bring unique strengths to the table, allowing developers to model complex systems, protect data integrity, promote code reuse, and create flexible, extensible applications.

While implementing these principles in JavaScript may sometimes require creative approaches due to the language's unique characteristics, the benefits are clear. OOP can lead to more organized codebases, easier collaboration among team members, and increased adaptability to changing requirements.

However, it's important to remember that OOP is not a one-size-fits-all solution. Each project may require a different balance of these principles, and in some cases, other paradigms might be more suitable. The key is to understand these concepts thoroughly and apply them judiciously, always keeping in mind the specific needs of your project and team.

Happy Coding 😄

Mastering Jest in Next.js: A Complete Guide for App Router and TypeScript 🚀

Alaa Samy — Fri, 23 Aug 2024 19:50:59 +0000

Dive into the world of modern web testing with this comprehensive guide on integrating Jest into your Next.js project, and learn how to set up a robust testing environment for your App Router-based application using TypeScript.
We'll walk you through installing essential dependencies, configuring Jest for Next.js, and writing your first test.

Perfect for developers looking to enhance their Next.js applications with reliable, type-safe testing practices. Boost your code quality and confidence with Jest and React Testing Library in your Next.js TypeScript projects.

To start working with Jest in a Next.js project you need to follow these steps:

1. Install dependencies:

npm install --save-dev jest @types/jest @testing-library/react @testing-library/jest-dom jest-environment-jsdom

Let's break down this npm installation command and explain each package:

--save-dev: This flag saves these packages as development dependencies in your package.json. It means these packages are only needed for development and testing, not for production.
jest: This is the core Jest library, a popular JavaScript testing framework developed by Facebook. It provides the test runner and assertion library.
@types/jest: This package provides TypeScript type definitions for Jest. It enables better autocomplete and type-checking when writing tests in TypeScript.
@testing-library/react: This is a set of helpers that allow you to test React components without relying on their implementation details, it encourages better testing practices.
@testing-library/jest-dom: This package extends Jest with custom matchers for asserting on DOM nodes, making it easier to test the state of the DOM in your tests.
jest-environment-jsdom: This package provides a simulated DOM environment for Jest tests. It's necessary when testing React components that interact with the DOM, as Next.js components often do.

2. Create a Jest configuration file (jest.config.js) in your project root:

const nextJest = require('next/jest')

const createJestConfig = nextJest({
  dir: './',
})

const customJestConfig = {
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jest-environment-jsdom',
}

module.exports = createJestConfig(customJestConfig)

This code configures Jest to work with Next.js. Let's break it down line by line:

const nextJest = require('next/jest'): This imports the Next.js Jest configuration function. Next.js provides this to help set up Jest in a way that's compatible with Next.js projects.
const createJestConfig = nextJest({ dir: './', }): This creates a Jest configuration function specific to your Next.js project, and dir: './' option tells Next.js that the root directory of your project is the current directory.
const customJestConfig = { ... }: This object contains custom Jest configuration options.
setupFilesAfterEnv: ['<rootDir>/jest.setup.js']: This specifies files to run after the Jest environment is set up but before tests are run, and it points to jest.setup.js file in your root directory, where you can add global setup code for your tests.
testEnvironment: 'jest-environment-jsdom': This sets the test environment to jsdom, which simulates a DOM environment in Node.js, and it's necessary for testing React components that interact with the DOM.
module.exports = createJestConfig(customJestConfig): This exports the final Jest configuration, it calls createJestConfig with your custom config, which merges your settings with Next.js's default Jest settings.

3. Create a jest.setup.js file in your project root:

import '@testing-library/jest-dom'

4. Update your package.json to include Jest scripts:

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch"
}

These scripts provide two different ways to run your tests:

The test script is for running all tests once, which is ideal for CI/CD or before committing changes.
The test:watch script is for development, allowing you to see test results update in real-time as you code.

5. Create a __tests__ folder in your project root or alongside your components

6. Write your first test (e.g., Home.test.tsx):

import '@testing-library/jest-dom'
import { render, screen } from '@testing-library/react'
import Home from '../app/page'

describe('Home', () => {
    it('renders a heading', () => {
        render(<Home />)
        const heading = screen.getAllByRole('heading', { level: 2 })
        expect(heading).toHaveLength(4);
    })
})

7. Run your tests:

npm test

This setup should get you started on using Jest in a Next.js project.

Incorporating Jest into your Next.js project with TypeScript marks a significant step towards robust, maintainable code. By following this guide, you've laid the groundwork for a comprehensive testing strategy that will serve you well as your application grows.

By prioritizing testing in your development workflow, you're not just catching bugs early—you're also documenting your code's behavior and making it easier for your team to collaborate and refactor with confidence.

Happy testing 😀😀

What is JavaScript?

Alaa Samy — Fri, 15 Mar 2024 12:18:45 +0000

Javascript is a programming language that can help to create dynamic pages and make it more interactive.
Javascript is described as prototype-based, high-level, multiparadigm, single-threaded, dynamic typing, and garbage-collected.

✔JavaScript is prototype-based

It means that JavaScript can create objects without defining its class

function Car (){
  this.color = 'red',
  this.wheels = 4
}

const firstCar = new Car();

✔JavaScript is high-level

JavaScript is a high-level language because it's easy to understand, and it doesn't have to manage resources at all or deal with hardware and operating system.

✔JavaScript is multiparadigm

JavaScript is very dynamic and it supports various types of programming styles such as:

1. Imperative programming paradigm

It's a paradigm that focuses on how the program should perform, through a set of instructions to follow, and the computer does what you want like:

Object-oriented programming
Procedural code

const arr = [1, 2, 3, 4, 5]
const result = []

for (let i=0; i < arr.length; i++){
   result.push(arr[i] * 3)
}

console.log(result)
// [3, 6, 9, 12, 15]

2. Declarative programming paradigm

It's a paradigm that focuses on what the program should accomplish without specifying the instructions on how to solve the problem like:

Logic language
Functional programming
Domain-specific language

const arr= [1, 2, 3, 4, 5]
const result = arr.map(num => num * 3)

console.log(result) 
// [3, 6, 9, 12, 15]

✔JavaScript is single-threaded

It means that javascript can only execute one task, and each task must done and completed before the other task starts

function First() {
  console.log('First function');
}
function Second() {
  console.log('Second function');
}

First();
Second();
// First function
// Second function

✔JavaScript is dynamic typing

JavaScript interpreter assigns a type to a variable at a run time based on the value assigned to that variable

✔JavaScript is garbage-collected

The Garbage collector is an algorithm inside javascript engines, it automatically frees up memory by removing unused objects, which can help to prevent memory leaks.

I hope you find something useful in this article

😊Happy coding!

DEV Community: Alaa Samy

[Boost]

Understanding the DOM, Event Propagation, and Event Delegation in JavaScript 🚀

Understanding the DOM, Event Propagation, and Event Delegation in JavaScript 🚀

🌳 What is the DOM?

⚡ What is Event Propagation?

1️⃣ Capturing Phase

2️⃣ Target Phase

3️⃣ Bubbling Phase

Let's See It in Action

event.target vs event.currentTarget

Stopping Event Propagation

Using stopPropagation()

Using stopImmediatePropagation()

🎯 What is Event Delegation?

Why does this work?

Why use closest() instead of tagName?

Why is Event Delegation useful?

Quick Summary

Final Thoughts

I built a tiny permission-checking library because our backend's permission strings never matched what the UI expected

The actual idea

Using it without React

Using it with React

What it isn't

SSR, CSR, SSG, ISR — I Was Confused Too. Here's What Actually Matters.

The one question that unifies everything

Server-Side Rendering (SSR)

Client-Side Rendering (CSR)

Static Site Generation (SSG)

Incremental Static Regeneration (ISR)

Hybrid (What production apps actually do)

How I actually decide

Closing thought

JavaScript Under the Hood: Understanding the Core Mechanics ✨

The Foundation: Single-Threaded Execution

JavaScript's Runtime Anatomy:

- Phases of Execution Context:

Asynchronous JavaScript: Event Loop & Queues

Conclusion

Clean Code in JavaScript: A Comprehensive Guide 🚀

What is Clean Code?

1. Variables: The Building Blocks of Clean Code

2. Objects: Organizing Data Cleanly

3. Functions: The Heart of Clean Code

4. Comments: When and How to Use Them

5. Testing: Ensuring Code Quality

6. Modern JavaScript Features for Cleaner Code

Conclusion

References

Understanding AI, Machine Learning, and Deep Learning: A Comprehensive Guide 🚀

✔Artificial Intelligence: An Overview

✔Types of AI

✔Machine Learning: Foundation and Concepts

✔Common Parts of Machine Learning:

✔Machine Learning Process

✔Types of Machine Learning

✔Common Machine Learning Problems and Classifications

✔Deep Learning: Advanced Machine Learning

✔Key Components of Deep Learning:

Conclusion ✨

🛠️ SOLID Principles in JavaScript: Write Better Code with Examples

Understanding Event Propagation in JavaScript 🌐

The 3 Phases of Event Propagation:

Example: Visualizing Propagation Phases:

Controlling Propagation

Key Takeaways

Elevate Your JavaScript: A Deep Dive into Object-Oriented Programming✨

Mastering Jest in Next.js: A Complete Guide for App Router and TypeScript 🚀

What is JavaScript?

✔JavaScript is prototype-based

✔JavaScript is high-level

✔JavaScript is multiparadigm

✔JavaScript is single-threaded

✔JavaScript is dynamic typing

✔JavaScript is garbage-collected

`event.target` vs `event.currentTarget`

Using `stopPropagation()`

Using `stopImmediatePropagation()`

Why use `closest()` instead of `tagName`?