Role-based UI means showing or enabling different parts of the interface according to what the current user is allowed to do. For example: ```text Reader → read articles Author → create and edit own articles Editor → review author content Admin → manage broader application settings ``` ### Simple Role Check ```jsx function AdminPanel() { const { user } = useAuth(); if (user?.role !== "admin") { return ; } return ; } ``` For a single application with a few simple roles, this can be enough. ### Showing Actions by Role ```jsx function ArticleActions({ article }) { const { user } = useAuth(); return (

{user?.role === "editor" && ( )} {user?.role === "admin" && ( )}

); } ``` ### The Problem with Role Checks Everywhere As an application grows, code like this can become scattered: ```jsx user.role === "admin" ``` ```jsx user.role === "editor" || user.role === "admin" ``` ```jsx user.role !== "reader" ``` This makes permission rules difficult to maintain. ### Prefer Permission-Based Checks for Complex Applications Instead of asking only: ```text Is this user an editor? ``` ask: ```text Can this user approve this article? ``` For example: ```javascript function can(user, permission) { return user.permissions?.includes(permission); } ``` Then: ```jsx {can(user, "article.approve") && ( )} ``` This makes the component care about the capability it needs instead of knowing every organizational role. ### Role-to-Permission Model Conceptually: ```text Reader └── article.read Author ├── article.read ├── article.create └── article.edit-own Editor ├── article.read ├── article.edit └── article.approve Admin ├── article.* └── user.manage ``` The backend may calculate the user's effective permissions and send the appropriate safe permission information to the frontend. ### Reusable Permission Component ```jsx function Can({ permission, children, fallback = null }) { const { user } = useAuth(); const allowed = user?.permissions?.includes(permission); return allowed ? children : fallback; } ``` Usage: ```jsx ``` This can make repeated permission-based UI clearer. ### A Hook Can Also Work ```jsx function usePermission(permission) { const { user } = useAuth(); return Boolean( user?.permissions?.includes(permission) ); } ``` Then: ```jsx const canDelete = usePermission("article.delete"); ``` ### Permission Can Depend on the Resource Real authorization is sometimes more complex than one static role. For example: ```text Author can edit article only if article.authorId === user.id ``` A frontend helper might [express](/courses/expressjs) that for UI purposes: ```javascript function canEditArticle(user, article) { if (user.role === "admin") { return true; } return ( user.role === "author" && article.authorId === user.id ); } ``` But the backend must repeat the authoritative ownership check when the update request arrives. ### Disabled vs Hidden Actions Sometimes hide an unavailable action: ```jsx {canDelete && } ``` Sometimes showing it disabled with an explanation is better: ```jsx ``` The choice depends on whether knowing the feature exists helps the user understand the product. ### Frontend Permissions Are Not Security Even if the UI says: ```text canDelete = false ``` an attacker can modify browser code or call the API directly. Therefore: ```text Frontend permission check → presentation and UX Backend permission check → actual authorization ``` ### Related Questions to Learn More ```text Conditional Rendering → How Do You Implement Role-Based Conditional Rendering in React? Context API → When Should You Use Context Instead of Props or a State Management Library? React Security → What Are the Most Important React Security Best Practices? React API Integration → How Do You Make Authenticated API Requests in React? ``` ### Interview-Ready Answer Role-based UI uses the authenticated user's role or permissions to determine which controls and pages should be visible or enabled. Simple applications can check roles directly, while larger systems are usually easier to maintain with capability-based permissions such as `article.approve` or `user.manage`. Resource ownership may also affect permissions. All frontend checks are for UX only; the backend must enforce the same authorization rules securely.