ReviewOS

stacks/ts-cloud

dashboard: consolidate the two confirm patterns into a useOpConfirm composable

#125
Closed glennmichael123 opened this 24 days ago · 0 comments
glennmichael123 24 days ago

Confirmation is currently a per-page convention, which is why gaps keep appearing (see the missing-confirmation issue). With 34 pages this will keep drifting.

Current state

  • 13 pages use the shared partial: /var/www/reviewos-reviewos/releases/74d992a/resources/views/layouts/app.stx:2950:322: include error: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' ╭──────────────────────────────────────────────────────────────╮ │  ERROR  Include Error │ ╰──────────────────────────────────────────────────────────────╯ File: app.stx (line 2950, col 322) Message: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' Context:  2948: 2949: > 2950:

    Confirmation is currently a per-page convention, which is why gaps keep appearing (see the missing-confirmation issue). With 34 pages this will keep drifting.

    Current state

    • 13 pages use the shared partial: /var/www/reviewos-reviewos/releases/74d992a/resources/views/layouts/app.stx:2950:1530: include error: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' ╭──────────────────────────────────────────────────────────────╮ │  ERROR  Include Error │ ╰──────────────────────────────────────────────────────────────╯ File: app.stx (line 2950, col 1530) Message: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' Context:  2948: 2949: > 2950:

      Confirmation is currently a per-page convention, which is why gaps keep appearing (see the missing-confirmation issue). With 34 pages this will keep drifting.

      Current state

      • 13 pages use the shared partial: /var/www/reviewos-reviewos/releases/74d992a/resources/views/layouts/app.stx:2966:46: include error: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' ╭──────────────────────────────────────────────────────────────╮ │  ERROR  Include Error │ ╰──────────────────────────────────────────────────────────────╯ File: app.stx (line 2966, col 46) Message: Error loading include file .../partials/op-confirm: ENOENT: no such file or directory, open '/var/www/reviewos-reviewos/releases/74d992a/resources/components/.../partials/op-confirm.stx' Context:  2964: 2965: > 2966: 2967: 2968:  — serverless.stx:131, serverless/{functions,deployments,queues,scheduler,assets,data}, server/{sites,backups,actions,services,workers,deployments}.
      • 4 pages hand-roll an equivalent bar: server/firewall.stx:123-128, server/team.stx, serverless/secrets.stx:104-109, serverless/alarms.stx:118-123.
      • The askOp / cancelOp / runOp / confirmTok / confirmVerb / canRun block is copy-pasted nearly verbatim in 11 files.

      Divergences between the two

      • Button label: the partial says "Run"; hand-rolled ones say "Remove"/"Delete". server/firewall.stx:126 says "Run" while its trigger says "Remove".
      • The partial's confirm button is a plain btn; hand-rolled use btn danger — so the shared bar renders a non-danger button even for backup:restore.
      • All four hand-rolled bars omit the <pre class="action-output">, discarding stdout/stderr from the API.
      • type="button" is missing on the confirm/cancel buttons in the partial and all four copies.

      Suggested direction

      Extract a useOpConfirm(endpoint) composable so a destructive call can't be made without routing through it, and make the partial's label/severity configurable so the hand-rolled copies can be deleted. Ideally forgetting the confirm becomes impossible rather than merely discouraged.

      Related cleanup: four different feedback mechanisms coexist (opOutput/opShown, message/messageKind, msg/msgOk, output/outputShown) — worth unifying on one useMessage().

      2951: 2952:        — serverless.stx:131, serverless/{functions,deployments,queues,scheduler,assets,data}, server/{sites,backups,actions,services,workers,deployments}.
    • 4 pages hand-roll an equivalent bar: server/firewall.stx:123-128, server/team.stx, serverless/secrets.stx:104-109, serverless/alarms.stx:118-123.
    • The askOp / cancelOp / runOp / confirmTok / confirmVerb / canRun block is copy-pasted nearly verbatim in 11 files.

    Divergences between the two

    • Button label: the partial says "Run"; hand-rolled ones say "Remove"/"Delete". server/firewall.stx:126 says "Run" while its trigger says "Remove".
    • The partial's confirm button is a plain btn; hand-rolled use btn danger — so the shared bar renders a non-danger button even for backup:restore.
    • All four hand-rolled bars omit the <pre class="action-output">, discarding stdout/stderr from the API.
    • type="button" is missing on the confirm/cancel buttons in the partial and all four copies.

    Suggested direction

    Extract a useOpConfirm(endpoint) composable so a destructive call can't be made without routing through it, and make the partial's label/severity configurable so the hand-rolled copies can be deleted. Ideally forgetting the confirm becomes impossible rather than merely discouraged.

    Related cleanup: four different feedback mechanisms coexist (opOutput/opShown, message/messageKind, msg/msgOk, output/outputShown) — worth unifying on one useMessage().

    2951: 2952:      — serverless.stx:131, serverless/{functions,deployments,queues,scheduler,assets,data}, server/{sites,backups,actions,services,workers,deployments}.
  • 4 pages hand-roll an equivalent bar: server/firewall.stx:123-128, server/team.stx, serverless/secrets.stx:104-109, serverless/alarms.stx:118-123.
  • The askOp / cancelOp / runOp / confirmTok / confirmVerb / canRun block is copy-pasted nearly verbatim in 11 files.

Divergences between the two

  • Button label: the partial says "Run"; hand-rolled ones say "Remove"/"Delete". server/firewall.stx:126 says "Run" while its trigger says "Remove".
  • The partial's confirm button is a plain btn; hand-rolled use btn danger — so the shared bar renders a non-danger button even for backup:restore.
  • All four hand-rolled bars omit the <pre class="action-output">, discarding stdout/stderr from the API.
  • type="button" is missing on the confirm/cancel buttons in the partial and all four copies.

Suggested direction

Extract a useOpConfirm(endpoint) composable so a destructive call can't be made without routing through it, and make the partial's label/severity configurable so the hand-rolled copies can be deleted. Ideally forgetting the confirm becomes impossible rather than merely discouraged.

Related cleanup: four different feedback mechanisms coexist (opOutput/opShown, message/messageKind, msg/msgOk, output/outputShown) — worth unifying on one useMessage().

Sign in to comment on this issue.