Read here. Code on desktop. The coding workspace opens on screens 1024px and wider.
User interface challenge
Users Database
medium35 min
Build an in-memory user directory with filtering, validated creation and editing, stable IDs, and confirmed deletion.
Requirements
Start with the three supplied users. Store all exercise records locally in state; this challenge does not read or modify application accounts or require an API.
Render Name, Email, and Actions, with Edit and Delete buttons. Filter by a case-insensitive substring of name or email after trimming the query. Keep the input controlled.
Show the visible/total count, and No matching users. when no records match. Filtering must never remove data.
Use a controlled Name and Email form for both creation and editing. Trim both values and normalize saved emails to lowercase. Name must contain 2–80 characters; email must match the supplied basic pattern.
Use the exact errors Name must contain 2–80 characters., Enter a valid email address., and That email is already in use. Reject case-insensitive duplicate email addresses, excluding only the current edited record. Invalid saves keep all users and the draft unchanged.
Create users with monotonically increasing IDs starting at 4; never reuse deleted IDs. Append a new user. Edit keeps the existing ID and position. A successful save clears the draft/errors and shows User added. or User updated.
Cancel discards the draft and returns to Add user without changing records. Preserve the current filter during all save, cancel, and delete actions.
Delete first shows inline confirmation. Keep user cancels it; Delete user removes only the confirmed record and shows User deleted. If that record was being edited, clear its stale draft and errors.
All form/table markup and complete visual styling are supplied. Implement controlled fields, validation, filtering, and CRUD handlers; no persistence, fetching, pagination, auth, or external form library is required.
Examples
Example 1
Input: Filter Grace, then add Katherine with a different email.
Output: The filter remains Grace, the new record is stored, and the count is 1 of 4 users.
Implement the same visible behavior in each supported framework.
What the tests check
Initial directory and controlled empty form
Creates a trimmed user with normalized email and a stable ID
Rejects invalid names and email without changing users
Rejects duplicate emails ignoring case
Edits in place and permits keeping the same email
Edit validation excludes only the record being edited
Cancel discards unsaved edits
Filtering matches trimmed names and emails case-insensitively
No-match state keeps the underlying data
Saving preserves the current filter
Deletion requires confirmation and can be cancelled
Deleted IDs are never reused for newly added users
