# Demo Page
> Use when creating a demo or test page for manual testing of Handsontable. Trigger when the user asks to create a demo, test page, repro page, reproduction case, manual test, or wants to verify a bug fix or feature visually. Also trigger when the user mentions dev-generated.html, dev-pr.html, dev-latest.html, dev.html, or wants to compare behavior between a released version and a local build. Use this for any PR that needs a manual testing artifact.
- Skill: `handsontable/demo-page` (Agent Skill)
- Install (CLI): `npx skillmds@latest add handsontable/demo-page`
- Raw SKILL.md: https://api.skillmd.com/api/skills/handsontable/demo-page/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: handsontable (https://skillmd.com/u/handsontable)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/handsontable/demo-page
---
# Demo Page Generator
Generate two self-contained HTML demo pages for manual testing:
| File | Loads from | Purpose |
|------|-----------|---------|
| `handsontable/dev-latest.html` | jsDelivr CDN (latest published version) | Shows the current/buggy behavior |
| `handsontable/dev-pr.html` | Local `dist/` (built from the branch) | Shows the fix or new feature |
Both files are gitignored (`dev*.html` pattern), so they never pollute the repo.
Each file links to the other at the top, so a reviewer can switch back and forth without losing scroll position or state context. **Two separate files means complete JS/CSS isolation** — no dual-instance loading tricks, no stylesheet toggling, no shared globals between versions.
## Step 1 — Analyze the PR context
Before generating the demo, understand what needs testing. Read the relevant source changes to determine:
- What bug is being fixed, or what feature is being added?
- Which plugins, editors, cell types, or settings are involved?
- What user interaction reproduces the issue (click, double-click, keyboard, scroll, touch)?
- Are there specific data shapes needed (merged cells, nested headers, large datasets)?
Use `git log` and `git diff` against the base branch to understand the changes. If there's a linked GitHub issue, read it for reproduction steps.
## Step 2 — Build Handsontable
Always run the build unconditionally — do not check whether `dist/` exists first:
```bash
npm run build --prefix handsontable
```
## Step 3 — Generate the two demo files
Write both files using the templates below. Both are gitignored (`dev*.html`), so they never pollute the repo.
> **Files already exist?** Both files are throwaway — generated by a previous task. Skip reading them. Wipe them first, then write fresh:
>
> ```bash
> rm -f handsontable/dev-pr.html handsontable/dev-latest.html
> ```
>
> Then use the Write tool to create each file from scratch.
Each file is a standalone single-instance page. The nav bar at the top links to the other file — the current file's link is styled as active (non-clickable) so the reviewer always knows where they are.
### Template — `handsontable/dev-latest.html` (Released / CDN)
```html
[short description] — Released v__RELEASED_VERSION__
[Short description of what is being tested]
How to test: [Step-by-step reproduction instructions]
How to test: [Step-by-step reproduction instructions]
```
### Filling in the templates
Replace these placeholders **in both files**:
| Placeholder | Value |
|-------------|-------|
| `__RELEASED_VERSION__` | The latest published version from `handsontable/package.json` (e.g., `17.0.1`). If the PR branch bumped the version, use the version from the base branch (`git show origin/develop:handsontable/package.json`). |
| `[Short description...]` | A one-line summary, e.g., "Filters dropdown closes on Android touch" |
| `[Step-by-step reproduction...]` | Numbered steps the reviewer should follow, e.g., "1. Double-tap cell A1. 2. The editor should open and stay open." |
Keep the `
```
## Step 4 — Serve and verify
Start a local server from the `handsontable/` directory:
```bash
python3 -m http.server 8767 --directory handsontable &
```
Verify both files are reachable:
```bash
curl -s -o /dev/null -w "dev-latest: %{http_code}\n" http://localhost:8767/dev-latest.html && \
curl -s -o /dev/null -w "dev-pr: %{http_code}\n" http://localhost:8767/dev-pr.html
```
Tell the user both URLs:
- `http://localhost:8767/dev-latest.html` — Released version (CDN)
- `http://localhost:8767/dev-pr.html` — PR Build (local)
The nav bar in each file links to the other, so the reviewer can switch back and forth without re-typing URLs.
## Important notes
- Both files are gitignored (`dev*.html`) — they will not appear in `git status` or get committed.
- Each file loads only one Handsontable build — no dual-instance tricks needed.
- If the released version used the old CSS system (pre-v17, `dist/handsontable.full.css`), adjust the CDN CSS link in `dev-latest.html` accordingly.
- For very old version comparisons, check that the API used in the config block exists in both versions.