End-to-end example of building a CRUD form with Pure Admin components wired up through vanilla JavaScript. Submissions land in an in-memory store scoped to this browser tab, and the table below renders them with inline editing, a toast-based Undo on delete, and a simulated server failure so you can see how error states are surfaced.
Things to try:
- Submit valid data — the form resets and a success alert replaces any prior status.
- Tick Force validation errors before saving — typed values stick and every
field shows an inline error via the
data-error-forslot under the input. - Click the pencil to edit a row inline; the submit button switches to Update Entry and a Cancel button appears.
- Click × to delete — the entry disappears and a toast with an Undo action gives you a few seconds to bring it back.
- Save with no network luck — submits have a ~10% chance of a simulated failure, which renders a dismissible danger alert without clearing the form.
- Refresh the page — entries reset to the three seed rows, so you can Clear All and reload to get back to a clean demo state.
New Entry
Stored Submissions
0 total
No submissions yet. Fill in the form above and click Save Entry.
| Name | Department | Start Date | Bio | Submitted |
|---|
How it works
Form binding
-
Each field lives in a
.pa-form-grouptagged withdata-field="name". A sibling<small data-error-for="name">is the slot where inline errors land, so the template stays declarative and the JS only has to flip a class and write text. -
Validation returns a plain
{ field: message }object; the renderer addspa-form-group--errorto the group,pa-input--error(orpa-select--error) to the control, and unhides the help text. The Force validation errors checkbox short-circuits validation to a fixed error map so you can inspect all six states without crafting bad input. - A successful submit clears only the inputs — the Force validation errors checkbox keeps its state so you can submit repeatedly while tweaking styles.
State & UX
- Entries are held in a JS array keyed by an incrementing id. The table is re-rendered wholesale on every change — simple, and small enough that diffing isn't worth the complexity.
- The summary alert above the form uses replace semantics: each outcome (validation failure, simulated server error, success, edit-mode entry) overwrites the previous banner so stacking never happens.
-
Delete uses the optimistic toast + undo pattern via
PureAdmin.toast.show({ actions: [...] }). The row disappears immediately; an Undo button on the toast restores it at its original position before the toast auto-dismisses. - The destructive bulk action (Clear All) falls back to a native confirm because there's no undo affordance — losing the whole set silently would be surprising.
-
Submits are run through a
simulateServerSave()promise that resolves with a ~10% failure rate after a short delay, so the success / danger alert paths are both exercisable without tooling.