feat(forms): preview a saved form from its row #495

Merged

longjacksonle merged 1 commit from feat/PMS-744-row-preview into main

2026-08-08 06:37:33 +02:00

longjacksonle commented

2026-08-08 06:35:07 +02:00

Owner

Follows #494, which put Preview inside the editor only. I had argued against the row action there; that was the wrong call, and this adds it.

Why the row is the better place

Asking "what does this one look like?" meant opening an edit form you did not intend to change. That is a detour, and it is a way to leave unsaved edits behind by accident.

What this adds

A Preview action on each definition row, between Edit and Send, opening the same modal the editor does.

preview_from_definition is the sibling of preview_form: one builds from the saved definition, one from the live editor state, both feed the same modal and the same client component, so the two entry points cannot disagree about what a client sees.

Two details the row can get wrong and the editor cannot:

Fields are sorted by sort_order, not trusted in arrival order. Sorted is how the client is served them, and order is the one thing the Fields column ("3") cannot tell you, so getting it wrong here would defeat the point.
A rule kind this build does not understand is dropped. It cannot be rendered honestly. The editor already refuses to save a definition carrying one.

Preview is offered for retired forms too. Looking at one is harmless, and it is exactly what you want before deciding whether to bring it back. Send stays hidden for them.

The modal now states whether it is showing saved or unsaved work, so two entry points into the same view are not mistaken for one another.

Verification

cargo check --all-targets, cargo clippy --all-targets (clean), cargo fmt --all --check (clean), cargo test --lib (268 passed).

One new test pins the two row-specific behaviours: sort order and the dropped unknown rule, plus the unlabelled-field and whitespace-description fallbacks.

Follows #494, which put Preview inside the editor only. I had argued against the row action there; that was the wrong call, and this adds it. ## Why the row is the better place Asking "what does this one look like?" meant opening an edit form you did not intend to change. That is a detour, and it is a way to leave unsaved edits behind by accident. ## What this adds A **Preview** action on each definition row, between Edit and Send, opening the same modal the editor does. `preview_from_definition` is the sibling of `preview_form`: one builds from the saved definition, one from the live editor state, both feed the same modal and the same client component, so the two entry points cannot disagree about what a client sees. Two details the row can get wrong and the editor cannot: * **Fields are sorted by `sort_order`**, not trusted in arrival order. Sorted is how the client is served them, and order is the one thing the Fields column ("3") cannot tell you, so getting it wrong here would defeat the point. * **A rule kind this build does not understand is dropped.** It cannot be rendered honestly. The editor already refuses to save a definition carrying one. Preview is offered for retired forms too. Looking at one is harmless, and it is exactly what you want before deciding whether to bring it back. Send stays hidden for them. The modal now states whether it is showing saved or unsaved work, so two entry points into the same view are not mistaken for one another. ## Verification `cargo check --all-targets`, `cargo clippy --all-targets` (clean), `cargo fmt --all --check` (clean), `cargo test --lib` (268 passed). One new test pins the two row-specific behaviours: sort order and the dropped unknown rule, plus the unlabelled-field and whitespace-description fallbacks.

longjacksonle added 1 commit

2026-08-08 06:35:07 +02:00

feat(forms): preview a saved form from its row

Check / fmt + clippy + tests (pull_request) Successful in 2m25s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

f212f76e99

Follows #494, which put Preview inside the editor only. Asking "what does this one look like?" then meant opening an edit form you did not intend to change, which is both a detour and a way to leave unsaved edits behind by accident.

`preview_from_definition` is the sibling of `preview_form`: same modal, same client component, one built from the saved definition and one from the live editor state, so the two entry points cannot disagree about what a client sees.

Two details the row can get wrong and the editor cannot. Fields are sorted by `sort_order` rather than trusted in arrival order, since sorted is how the client is served them and order is the one thing the Fields column cannot tell you. A rule kind this build does not understand is dropped, because it cannot be rendered honestly.

Offered for retired forms too: looking at one is harmless, and it is exactly what you want before deciding whether to bring it back. The modal now says whether it is showing saved or unsaved work, so the two entry points are not mistaken for each other.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011myibMMwyb6za3GVWJGkiX

longjacksonle scheduled this pull request to auto merge when all checks succeed

2026-08-08 06:35:31 +02:00