phlex-reactive 0.4.5 → 0.4.7

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 781352f05403f22ccf974061e325f0066b9809c20de36a881279fcea424c55a5
-  data.tar.gz: dfd1747be189e0c451f390f396d535aa5c36f7e0fd8d95f31a331a584537976c
+  metadata.gz: 6a9dfa70408b2db2a88337edfc41963ead03b74cd83d919888b9e3b9bbf5eb99
+  data.tar.gz: 3adb9e76db58f23fd80ebbbc9cb50b08768bbf3473ee5f83375d89b781eda454
 SHA512:
-  metadata.gz: 14e5f543ebb18929407b21a90f6851fcbc685954d23c2ef9aa6a37ed770c85bdf7d477bb430799f81837d04a31154ea85343406e6767f128862fecec82aca401
-  data.tar.gz: 55d32359caa8bb5aa7be4b8db1c55cdf58651b08361dd4bd5e87e4b7bf50dd4cdb32d3aaede40be35966e28cf994ff8047006c085f17fc9002bc26f9cc3cf4d7
+  metadata.gz: 3011d097ec4280eaac80d94d914287d9604a3413615875ac719100065ef20d694ac4025e2695483d782f0c99e5803027dc5d717d38a922f4d404f40d67d513d9
+  data.tar.gz: 35b1ec519c60fa7c2a4655b80ad2717d8eca2eb84f71f262ec67ca618b83582acbef81980ceb6125addfb6b47dc9dc5f732170291a507dd2246b1986ddb1097c

data/CHANGELOG.md

@@ -8,6 +8,22 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Added
 
+- **Overridable / async confirm resolver — reuse your themed dialog (#55).**
+  Follow-up to #52. The `confirm:` gate was hardcoded to the synchronous,
+  browser-native `window.confirm`, so a reactive trigger was the one interaction
+  a Hotwire app couldn't theme — every confirmable reactive action showed the
+  unstyled native chrome instead of the app's `Turbo.config.forms.confirm`
+  dialog. The client now resolves the confirmation through an overridable hook
+  (`confirmResolver`, set via `setConfirmResolver` from `phlex/reactive/confirm`),
+  defaulting to `window.confirm`. An app reuses its styled dialog in one line:
+  `setConfirmResolver((m) => window.Turbo.config.forms.confirm(m))`. The resolver
+  may be **async** — `dispatch` `preventDefault`s up front (preserving the #11
+  submit-trigger guarantee), then `await`s the resolver and enqueues only on a
+  truthy result; a falsy resolve or a rejection cancels the action and never
+  leaks an unhandled rejection. Unset, behavior is byte-for-byte identical to
+  0.4.5 (sync native confirm, no dependency); the `confirm:` markup/`on(...)` API
+  is unchanged. README documents the one-line opt-in.
+
 - **`reactive_root` helper — the whole reactive root in one spread (#48).**
   `reactive_attrs` doesn't emit `id:`, so an app could put `id:` on a *child*
   element and leave the controller root's `id` empty — which silently re-opened
@@ -85,6 +101,27 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Fixed
 
+- **`reactive_controller.js` used a relative `./confirm.js` import that 404'd under
+  importmap-rails + Propshaft — taking down every Stimulus controller on the page (#57).**
+  The #55 confirm resolver added `import { confirmResolver } from "./confirm.js"` to the
+  client controller. Under importmap + Propshaft the controller is served at its
+  **digested** URL, and a relative sibling import is left untouched (Propshaft's JS
+  compiler rewrites only `RAILS_ASSET_URL(...)`, and the import map resolves **only**
+  bare specifiers, never relative-resolved URLs). So the browser resolved `./confirm.js`
+  against the digested controller URL and requested an **undigested**
+  `/assets/phlex/reactive/confirm.js` → **404**. The throwing import meant
+  `reactive_controller.js` never evaluated, and in an app that eagerly registers it the
+  whole controllers entrypoint died — **every** Stimulus controller on the page stopped,
+  with no obvious link to phlex-reactive. The fix imports the **bare** specifier the
+  engine already pins (`phlex/reactive/confirm`), which resolves to the digested asset
+  through the import map and mirrors how the gem already expects apps to import the
+  module (`import { setConfirmResolver } from "phlex/reactive/confirm"`). Bundlers
+  (esbuild/webpack/bun) resolve the bare specifier the same way they already resolve
+  `phlex/reactive/reactive_controller`; the gem's bun JS suite resolves it via a new
+  `tsconfig.json` `paths` alias. Covered by a bun unit test (the bare import resolves,
+  and the source no longer carries the relative form). 0.4.5 was unaffected (inline
+  `window.confirm`, no relative import).
+
 - **Client mirror of #44: collections of *reactive* rows were STILL add-once-only in
   the browser — `#extractToken` read the FIRST token in the response, not this
   controller's own (#46).** The server fix in 0.4.2 (#44) made the `add` response

data/README.md

@@ -311,6 +311,7 @@ Use in controllers: `render turbo_stream: Counter.replace(counter)`.
 | `reactive_attrs` | Marks an element reactive + carries the signed token (no `id`). Spread alongside `id:` on the **same** element: `div(id:, **reactive_attrs)`. Prefer `reactive_root`, which can't split them. |
 | `on(:action, event: "click", **params)` | Spread onto a trigger element. Adds `type=button` for clicks. |
 | `on(:action, event: "input", debounce: 300)` | Coalesce rapid events into one round trip after a quiet period (live-as-you-type). |
+| `on(:action, confirm: "Sure?")` | Gate a destructive trigger behind a confirmation. Defaults to `window.confirm`; override the dialog with [`setConfirmResolver`](#custom-confirmation-dialogs-setconfirmresolver). |
 | `reactive_input(:param, **attrs)` / `reactive_select(:param, **attrs)` | Render a control already bound to an action param (no magic `name:`). |
 | `reactive_field(:param, **attrs)` | The attribute hash behind the above — spread onto any control. |
 | `nested_update!(:assoc, attrs)` | Map a nested param onto `<assoc>_attributes` with id preservation; update the record. |
@@ -478,6 +479,37 @@ end
 `nested_attributes(:address, address)` returns the id-merged hash without
 updating, if you need to combine it with other attributes.
 
+### Custom confirmation dialogs (`setConfirmResolver`)
+
+`on(:action, confirm: "Really delete this?")` gates a destructive trigger behind
+a confirmation. Because the reactive controller preempts the event (its own
+`preventDefault` + POST), Hotwire's `data-turbo-confirm` — which routes through
+`Turbo.config.forms.confirm` — never runs for a reactive trigger. So by default
+the gate uses the browser-native `window.confirm` (synchronous, no dependency,
+screen-reader friendly).
+
+If your app already themes confirmations (the common Hotwire setup —
+`Turbo.config.forms.confirm = (message) => Promise<boolean>`, backed by a styled
+modal), reuse that exact dialog for reactive triggers with one line at boot:
+
+```js
+import { setConfirmResolver } from "phlex/reactive/confirm"
+
+// Reuse the same themed dialog the rest of the app already uses.
+setConfirmResolver((message) => window.Turbo.config.forms.confirm(message))
+```
+
+The resolver receives the `confirm:` message and returns `true`/`false` (or a
+`Promise` of one). It may be **async** — the controller `await`s it, then runs
+the action only on a truthy result; a falsy result (or a rejected promise — e.g.
+the user dismissed the dialog) cancels the action, exactly like declining the
+native prompt. The native default is always prevented up front, so a `submit`
+trigger never navigates while the dialog is open.
+
+Unset, behavior is identical to the native `window.confirm` — the `confirm:`
+markup and `on(...)` API are unchanged; only the client's resolution strategy
+gains a seam.
+
 ### `reply` — controlling the action's reply
 
 By default an action re-renders its component in place. To do more, **return**

data/app/javascript/phlex/reactive/confirm.js

@@ -0,0 +1,34 @@
+// The overridable confirmation resolver behind `on(:action, confirm: "…")`
+// (issue #55, follow-up to #52).
+//
+// The reactive controller preempts the click event (its own preventDefault +
+// POST), so Hotwire's `data-turbo-confirm` — which routes through
+// `Turbo.config.forms.confirm` — never runs for a reactive trigger. That made
+// the reactive path the ONE interaction a Hotwire app couldn't theme: every
+// confirmable reactive action showed the unstyled native window.confirm chrome.
+//
+// This module is the seam. `dispatch` resolves the confirm message through
+// `confirmResolver`, which defaults to a Promise-wrapped window.confirm (so the
+// 0.4.5 behavior is byte-for-byte unchanged when nothing is configured: sync,
+// no dependency, screen-reader friendly). An app reuses its themed dialog with
+// one line at boot:
+//
+//   import { setConfirmResolver } from "phlex/reactive/confirm"
+//   setConfirmResolver((message) => window.Turbo.config.forms.confirm(message))
+//
+// The resolver may be sync or async — the controller awaits it via
+// Promise.resolve, so a bare boolean and a Promise<boolean> both work. It must
+// resolve truthy to proceed; a falsy resolve (or a rejection) cancels the
+// action — exactly like declining the native prompt.
+
+// The default: wrap the synchronous native confirm in a Promise so the call
+// site can always `await` it. Read window lazily (per call), not at module load
+// — under SSR / test the global may not exist yet when this module is imported.
+export let confirmResolver = (message) =>
+  Promise.resolve(typeof window !== "undefined" ? window.confirm(message) : true)
+
+// Override the resolver. Pass a function `(message) => boolean | Promise<boolean>`.
+// Truthy resolves the action through; falsy (or a rejected Promise) cancels it.
+export function setConfirmResolver(fn) {
+  confirmResolver = fn
+}

data/app/javascript/phlex/reactive/reactive_controller.js

@@ -1,4 +1,15 @@
 import { Controller } from "@hotwired/stimulus"
+// Import the BARE specifier the engine already pins (phlex/reactive/confirm),
+// NOT a relative "./confirm.js" (issue #57). Under importmap-rails + Propshaft
+// the controller is served at its DIGESTED url; a relative sibling import is
+// left untouched (Propshaft rewrites only RAILS_ASSET_URL(...), and the import
+// map resolves ONLY bare specifiers), so "./confirm.js" resolves against the
+// digested controller url → an undigested /assets/.../confirm.js that 404s, and
+// the throwing import takes down every Stimulus controller on the page. The
+// bare specifier resolves to the digested asset through the import map, and
+// bundlers/bun resolve it the same way they already resolve
+// "phlex/reactive/reactive_controller" (see tsconfig.json paths for the tests).
+import { confirmResolver } from "phlex/reactive/confirm"
 
 // The ONE generic controller behind every reactive Phlex component. It
 // replaces the per-feature Stimulus controllers you'd otherwise hand-write
@@ -171,37 +182,53 @@ export default class extends Controller {
     const { action, params, debounce, confirm } = event.params
     if (!action) return
 
-    // Confirmation gate (issue #52). A destructive reactive trigger can't use
-    // Hotwire's data-turbo-confirm — this controller preempts the event — so a
-    // `confirm:` message threads a data-reactive-confirm-param and we prompt
-    // HERE, BEFORE any preventDefault/enqueue/debounce. On decline we still
-    // preventDefault (so a `submit`/click can't natively navigate on cancel)
-    // and bail — nothing is enqueued, no timer is scheduled. window.confirm is
-    // synchronous + screen-reader friendly and keeps the no-dependency default;
-    // a richer/async dialog can be layered on additively later.
-    if (confirm && !window.confirm(confirm)) {
-      event.preventDefault()
-      return
-    }
-
     // Stop native behavior (button submit / FORM NAVIGATION) HERE, synchronously
-    // within the event dispatch. preventDefault() only works while the event is
-    // still being handled — deferring it into the request-queue microtask (below)
-    // is too late: a `submit` trigger would natively POST the form and navigate
-    // before the reactive round trip runs (issue #11). For a `click` trigger
-    // there's no default to miss, so this was previously invisible. This holds
+    // within the event dispatch — BEFORE the (possibly async) confirm gate below.
+    // preventDefault() only works while the event is still being handled; once we
+    // await the confirm resolver it's too late, and a `submit` trigger would
+    // natively POST the form and navigate before the reactive round trip runs
+    // (issue #11). For a `click` trigger there's no default to miss. This holds
     // for debounced triggers too — the round trip is deferred, but the native
-    // default must still be prevented now.
+    // default must still be prevented now. (Moved ahead of the confirm branch in
+    // issue #55: an async resolver means we can't preventDefault after awaiting.)
     event.preventDefault()
 
+    // Capture the trigger element now; #proceed runs in a later microtask (after
+    // the confirm resolver settles), by which point event.target may be reset.
+    const target = event.target
+
+    // No confirm message → proceed straight away (unchanged fast path).
+    if (!confirm) return this.#proceed(target, action, params, debounce)
+
+    // Confirmation gate (issue #52, made overridable + async in #55). A reactive
+    // trigger can't use Hotwire's data-turbo-confirm — this controller preempts
+    // the event — so a `confirm:` message routes through confirmResolver (default
+    // window.confirm; an app can override it to reuse Turbo.config.forms.confirm).
+    // The resolver may be sync or async; call it INSIDE the chain (via the leading
+    // .then) so even a SYNCHRONOUS override throw rejects this promise instead of
+    // escaping dispatch — a throwing dialog is treated as a cancel, like the user
+    // dismissing it. The .catch is scoped to the resolver step (→ false = cancel),
+    // so a dismissed/erroring dialog never surfaces as an unhandled rejection AND a
+    // genuine bug inside #proceed is NOT silently swallowed. Enqueue ONLY on a
+    // truthy resolution — nothing is enqueued, no timer scheduled, otherwise.
+    Promise.resolve()
+      .then(() => confirmResolver(confirm))
+      .catch(() => false)
+      .then((ok) => {
+        if (ok) this.#proceed(target, action, params, debounce)
+      })
+  }
+
+  // Enqueue the action — debounced if a debounce window is set, else immediately.
+  // Split out of dispatch so both the no-confirm fast path and the post-confirm
+  // microtask share one place (issue #55). `target` is captured up front because
+  // this can run in a later microtask, after event.target has been reset.
+  #proceed(target, action, params, debounce) {
     // Debounced trigger (e.g. on(:update, event: "input", debounce: 300)):
     // coalesce rapid events into ONE round trip after a quiet period, instead of
     // one POST per keystroke (issue #17). A blur flushes a pending dispatch.
     const ms = Number(debounce) || 0
-    if (ms > 0) return this.#debounceDispatch(event.target, ms, action, params)
-
-    // Capture action/params now; the queued work runs in a later microtask, by
-    // which point the event object may have been reset by the browser.
+    if (ms > 0) return this.#debounceDispatch(target, ms, action, params)
     return this.#enqueue(action, params)
   }
 

data/lib/phlex/reactive/engine.rb

@@ -24,7 +24,10 @@ module Phlex
       initializer "phlex_reactive.assets" do
         if it.config.respond_to?(:assets)
           it.config.assets.paths << root.join("app/javascript").to_s
-          it.config.assets.precompile += %w[phlex/reactive/reactive_controller.js]
+          it.config.assets.precompile += %w[
+            phlex/reactive/reactive_controller.js
+            phlex/reactive/confirm.js
+          ]
         end
       end
 
@@ -38,6 +41,19 @@ module Phlex
             to: "phlex/reactive/reactive_controller.js",
             preload: true
           )
+          # The overridable confirm resolver (issue #55). reactive_controller.js
+          # imports it by this BARE specifier — `import { confirmResolver } from
+          # "phlex/reactive/confirm"` — NOT a relative "./confirm.js" (issue #57:
+          # a relative sibling import inside the digested controller resolves to
+          # an undigested /assets/.../confirm.js that 404s under Propshaft). This
+          # pin maps the bare specifier to the digested asset, so the controller's
+          # own import AND an app's `import { setConfirmResolver } from
+          # "phlex/reactive/confirm"` both resolve through the import map.
+          it.importmap.pin(
+            "phlex/reactive/confirm",
+            to: "phlex/reactive/confirm.js",
+            preload: true
+          )
         end
       end
 

data/lib/phlex/reactive/version.rb

@@ -2,6 +2,6 @@
 
 module Phlex
   module Reactive
-    VERSION = "0.4.5"
+    VERSION = "0.4.7"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: phlex-reactive
 version: !ruby/object:Gem::Version
-  version: 0.4.5
+  version: 0.4.7
 platform: ruby
 authors:
 - Mikael Henriksson
@@ -117,6 +117,7 @@ files:
 - LICENSE.txt
 - README.md
 - app/controllers/phlex/reactive/actions_controller.rb
+- app/javascript/phlex/reactive/confirm.js
 - app/javascript/phlex/reactive/reactive_controller.js
 - lib/generators/phlex/reactive/component/USAGE
 - lib/generators/phlex/reactive/component/component_generator.rb