{ state.capabilities = new Set(action.payload); state.isAuthenticated = true; }, clearSession: (state) => { state.capabilities = new Set(); state.isAuthenticated = false; }, }, });

export const { setCapabilities, clearSession } = authSlice.actions; export default authSlice.reducer;

### Step 2: Build an O(1) Access Hook
Array-based permission checks degrade linearly as capability lists grow. Converting the Redux array to a `Set` during initialization enables constant-time lookups. The hook exposes three evaluation strategies: exact match, union, and intersection.

```typescript
// useAccessControl.ts
import { useSelector } from 'react-redux';
import type { RootState } from './store';

export function useAccessControl() {
  const capabilities = useSelector((state: RootState) => state.auth.capabilities);

  const has = (required: string): boolean => capabilities.has(required);

  const hasAny = (required: string[]): boolean =>
    required.some((cap) => capabilities.has(cap));

  const hasAll = (required: string[]): boolean =>
    required.every((cap) => capabilities.has(cap));

  return { has, hasAny, hasAll };
}

Step 3: Intercept Before Suspense Resolution

React Router’s element prop accepts React elements, but lazy-loaded components trigger network requests immediately upon route matching. To prevent this, wrap the route in a guard component that evaluates capabilities synchronously. If access is denied, redirect before the lazy import executes.

// RouteGuard.tsx
import { Navigate, Outlet, useLocation } from 'react-router-dom';
import { useAccessControl } from './useAccessControl';
import type { ReactNode } from 'react';

interface RouteGuardProps {
  required: string[];
  strategy?: 'any' | 'all';
  fallbackPath?: string;
  children?: ReactNode;
}

export function RouteGuard({
  required,
  strategy = 'all',
  fallbackPath = '/unauthorized',
  children,
}: RouteGuardProps) {
  const { hasAny, hasAll } = useAccessControl();
  const location = useLocation();

  const isAuthorized =
    strategy === 'any' ? hasAny(required) : hasAll(required);

  if (!isAuthorized) {
    return <Navigate to={fallbackPath} state={{ from: location }} replace />;
  }

  return children ? <>{children}</> : <Outlet />;
}

Step 4: Unify Routing and Navigation Configuration

Maintaining separate arrays for route definitions and navigation menus creates configuration drift. Define a single typed configuration object that drives both the router and the sidebar. This ensures that hidden routes never appear in the UI, and visible routes always have corresponding guards.

// appConfig.ts
import React from 'react';

export interface RouteDefinition {
  path: string;
  label: string;
  required: string[];
  strategy?: 'any' | 'all';
  lazyImport: () => Promise<{ default: React.ComponentType }>;
}

export const routeConfig: RouteDefinition[] = [
  {
    path: '/inventory',
    label: 'Inventory Management',
    required: ['inventory_view'],
    lazyImport: () => import('./remotes/InventoryMFE'),
  },
  {
    path: '/analytics',
    label: 'Business Analytics',
    required: ['analytics_read', 'analytics_export'],
    strategy: 'any',
    lazyImport: () => import('./remotes/AnalyticsMFE'),
  },
];

Architecture Rationale

• Flattening at the boundary: Keeps frontend logic declarative. The backend retains complex RBAC/ABAC models; the client receives only what it needs to render.
• Set-based lookups: Eliminates O(n) traversal overhead. Critical for enterprise portals with 50+ capabilities.
• Pre-Suspense interception: Prevents chunk downloads. React Router evaluates the element prop synchronously, so the guard executes before React.lazy schedules the network request.
• Unified configuration: Enforces single source of truth. Reduces maintenance overhead and eliminates UI/backend permission mismatches.

Pitfall Guide

1. Post-Lazy Permission Checks

   • Explanation: Evaluating capabilities inside the remote component or after React.lazy resolves. The bundle has already been fetched.
   • Fix: Place the guard at the route definition level, wrapping the lazy import. Evaluate before the element renders.

2. Array-Based Permission Lookups

   • Explanation: Using .includes() or .filter() on large capability arrays. Performance degrades linearly and causes unnecessary re-renders.
   • Fix: Convert the payload to a Set immediately upon authentication. Use .has() for constant-time evaluation.

3. Duplicating Route and Navigation Config

   • Explanation: Maintaining separate arrays for <Route> definitions and sidebar menu items. Leads to drift where hidden routes appear in navigation or vice versa.
   • Fix: Define a single RouteDefinition[] array. Map it to both the router and the navigation component using a shared filter function.

4. Treating Frontend Guards as Security

   • Explanation: Assuming route guards prevent data leakage. Client-side checks can be bypassed via direct API calls or DevTools.
   • Fix: Treat frontend guards as UX optimization and bandwidth conservation. Always validate capabilities on the backend for every data request. Return 403/401 consistently.

5. Over-Engineering Nested Permission Trees

   • Explanation: Attempting to parse hierarchical backend structures (e.g., { orders: { view: true, edit: false } }) in the browser. Increases bundle size and complexity.
   • Fix: Flatten the structure at the auth boundary. Send ['orders_view', 'orders_edit'] to the client. Keep frontend logic flat and predictable.

6. Missing Explicit Redirect States

   • Explanation: Relying on implicit rendering failures or blank screens when access is denied. Creates poor UX and debugging friction.
   • Fix: Use <Navigate> with replace to prevent history stack pollution. Provide a dedicated /access-denied route with contextual messaging.

7. Hardcoding Roles Instead of Capabilities

   • Explanation: Checking user.role === 'manager' instead of specific permissions. Breaks when roles evolve or cross-functional access is granted.
   • Fix: Evaluate capabilities (reports_export) rather than roles. Align frontend checks with backend policy engines for consistent authorization models.

Production Bundle

Action Checklist

• Normalize backend permission payload into a flat string array at the authentication boundary.
• Store capabilities in a Redux slice configured as a Module Federation singleton.
• Convert the capability array to a Set during slice initialization for O(1) lookups.
• Implement a route guard component that evaluates capabilities before rendering lazy imports.
• Define a unified RouteDefinition configuration object for routing and navigation.
• Map the configuration to both <Route> elements and sidebar menu components.
• Add explicit /access-denied and /loading fallback routes to handle guard transitions.
• Verify backend API endpoints enforce identical capability checks to prevent data leakage.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Enterprise portal with 50+ capabilities	Set-based useAccessControl + pre-Suspense guard	Eliminates O(n) traversal and prevents unnecessary chunk downloads	Reduces CDN egress by 15–30%
Small internal tool with <10 routes	Simple array .includes() + inline route check	Lower implementation overhead; performance difference is negligible	Minimal dev time, no infra cost
Multi-tenant SaaS with dynamic permissions	Flattened capabilities + unified config + backend 403 enforcement	Ensures consistency across tenants and prevents configuration drift	Slight increase in auth payload size, offset by reduced support tickets
Legacy monolith migrating to MFE	Gradual route guard adoption + capability mapping layer	Allows incremental migration without breaking existing navigation	Moderate refactoring cost, high long-term maintainability

Configuration Template

// accessConfig.ts
import React from 'react';
import { RouteGuard } from './RouteGuard';

export interface AccessRoute {
  path: string;
  label: string;
  required: string[];
  strategy?: 'any' | 'all';
  fallback?: string;
  lazyImport: () => Promise<{ default: React.ComponentType }>;
}

export const accessRoutes: AccessRoute[] = [
  {
    path: '/dashboard',
    label: 'Overview',
    required: ['dashboard_view'],
    lazyImport: () => import('./modules/DashboardMFE'),
  },
  {
    path: '/compliance',
    label: 'Compliance Center',
    required: ['compliance_read', 'compliance_audit'],
    strategy: 'any',
    fallback: '/restricted',
    lazyImport: () => import('./modules/ComplianceMFE'),
  },
];

export function buildRouterRoutes() {
  return accessRoutes.map((route) => {
    const LazyComponent = React.lazy(route.lazyImport);
    return {
      path: route.path,
      element: (
        <RouteGuard
          required={route.required}
          strategy={route.strategy}
          fallbackPath={route.fallback || '/unauthorized'}
        >
          <React.Suspense fallback={<div>Loading module...</div>}>
            <LazyComponent />
          </React.Suspense>
        </RouteGuard>
      ),
    };
  });
}

Quick Start Guide

1. Initialize the auth slice: Replace your existing permission array with a Set in your Redux store. Dispatch setCapabilities immediately after successful authentication.
2. Create the access hook: Copy the useAccessControl implementation. Ensure it reads directly from the Redux Set to guarantee O(1) performance.
3. Define your route configuration: Replace scattered <Route> declarations with a single accessRoutes array. Include required capabilities and lazyImport functions.
4. Wrap lazy imports with the guard: Use the RouteGuard component to intercept route matches. Pass required, strategy, and fallbackPath props.
5. Validate and deploy: Test unauthorized navigation in a staging environment. Verify that network tabs show zero requests for blocked routes and that redirects occur synchronously.