[81reap]

Buttons now aceppt confirm to show a confirmation dialog.

Fixes #831

Assisted-By :: Claude Opus 5.5

[81reap]

$ cat tests/end-to-end/fixtures/repro_831/index.sql 
SELECT 'button' AS component;
SELECT 'Delete' AS title, 'deleted.sql' AS link, 'red' AS color, 'Delete this movie?' AS confirm;

$ cat tests/end-to-end/fixtures/repro_831/deleted.sql 
SELECT 'text' AS component, 'Deleted' AS contents;

$ cat tests/end-to-end/fixtures/repro_831/test.ts 
import { expect, test } from "../../fixture.ts";

test("a button with confirm asks before it acts", async ({ page }) => {
  await page.getByRole("button", { name: "Delete" }).click();
  await expect(page.getByRole("dialog", { name: "Delete this movie?" })).toBeVisible();
  await expect(page).not.toHaveURL(/deleted/);
});

repro_831	sqlite
v0.33.0	✘ failed
v0.47.0	✘ failed
tree	✔ passed

[lovasoa]

@81reap do you really think this is a good idea? are we not encouraging a bad practice here? Things that require confirmation probably should not be behind a simple GET action and a simple link.

the pattern i would recommend is creating confirmation pages that load with a GET and submit a POST on confirmation. I'm not sure how we could make this easy and intuitive to use, but that's a direction I would favor.

Something like

SELECT 'confirmation' as component; 

-- if this point is reached, we know we received an explicit user confirmation over POST

DELETE FROM very_important WHERE id=$id;

Then the deletion button could safely be a simple link to the deletion page.

[lovasoa]

I don't think confirmation on buttons is a good idea, actually.

[81reap]

I think the confirmation dialog is a useful flow to have, espically on mobile where it is easy to fat finger the wrong thing.

That said I do see your point about the insecure GET and doing the classic "wrap everything in a GET call" anti pattern happening here as well. That's a good call. lemme think about this more