Repository navigation
Create from…: the preview / edit / confirm window #15
Description
Part of #10 — "Create from…" (materialize) — turn messages, lists, rows and documents into new lists/documents/posts
Web behaviour: choosing a destination opens a finalization window showing exactly what will
be created, before anything is saved. The destination can be switched from inside the window.
For a list the user can set the title and optional description, edit the columns (rename,
change type, remove, Add column), and choose whether to make it public — with a live table
preview of the rows and columns.
For a document the user can set the title and file name, choose public/private, and adjust
the list style (numbered or bulleted) and whether row data appears inline or as sub-items — with
a rendered preview.
On success, links appear to open the new list and/or document immediately.
Tests: column edits survive into the create request; destination switch preserves edits where
they still apply; success state exposes both navigation targets.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/15-materialize-preview-window). Closing here — review and any follow-up happens on the PR.It lives in
:core:materializeso all five entry points (#12, #13, #14, #16) share one window rather than each re-implementing preview/confirm.The destination-switch requirement turned out to be the interesting part: switching changes only the target and discards nothing, with one function deciding which edits each destination can carry. So a title survives List → Doc, while column edits do not reach a doc request (a document has no columns) but are still intact if you switch back.
One deliberate restraint worth noting: the document preview renders from the source columns, not the edited list columns.
docConfigcarries no field list, so rendering renamed columns would promise something the request does not actually ask for.Open item for #12–#14: the window can only preview what the entry point seeds. For a messages source the documented default columns are Content / Author / Posted / Links / Tags, but their wire spellings are not published anywhere, so they were not guessed. An entry point that seeds no columns sends no
fieldsand lets the server derive them, which is safe — but if you know the realsourceKeystrings, those three issues will produce better previews.merge: #15 materialize preview window (PR)