phlex-reactive 0.4.1 → 0.4.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 786d397de0be7e32424c73079906cdf8d32d0325727d06027025d888693754e6
-  data.tar.gz: b080f12ff8c8f4271066993548f9c951278fe2dacabf9b7d21c2113704f58da4
+  metadata.gz: 63629dadef998637b9b65f885a00d54297821f405599a64c103e3b482e991fdc
+  data.tar.gz: 4826a5cf276f46cdf99575cb624169bacbbc3bf85115ca1256542e4c7aeb6f6b
 SHA512:
-  metadata.gz: 316b9b2094490dd5045d1362276a8f31ba4deee96df08e6614dc9db8f62a2ceb822f5a474d2204dcb65f7ed1bb27b3c99303f14a180a336c2d5bc3d21c3bf31a
-  data.tar.gz: f54ecfe74e977b3d4a399cd004071792a3a7245636d1c82f19441b0240fb2d24d32bb072a3ae863a9e04efcab5a31182560628237f72bf77ff73ac387592e4c4
+  metadata.gz: 7561f6119d33b19334078c64570bb2fc7e6e9064b0ee90c4bcbac21dbbe2e07d5ccdb0854d146848efee66bb084c895eb89a853c3931de4c7fd115a0594163d9
+  data.tar.gz: 5220bfda32b47381507fed0d3a9a9d6620f06e9a10dbd8eb877fc07a0f420a8a1e3ff2dd06805059b0b0b7f550bb76cac81a7899f258bb85508643ef61dc8e35

data/CHANGELOG.md

@@ -72,6 +72,53 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ### Fixed
 
+- **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
+  correct — the container's fresh `reactive:token` stream is present — but the
+  client still broke. After each action the reactive controller stores the
+  response's fresh token for its NEXT dispatch; `#extractToken` did
+  `html.match(/data-reactive-token-value="([^"]+)"/)` — the FIRST match in the whole
+  body. On a collection of reactive rows the response is, in body order: the
+  appended/prepended ROW (carrying its OWN token, since a reactive row is itself a
+  `data-controller="reactive"` root) FIRST, then the container's `reactive:token`
+  refresh LAST. So the list controller stored the ROW's token; its second dispatch
+  sent a row token → failed verification → the second add silently did nothing. The
+  fix reads the token that RE-RENDERS this controller's own element id — preferring
+  the dedicated `reactive:token` stream targeting `this.element.id`, then a self
+  `replace`/`update` of it — and otherwise keeps the existing token (never adopting
+  a child row's or a sibling component's token). This is the exact client analogue
+  of the #44 server rule: a stream "carries the token for C" only when it re-renders
+  C itself, never when it inserts children into C. A request-level test can't catch
+  this (the server response is already correct); covered by a bun unit test on the
+  token selection AND a real two-click browser test (a collection of reactive rows →
+  three rows after three adds) under Puma + Falcon. Refs cosmos#1939, #44, #30.
+
+- **Collections of *reactive* rows were still add-once-only — a prepended/appended
+  row's OWN token suppressed the container's token refresh (#44).** When an action
+  appended/prepended a *reactive* child row into a container whose `#id` equals the
+  append target (the most common collection shape — rows go directly into the
+  container element), that single `append`/`prepend` stream carried BOTH
+  `target="<container>"` and the row's own `data-reactive-token-value` (embedded in
+  the `<template>`). `carries_token_for?` matched
+  `include?("data-reactive-token-value") && include?(target)` in that one string →
+  both true → it concluded the container's token was already fresh and **skipped**
+  the container's `reactive:token` refresh. So the container (which owns the
+  add/remove trigger) never rolled its token forward, and the second dispatch was
+  rejected with the stale token — the list silently stopped after the first add.
+  This hit both the hand-rolled `reply.streams(Row.prepend(...), …)` form **and**
+  the `reactive_collection` / `reply.append`/`reply.prepend` helper, since they
+  share the gate. Fixed by tightening `carries_token_for?`: a stream "carries the
+  token for C" only when its action RE-RENDERS C itself (`replace`/`update`/
+  `reactive:token` at C's target) — `append`/`prepend` (which insert *children*
+  into C) never count, because a reactive child's token is not the container's. The
+  idempotency the gate provided is preserved (a caller's own self-replace still
+  suppresses the duplicate token) and the #30 sibling case still refreshes
+  correctly. Covered at the request level: a reactive row appended twice in a row
+  (the second using the token the first rolled forward) now succeeds, and each
+  response carries a `reactive:token` stream targeting the container with a
+  non-empty token. Refs cosmos#1939, #35, #30.
+
 - **0.4.0 regression: re-renders lost the `request`, crashing `form_authenticity_token`
   and other request-dependent helpers (#42).** The 0.4.0 render-path perf rework
   built the cached off-request view context from a bare

data/app/controllers/phlex/reactive/actions_controller.rb

@@ -107,15 +107,49 @@ module Phlex
         streams
       end
 
-      # True when one of `streams` already carries a fresh token TARGETING this
-      # component — i.e. the caller hand-built the actor's own token-bearing
-      # stream, so appending to_stream_token would double it. Scoped to the
-      # component's target id (not a global substring) so a sibling component's
-      # stream, which carries its OWN token for a DIFFERENT target, doesn't fool
-      # us into skipping this component's refresh.
+      # Actions that RE-RENDER the component's own root (so the root's fresh
+      # data-reactive-token-value rolls the signed token forward). `append`/
+      # `prepend` are deliberately excluded: they insert CHILDREN into the
+      # component, and a reactive child carries its OWN token — that child token is
+      # not the component's (issue #44). reactive:token is our inert token-only
+      # refresh; replace/update re-render the root.
+      SELF_RENDER_ACTIONS = %w[replace update reactive:token].freeze
+      private_constant :SELF_RENDER_ACTIONS
+
+      # True when one of `streams` already carries a fresh token by RE-RENDERING
+      # this component itself — i.e. the caller hand-built the actor's own
+      # token-bearing stream, so appending to_stream_token would double it.
+      #
+      # The match requires BOTH (a) the stream's action re-renders the component's
+      # ROOT (replace/update/reactive:token — never append/prepend, which insert
+      # children) AND (b) it targets the component's id AND (c) it actually carries
+      # a token. This is stricter than a same-string substring check on purpose:
+      #   * A sibling component's replace targets a DIFFERENT id → (b) fails, so we
+      #     still refresh ours (issue #30).
+      #   * A reactive child row appended/prepended INTO the component carries its
+      #     own token at the component's target, but the action is append/prepend →
+      #     (a) fails, so we still refresh the CONTAINER's token (issue #44). Before
+      #     this, the child's token at the container target suppressed the
+      #     container's refresh and the list was add-once-only.
       def carries_token_for?(streams, component)
         target = %(target="#{ERB::Util.html_escape(component.id)}")
-        streams.any? {  it.include?("data-reactive-token-value") && it.include?(target) }
+        streams.any? do
+          it.include?("data-reactive-token-value") &&
+            it.include?(target) &&
+            self_render_stream_for?(it, target)
+        end
+      end
+
+      # Does this turbo-stream's OPENING tag re-render `target` itself? Matches a
+      # `<turbo-stream action="<self-render>" ... target="<id>">` opening tag — the
+      # action and target on the SAME tag — so a child row's token embedded in an
+      # append/prepend `<template>` can never count as the container's own refresh.
+      def self_render_stream_for?(stream, target)
+        open_tag = stream[/<turbo-stream\b[^>]*>/]
+        return false unless open_tag&.include?(target)
+
+        action = open_tag[/\baction="([^"]+)"/, 1]
+        SELF_RENDER_ACTIONS.include?(action)
       end
 
       # A 200 turbo-stream carrying a namespaced custom action the client turns

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

@@ -64,6 +64,13 @@ export function registerReactiveActions() {
   registerReactiveToken()
 }
 
+// Escape a DOM id for safe interpolation into a RegExp (an id can legally contain
+// regex metacharacters like `.`/`:` — e.g. an `escape:`-namespaced or dotted id).
+// Used by #extractToken to match the stream that re-renders THIS element by id.
+export function escapeRegExp(string) {
+  return string.replace(/[.*+?^${}()|[\]\\]/g, "\\$&")
+}
+
 if (typeof window !== "undefined") {
   if (window.Turbo) registerReactiveActions()
   else document.addEventListener("turbo:load", registerReactiveActions, { once: true })
@@ -286,9 +293,46 @@ export default class extends Controller {
     this.#tokenCache = value
   }
 
+  // Read the next token for THIS controller — the one that re-renders THIS
+  // element's id, never just the first token in the body (issue #46). On a
+  // collection of REACTIVE rows the prepended/appended ROW carries its OWN
+  // data-reactive-token-value and it sorts FIRST in the response; the list's own
+  // fresh token rides a trailing `reactive:token` stream targeting the container.
+  // Grabbing the first match stored the ROW's token, so the list's SECOND
+  // dispatch sent a row token → failed verification → add-once-only. This mirrors
+  // the server's carries_token_for? (#44): a stream carries OUR token only when it
+  // RE-RENDERS our id (reactive:token / replace / update of `this.element.id`) —
+  // append/prepend insert children and never count. Returns undefined when no
+  // stream re-renders our id, so #currentToken keeps its existing value.
   #extractToken(html) {
-    const match = html.match(/data-reactive-token-value="([^"]+)"/)
-    return match?.[1]
+    const id = this.element.id
+    if (!id) {
+      // No id to self-match (shouldn't happen for a reactive root). Fall back to
+      // the legacy first-token behavior so a single-component response still works.
+      return html.match(/data-reactive-token-value="([^"]+)"/)?.[1]
+    }
+
+    // The dedicated token-only refresh for THIS element (partial updates / the
+    // collection container) — an attribute on the <turbo-stream> itself.
+    const tokenStream = html.match(
+      new RegExp(
+        `<turbo-stream\\b[^>]*\\baction="reactive:token"[^>]*\\btarget="${escapeRegExp(id)}"[^>]*\\bdata-reactive-token-value="([^"]+)"`,
+      ),
+    )
+    if (tokenStream) return tokenStream[1]
+
+    // A full self re-render: a replace/update of THIS element whose template root
+    // carries the fresh token. Scope the token search to that one stream so a
+    // sibling/child token elsewhere in the body can't leak in.
+    const selfStream = html.match(
+      new RegExp(
+        `<turbo-stream\\b[^>]*\\baction="(?:replace|update)"[^>]*\\btarget="${escapeRegExp(id)}"[^>]*>([\\s\\S]*?)</turbo-stream>`,
+      ),
+    )
+    if (selfStream) return selfStream[1].match(/data-reactive-token-value="([^"]+)"/)?.[1]
+
+    // Nothing re-rendered our id — keep the current token.
+    return undefined
   }
 
   // True when `el` is collected by THIS reactive root and not by a nested one.

data/lib/phlex/reactive/version.rb

@@ -2,6 +2,6 @@
 
 module Phlex
   module Reactive
-    VERSION = "0.4.1"
+    VERSION = "0.4.3"
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: phlex-reactive
 version: !ruby/object:Gem::Version
-  version: 0.4.1
+  version: 0.4.3
 platform: ruby
 authors:
 - Mikael Henriksson