DEV Community: Naser Rasouli

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

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.

Mastering Git Flow: A Developer’s Guide to Branching Strategies

Naser Rasouli — Tue, 29 Apr 2025 08:15:56 +0000

What is Git Flow?
Git Flow is a popular branching strategy that helps manage the clean and organized development of applications. It was introduced by Vincent Driessen in 2010 to provide developers with a structured workflow using Git. Git Flow focuses on isolating different types of work (features, releases, hotfixes) to avoid dangerous conflicts and miscodes in applications.

Git Flow defines important branches, each with a specific purpose:

Main (Master)
The main (or master) branch always contains the production-ready version
of the application.
It must remain stable at all times. Only fully tested and approved code
is merged into main, typically from a release or hotfix branch.
Release
The release branch is used for final testing and debugging before
merging into main.
It is created from the develop branch when the development of a new
version is complete.
Only bug fixes or final adjustments are made here. Once testing is
complete, this branch is merged into both main and develop.
Develop
The develop branch acts as the integration branch for features under
active development.
All new feature branches are created from develop, and once completed,
they are merged back into it.
It always contains the latest development changes and serves as a base
for creating release branches.
Features
A feature branch is used to develop a single feature, such as
authentication or payment integration.
Each feature should be isolated in its own branch to keep development
focused and avoid conflicts.
Once the feature is complete and tested, the branch is merged into
develop and then deleted.
Hotfix
A hotfix branch is created when a critical issue needs to be fixed in
production.
It is branched off directly from the main, and after the fix, it is
merged into both main and develop to ensure consistency.
This allows urgent patches to be deployed without waiting for the next
release cycle.

Why Git Flow?
Using Git Flow brings structure and clarity to the development process, helping teams manage features, fixes, and releases more efficiently—reducing errors, improving collaboration, and ensuring a smoother path from development to production.