Day 75: User Interface Components - Building Production-Grade User Management UI

What We’re Building Today

Today we’re building the visual layer that transforms our user management API (from Day 74) into an intuitive administrative interface. We’ll create five core UI components: a user management dashboard, team organization interface, permission assignment panel, user profile viewer, and real-time activity monitor. Think GitHub’s organization settings, Slack’s workspace admin, or Datadog’s team management console—professional, efficient, and powerful.

---

---

Why UI Matters in User Management

When Slack redesigned their workspace admin interface in 2023, they reduced permission assignment errors by 67% simply by improving visual hierarchy and adding confirmation flows. GitHub’s user management UI handles 100 million users, processing thousands of permission changes daily without confusion. The difference between good and bad UI here isn’t aesthetics—it’s operational safety. A poorly designed permission UI leads to accidental privilege escalation, orphaned accounts, and security incidents.

Component Architecture Overview

Our UI layer follows a three-tier React architecture: presentational components (pure UI), container components (state management), and service components (API communication). Each tier has a single responsibility. The user list component doesn’t know about API calls; the API service doesn’t render buttons. This separation makes testing trivial and modifications safe.

Netflix’s administrative tools use this exact structure. Their permission UI component tree mirrors their backend service hierarchy, making it impossible for UI state to diverge from actual permissions. When you see “Admin” displayed, you are an admin—no sync issues.

Understanding the Three Layers

The architecture works like this:

Presentational Layer handles what users see—tables, buttons, forms. These components receive data as props and send user actions upward. They’re like restaurant waiters: they take orders and deliver food, but don’t cook.

Container Layer manages state and business logic. It decides what data to show, when to call APIs, and how to handle errors. These components are like restaurant managers: they coordinate between the dining room and kitchen.

Service Layer communicates with the backend. It formats requests, handles responses, and manages network errors. These are like the kitchen: they prepare everything the managers requested.

This separation means you can redesign the UI without touching API code, or switch backends without changing components.

---

---

Component 1: User Management Interface

The user management dashboard displays paginated user lists with real-time search, filtering, and bulk operations. Key features: sortable columns (name, email, role, status, last active), inline editing for quick updates, and batch actions (activate, deactivate, delete).

Datadog’s user list loads 10,000 users instantly by virtualizing the table—only rendering visible rows. We’ll implement the same using react-window. Without virtualization, rendering 1,000+ rows locks the browser for seconds. With it, 10,000 rows render in under 100ms.

The component maintains local state for UI interactions (sort, filter, selection) while syncing actual data changes to the backend immediately. Optimistic updates show changes instantly; background reconciliation ensures consistency.

Building the User List Step by Step

First, we set up the data grid with Material-UI’s DataGrid component. This gives us sorting, filtering, and pagination out of the box.

The search functionality works like this: as you type, we wait 300ms after your last keystroke (debouncing) before filtering. This prevents the UI from re-rendering on every character, keeping it smooth even with hundreds of users.

For filters, we provide dropdown menus for status (active/inactive) and role (admin/editor/viewer). These combine with the search term—so you can find “all inactive admins” by selecting both filters and searching.

The create/edit dialog is a modal that opens when you click “Add User” or the edit icon. It pre-fills with existing data for edits, or shows empty fields for new users. Input validation happens immediately—if you type an invalid email, you see the error before clicking save.

Here’s the important part: when you click “Create User,” the new user appears in the table immediately. We don’t wait for the API response. This is called optimistic updating. Behind the scenes, the API call happens. If it fails, we quietly remove the user and show an error. If it succeeds, we just confirm what’s already displayed. This makes the UI feel instant.

Component 2: Team Management Interface

Teams organize users into logical groups with inherited permissions. Our interface shows team hierarchy (parent/child teams), member lists with role badges, and drag-drop member assignment. The key challenge: representing hierarchical data in a flat UI without confusion.

GitHub uses a nested sidebar for team hierarchy—we’ll adopt this pattern. Each team is a collapsible node showing member count and permission summary. Clicking a team loads its detail view: members, inherited permissions, and subteams.

The team editor supports CRUD operations with validation: can’t delete teams with active members (safety), can’t create circular hierarchies (integrity), can’t exceed nesting depth of 5 (performance). These constraints are enforced in UI before API calls, providing instant feedback.

Implementing Team Hierarchy

The team display uses cards laid out in a grid. Each card shows the team name, description, member count, and an “Add Member” button.

For the hierarchy, we use a simple parent_id system. Teams with no parent are top-level (like “Engineering”). Teams with a parent are children (like “Frontend” under “Engineering”). The UI sorts teams so parents always appear before their children.

When you click “Add Member,” a dialog shows all available users. You can search through them and click to add. The member immediately appears in the team card with their role badge. Again, this is optimistic—the API call happens in the background.

The drag-and-drop feature lets you grab a user from one team and drop them on another. HTML5 provides the drag-and-drop API. We handle the drop event by calling the “remove from old team” and “add to new team” APIs in sequence.

Component 3: Permission Management UI

Permission assignment is the most security-critical UI we’ll build. It visualizes role-permission matrices, supports bulk assignments, and shows effective permissions (combining direct + inherited). The interface prevents dangerous configurations: can’t remove your own admin rights, can’t grant permissions you don’t have, can’t create permission chains exceeding depth 3.

We use a two-panel design. Left panel: user/team selector with permission summary. Right panel: detailed permission matrix with toggle switches. Changes highlight in yellow (pending), green (saved), red (errors). This matches AWS IAM Console’s pattern—familiar to most engineers.

---

---

The permission matrix uses a sparse data structure—only storing granted permissions, not the full NxM matrix. This optimization is crucial when dealing with 500+ permissions across 1,000+ users. GitHub’s permission system works the same way.

Building the Permission Matrix

The UI is a table where rows are users and columns are roles. Each cell contains a toggle switch. When you flip a switch, three things happen:

First, the switch changes color to yellow and the cell gets a yellow background. This is the “pending” state—you’ve made a change but haven’t saved it yet.

Second, we validate the change. Can you actually grant this permission? Are you trying to remove your own admin rights (blocked)? Is this creating a permission conflict? Validation happens instantly, showing errors in red if there’s a problem.

Third, when you click “Save All Changes,” we batch all the pending changes into one API call. This is much faster than individual calls for each change. As the API responds, cells flash green for success or red for errors. The yellow highlighting disappears as changes are confirmed.

The key insight: we track three states for each permission—current (what’s in the database), pending (what the user requested), and displayed (what’s on screen). This lets us show optimistic updates while maintaining data integrity.

Component 4: User Profile Interface

Each user profile shows identity information, assigned roles/teams, activity timeline, and account status. The profile editor supports field-level permissions—users edit their own name/avatar, admins edit everything. Changes trigger audit logs automatically.

The activity timeline updates live via WebSocket. When a user performs actions elsewhere (creates dashboards, triggers alerts), the timeline shows it within 500ms. This real-time feedback is critical for security monitoring—admins detect suspicious activity immediately.

The profile component fetches data in parallel (user info, teams, permissions, recent activity) using Promise.all, reducing load time from 2s to 400ms. Each fetch has independent error handling—partial failures don’t break the entire profile.

Creating the Profile View

The profile page is split into two columns. The left column shows the avatar (a large circular image), name, email, status badge, and chips for roles and teams. This is all static display—no editing here in the basic view.

The right column shows the activity timeline. This is an infinite-scroll list. We load 20 activities initially. As you scroll down, we detect when you’re near the bottom and automatically fetch the next 20. This continues until there’s no more history.

For parallel loading, we kick off all four data fetches at the same time when the page loads:

const [user, activities, teams, permissions] = await Promise.all([
  fetchUser(id),
  fetchActivities(id),
  fetchUserTeams(id),
  fetchUserPermissions(id)
])

This means if each fetch takes 400ms, the total load time is 400ms instead of 1.6 seconds (4 × 400ms) sequential. The profile appears 4x faster.

Component 5: Activity Monitoring Dashboard

The activity monitor displays real-time user actions in a scrolling feed, with filters by user, action type, and time range. It shows who’s doing what, when, and where. Critical for compliance (SOC2 requires user activity logging) and security (detecting unauthorized access).

Slack’s activity feed handles 50,000 events/second by using time-bucketed aggregation. Instead of showing every individual action, it groups: “user@example.com performed 47 dashboard views in the last minute.” We implement the same bucketing—displaying aggregated metrics for the last hour, detailed events for the last 15 minutes.

The feed uses infinite scroll with virtual rendering. New events appear at the top via WebSocket push. Old events load on scroll via paginated API calls. This hybrid approach keeps the UI responsive while maintaining full history access.

Implementing Real-Time Activity Feed

The feed is a simple list component. Each list item shows: user avatar, user name, action badge (colored pill), resource name, details text, and timestamp.

WebSocket connection is managed by a React Context. This context maintains the connection, handles reconnects, and broadcasts messages to all components that need them. When a new activity arrives via WebSocket, we insert it at the top of the feed array.

The activity list auto-scrolls to show new items only if you’re already at the top. If you’ve scrolled down to read older activities, new items appear silently at the top without interrupting you. This respects the user’s current focus.

For aggregation, we group activities by user + action type in 1-minute windows. Instead of showing:

• User A: viewed dashboard (10:01:05)

• User A: viewed dashboard (10:01:12)

• User A: viewed dashboard (10:01:28)

We show:

• User A: 47 dashboard views (last minute)

This reduces clutter by 90% while preserving all the important information.

Data Flow and State Management

User actions flow through this pipeline: UI interaction → optimistic local update → API call → WebSocket broadcast → all connected clients update. This ensures the admin who made the change sees instant feedback, while other admins see updates within 200ms.

We use React Context for global state (current user, permissions, theme) and local component state for UI-only data (filter values, sort order, expanded rows). This prevents unnecessary re-renders—changing a filter doesn’t trigger API calls until the user hits “Apply.”

When multiple admins edit the same user simultaneously, last-write-wins with conflict detection. The UI shows a warning: “User was modified by admin@example.com 30 seconds ago. Review changes before saving.” This prevents accidental overwrites, similar to Google Docs’ conflict resolution.

Understanding State Synchronization

State exists in three places:

Backend Database: The source of truth. This is what’s actually in the system.

Component State: What this browser window thinks is true. Updated optimistically (immediately) when you make changes.

Other Clients: What other admins’ browser windows think is true. Updated via WebSocket when anyone makes changes.

When you create a user, here’s what happens:

1. Your component state updates (new user appears in table)

2. API call fires to backend

3. Backend saves to database

4. Backend broadcasts WebSocket message

5. All connected clients (including yours) receive the message

6. All tables refresh to show the new user

This flow ensures everyone sees the same data, usually within 200ms of any change.

Performance Optimization Patterns

Our UI targets these metrics: initial load under 1.5s, time-to-interactive under 2s, filter operations under 100ms, navigation under 200ms. We achieve this through code splitting (each component loads on-demand), lazy loading (images/charts load when visible), and request batching (combining multiple API calls).

The main bundle is 150KB gzipped. User management component: 45KB. Team management: 38KB. Each loads independently. Without splitting, the bundle would be 600KB—too slow for global users on 3G connections.

Memoization prevents wasted renders. The user list component only re-renders when user data changes, not when unrelated state (like theme) changes. This keeps the 1,000-row table buttery smooth during interactions.

Code Splitting Explained

Instead of loading all JavaScript upfront, we split code by route. The user management page only loads when you navigate to /users. The team management page only loads when you navigate to /teams.

React makes this easy with lazy imports:

const UserManagement = lazy(() => import('./pages/UserManagement'))
const TeamManagement = lazy(() => import('./pages/TeamManagement'))

The first time you visit a page, there’s a tiny delay (maybe 100ms) as the code downloads. But subsequent visits are instant because it’s cached.

This is huge for mobile users. They might only use the user list and never touch teams. Why make them download team management code they’ll never run?

Security Considerations

Every permission check happens server-side. The UI hides/shows features based on user roles, but never trusts client-side enforcement. A user with “viewer” role doesn’t see the “Delete” button, but even if they craft an HTTP request, the backend rejects it.

CSRF tokens protect all state-changing operations. Session timeout triggers automatic logout after 30 minutes of inactivity. All API calls include request signing to prevent replay attacks.

Testing Strategy

Our test pyramid: 120 unit tests (component logic), 40 integration tests (component interactions), 15 E2E tests (full workflows). Critical flows have 100% test coverage: user creation, permission assignment, role changes.

We test edge cases religiously: deleting the last admin (prevented), assigning circular team hierarchies (prevented), concurrent edits (merge conflict UI), network failures (retry with exponential backoff).

---

Hands-On Implementation

GitHub Link:-

https://github.com/sysdr/infrawatch-fullstack-p/tree/main/day75

Now let’s build this system from scratch. We’ll use React with Vite for the frontend and a minimal FastAPI backend for testing.

Prerequisites

Before starting, make sure you have:

• Node.js 20 or higher installed

• Python 3.11 or higher installed

• A code editor (VS Code recommended)

• Basic understanding of React and APIs

Project Setup

We’ve already created a complete implementation script for you. Here’s how to use it:

Step 1: Run the Implementation Script

chmod +x day75_implementation.sh
./day75_implementation.sh

This script creates the entire project structure with all files and folders in the correct locations. It takes about 30 seconds to complete.

Expected output:

Creating project structure...
Creating backend server...
Creating React frontend...
Creating Docker configuration...
Project created successfully!

Step 2: Navigate to Project Directory

cd user-management-ui

You’ll see this structure:

user-management-ui/
├── frontend/          # React application
├── backend/           # FastAPI server
├── docker/            # Docker configuration
├── build.sh           # Install dependencies
├── run.sh             # Start services
└── stop.sh            # Stop everything

Installing Dependencies

Step 3: Install All Dependencies

./build.sh

This script does three things:

1. Creates a Python virtual environment for the backend

2. Installs Python packages (FastAPI, SQLAlchemy, etc.)

3. Installs Node packages (React, Material-UI, etc.)

Expected output:

Setting up backend...
Created virtual environment
Installing Python packages...
Successfully installed 15 packages

Setting up frontend...
Installing Node packages...
Added 847 packages

Build Complete!

This takes 2-3 minutes depending on your internet speed.

Running the Application

Step 4: Start Both Servers

./run.sh

This starts the backend on port 8000 and frontend on port 3000.

Expected output:

Starting backend...
INFO: Uvicorn running on http://0.0.0.0:8000

Starting frontend...
VITE v5.4.11 ready in 387 ms
Local: http://localhost:3000

System Started
Backend: http://localhost:8000
Frontend: http://localhost:3000

Step 5: Open Your Browser

Navigate to

http://localhost:3000

You should see the user management interface with:

• Sidebar navigation on the left

• User list in the main area

• 24 sample users already loaded

• Search and filter controls at the top

Testing the Features

Let’s verify everything works correctly.

Test 1: User List Loads Quickly

Open Chrome DevTools (F12), go to the Performance tab, click Record, then reload the page. Stop recording after the page loads.

Look for these metrics:

• Total load time: Should be under 1.5 seconds

• User table render: Should be under 100ms

• Initial API call: Should complete in under 300ms

Test 2: Search Filters Work

1. Type “alice” in the search box

2. The table should instantly filter to show only Alice Admin

3. Clear the search

4. Select “inactive” from the Status dropdown

5. The table should show only inactive users

Test 3: Create a New User

1. Click the blue “Add User” button (top right)

2. Fill in the form:

   • Email: test@example.com

   • Name: Test User

   • Avatar: https://i.pravatar.cc/150?img=50

3. Click “Create”

4. The dialog closes

5. The new user appears immediately at the top of the table (optimistic update)

6. After ~200ms, the user stays there (API confirmed)

Test 4: Edit an Existing User

1. Find any user in the table

2. Click the edit icon (pencil) in the Actions column

3. Change the name to something else

4. Click “Update”

5. The name changes immediately in the table

6. The API confirms the change (you won’t see any difference if it succeeds)

Test 5: Real-Time Updates

1. Open

http://localhost:3000

1. in a second browser window (or incognito)

2. In window 1, create a new user

3. In window 2, watch the activity feed (click “Activity” in sidebar)

4. You should see the “user_created” event appear within 500ms

5. Go to the Users page in window 2

6. The new user should appear there too (without refreshing)

This proves the WebSocket real-time synchronization works.

Test 6: Team Management

1. Click “Teams” in the sidebar

2. You’ll see three team cards: Engineering, Frontend, Backend

3. Frontend and Backend are children of Engineering

4. Click “Create Team” button

5. Enter name: “DevOps”, description: “Infrastructure team”

6. Click “Create”

7. New team card appears immediately

Test 7: Permission Matrix

1. Click “Permissions” in the sidebar

2. You see a table with users as rows, roles as columns

3. Each cell has a toggle switch

4. Find Alice Admin - she has all three roles (Admin, Editor, Viewer)

5. Toggle off her “Viewer” role

6. The cell turns yellow (pending)

7. Wait a moment - it turns green (saved)

8. Toggle it back on

9. Again: yellow, then green

Test 8: User Profile

1. Click “Profile” in the sidebar

2. You see Alice Admin’s profile

3. Large avatar at the top

4. Name, email, status badge

5. Roles and teams as chips

6. Recent activity timeline on the right

7. Timeline shows her recent actions

All activities should load in under 500ms (check Network tab in DevTools).

Test 9: Activity Monitor

1. Click “Activity” in the sidebar

2. You see a scrolling feed of all user actions

3. Top indicator shows “Live” in green (WebSocket connected)

4. Create a user in another tab

5. The activity feed updates within 500ms showing the create action

Test 10: Performance Under Load

Let’s simulate having many more users. Open the backend file:

# In backend/app/main.py, find the init_db function
# Change this line:
for i in range(5, 25):  # Creates 20 extra users

# To this:
for i in range(5, 505):  # Creates 500 extra users

Restart the backend:

./stop.sh
./run.sh

Now test:

1. Reload the frontend

2. The user list should still load smoothly

3. Scrolling should be buttery smooth (60fps)

4. Search should still respond instantly

This proves virtualization is working - only visible rows are rendered.

Docker Deployment

Want to run in Docker? It’s even simpler.

Step 11: Build and Run with Docker

docker-compose up --build

This builds two containers:

• Backend container (Python + FastAPI)

• Frontend container (Nginx + React build)

Expected output:

Building backend...
Building frontend...
Creating network "user-management-ui_default"
Creating user-management-ui_backend_1...
Creating user-management-ui_frontend_1...

backend_1  | INFO: Uvicorn running on http://0.0.0.0:8000
frontend_1 | Starting nginx

Access the application at

http://localhost:3000

(same as before).

The difference: with Docker, you get:

• Consistent environment (works the same everywhere)

• Easy deployment (single command)

• Isolated dependencies (won’t conflict with other projects)

Step 12: Stop Docker

docker-compose down

Or just press Ctrl+C in the terminal where docker-compose is running.

Troubleshooting Common Issues

Problem: “Port 8000 already in use”

Solution: Another process is using that port. Find and stop it:

lsof -ti:8000 | xargs kill -9

Problem: “npm install fails with EACCES error”

Solution: Permission issue. Run with sudo:

sudo ./build.sh

Problem: “WebSocket won’t connect (shows Disconnected)”

Solution: Backend isn’t running. Check:

curl http://localhost:8000

Should return: {"message": "User Management API", "version": "1.0.0"}

If not, restart the backend:

cd backend
source venv/bin/activate
python app/main.py

Problem: “User list is empty”

Solution: Database wasn’t initialized. Delete and restart:

rm backend/users.db
./stop.sh
./run.sh

Problem: “Changes don’t appear in other browser windows”

Solution: WebSocket isn’t connected. Check browser console for errors. Most common cause: backend isn’t running or firewall blocking WebSocket.

Understanding What You Built

Let’s review the key files and what they do:

Frontend Key Files:

• frontend/src/App.jsx - Main app component with routing and navigation

• frontend/src/pages/UserManagement.jsx - User list with CRUD operations

• frontend/src/pages/TeamManagement.jsx - Team cards and hierarchy

• frontend/src/pages/PermissionManagement.jsx - Permission matrix

• frontend/src/pages/ActivityMonitor.jsx - Real-time activity feed

• frontend/src/contexts/WebSocketContext.jsx - WebSocket connection manager

• frontend/src/services/api.js - API service layer

Backend Key Files:

• backend/app/main.py - FastAPI application with all endpoints

• Contains models: User, Team, Role, Permission, Activity

• Contains API routes for CRUD operations

• WebSocket endpoint for real-time updates

How Components Connect:

1. User clicks button in UserManagement.jsx

2. Component calls function from api.js

3. API service sends HTTP request to backend

4. Backend processes request, updates database

5. Backend broadcasts WebSocket message

6. WebSocketContext.jsx receives message

7. All components subscribed to context update

8. UI shows new state everywhere

This is the complete data flow from click to update across all connected clients.

---

What You’ve Built

You now have a production-grade user management interface that:

• Handles thousands of users with sub-100ms interactions

• Provides real-time activity monitoring via WebSocket

• Implements safe permission management with validation

• Supports team hierarchies with drag-drop organization

• Delivers comprehensive user profiles with audit trails

Success Criteria

Your implementation works when:

1. User list loads 1,000+ users in under 100ms

   • Check: Chrome DevTools Performance tab shows fast render

2. Real-time activity feed shows new events within 500ms

   • Check: Create user in one window, appears in activity feed in another window

3. Permission changes highlight pending state before saving

   • Check: Toggle switch shows yellow, then green after save

4. Search/filter operations feel instant (no visible lag)

   • Check: Type in search box, results update immediately

5. Profile page loads all sections in parallel under 500ms

   • Check: Network tab shows parallel requests completing together

6. Team hierarchy supports drag-drop member reassignment

   • Check: Drag user from one team to another works smoothly

7. Bulk operations (select 100 users, deactivate) complete in under 2s

   • Check: Select many users, perform action, completes quickly

Assignment

Extend the user management interface with these features:

Challenge 1: Advanced Search

Add multi-field search supporting queries like role:admin AND last_active:>7days with syntax highlighting and autocomplete.

Hints:

• Parse query string by splitting on “AND”

• Each part becomes a filter: {field, operator, value}

• Apply filters client-side for small datasets

• Show autocomplete dropdown with available fields

Challenge 2: Custom Views

Let admins save filter combinations as named views (e.g., “Inactive Users”, “Recent Admins”).

Hints:

• Store views in browser localStorage: {name, filters, sortBy, columns}

• Add “Save Current View” button

• Add dropdown showing saved views

• Clicking a view applies its filters

Challenge 3: Keyboard Navigation

Implement full keyboard shortcuts - J/K for navigation, E for edit, D for delete, / for search.

Hints:

• Add onKeyDown handler on table rows

• Maintain selectedIndex in state

• J increments index, K decrements

• E opens edit modal for selected user

• Add visual focus indicator (blue border)

Challenge 4: Export Functionality

Add CSV/JSON export for user lists with current filters applied.

Hints:

• Fetch all matching records (paginate 1000 at a time)

• Convert to CSV using papaparse library

• Trigger download via Blob URL

• Show progress bar during fetch

Challenge 5: Comparison View

Show side-by-side diff when reviewing permission changes before approval.

Hints:

• Store “before” and “after” permission states

• Compute diff using object comparison

• Display in two columns: Before | After

• Highlight additions (green), deletions (red), modifications (yellow)

Success: Advanced search returns results in under 50ms. Custom views persist across sessions. Keyboard navigation allows managing 20 users without touching the mouse. Exports include 10,000+ users without browser freeze. Comparison view highlights exact differences between old and new permissions.

Solution Hints

Advanced Search Implementation:

Parse the query into filter objects. For example, role:admin AND status:active becomes:

[
  { field: 'role', operator: ':', value: 'admin' },
  { field: 'status', operator: ':', value: 'active' }
]

Then filter the user array:

users.filter(user => 
  filters.every(f => user[f.field] === f.value)
)

For autocomplete, maintain an index of available fields and their values. Show suggestions as the user types.

Custom Views Implementation:

When user clicks “Save View”, open a dialog asking for a name. Then:

const view = {
  name: viewName,
  filters: { search, status, role },
  sortBy: currentSort,
  columns: visibleColumns
}
localStorage.setItem(`view_${viewName}`, JSON.stringify(view))

Load views on component mount:

const views = Object.keys(localStorage)
  .filter(key => key.startsWith('view_'))
  .map(key => JSON.parse(localStorage.getItem(key)))

Keyboard Navigation Implementation:

Track the selected row index in state:

const [selectedIndex, setSelectedIndex] = useState(0)

const handleKeyDown = (e) => {
  if (e.key === 'j') setSelectedIndex(i => Math.min(i + 1, users.length - 1))
  if (e.key === 'k') setSelectedIndex(i => Math.max(i - 1, 0))
  if (e.key === 'e') openEditModal(users[selectedIndex])
  if (e.key === 'd') deleteUser(users[selectedIndex].id)
  if (e.key === '/') { e.preventDefault(); searchInputRef.current.focus() }
}

Add a focus indicator to the selected row with CSS: backgroundColor: selectedIndex === rowIndex ? '#e3f2fd' : 'white'

Export Implementation:

Fetch all data in chunks:

const exportData = async () => {
  let allUsers = []
  let page = 0
  
  while (true) {
    const response = await userAPI.getAll({ skip: page * 1000, limit: 1000 })
    if (response.data.length === 0) break
    allUsers = [...allUsers, ...response.data]
    page++
  }
  
  const csv = Papa.unparse(allUsers)
  const blob = new Blob([csv], { type: 'text/csv' })
  const url = URL.createObjectURL(blob)
  
  const link = document.createElement('a')
  link.href = url
  link.download = 'users.csv'
  link.click()
}

Show a progress bar by tracking page and updating a progress component.

Comparison View Implementation:

Fetch both states:

const [oldPermissions, newPermissions] = await Promise.all([
  fetchCurrentPermissions(userId),
  fetchProposedPermissions(userId)
])

const diff = {
  added: newPermissions.filter(p => !oldPermissions.includes(p)),
  removed: oldPermissions.filter(p => !newPermissions.includes(p))
}

Display in two columns with color coding:

<Box display="flex">
  <Box flex={1}>
    <Typography>Current Permissions</Typography>
    {oldPermissions.map(p => 
      <Chip 
        label={p} 
        color={diff.removed.includes(p) ? 'error' : 'default'}
      />
    )}
  </Box>
  <Box flex={1}>
    <Typography>New Permissions</Typography>
    {newPermissions.map(p => 
      <Chip 
        label={p} 
        color={diff.added.includes(p) ? 'success' : 'default'}
      />
    )}
  </Box>
</Box>

YouTube Demo Link:-

Next Lesson Preview

Day 76 we integrate with enterprise authentication systems. We’ll add LDAP/AD directory sync for auto-importing thousands of users, implement SSO (SAML/OAuth) for single-click login, create bulk user import from CSV/JSON, and build automated user provisioning/deprovisioning workflows. You’ll see how Slack and GitHub handle enterprise-scale user management.

Get ready to connect your user management system to real corporate directories and enable seamless single sign-on across your entire platform!