Question
Choosing hx-target innerHTML versus hx-swap-oob outerHTML for updating a remote status element with regional time zone considerations
Ash Moss
0 reputation · 29 Feb 2020, 08:43 UTC
42.4K views1
Loading…
0 reputation · 29 Feb 2020, 08:43 UTC
Goal: refresh a status badge located outside the triggering button while ensuring the displayed date reflects the user's local time zone.
Constraint: htmx provides no native time‑zone or date conversion attributes, so the choice of swap mechanism influences where date formatting must occur.
Using hx-target with hx-swap='innerHTML' swaps only the badge's inner markup, preserving the container and allowing client‑side script to re‑initialize date libraries after the swap.
Using hx-swap-oob='outerHTML:#id' replaces the entire remote element, which may embed a pre‑formatted timestamp but cannot inject new client scripts without additional event wiring.
Questions: Does hx-swap-oob guarantee a single deterministic time representation per request? Can hx-target reliably trigger client‑side date formatting after each swap? Which approach minimizes extra JavaScript for regional time zone handling?
35275 reputation · 29 Feb 2020, 13:55 UTC
Use hx-target with innerHTML for reliable client‑side date formatting and minimal extra JavaScript.
hx-swap-oob replaces the whole element; it can embed a pre‑formatted timestamp but cannot inject new scripts without additional wiring, so deterministic local time representation depends on the server’s output. hx-target swaps only the badge’s inner markup; after each update the existing client script can be re‑executed, allowing reliable local time zone conversion if the script runs after the swap.
Is the timestamp already localized to the user’s timezone in the server response?
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 29 Feb 2020, 14:58 UTC
One clarification: hx-swap-oob is not limited to replacing the whole element. You can prefix the selector with a swap style, such as hx-swap-oob="innerHTML:#badge", which swaps only the contents of the out-of-band target while leaving the original node and its listeners intact. This gives you the same DOM-preservation benefit as hx-target without requiring the badge to be inside the request target.
If you use outerHTML:#badge, the element is replaced wholesale, so listeners attached to the badge itself are lost and must be re-bound. For time zone handling, htmx:afterSwap fires for out-of-band swaps in htmx 1.x and 2.x, but event.detail.elt references the new node, so a client-side Intl.DateTimeFormat call must target the replacement rather than a cached reference.
Server-rendered timestamps also become stale if the user changes their system time zone after page load, unless the zone is re-sent with each request via htmx:configRequest. Verify the exact default swap behavior for your pinned htmx version before relying on it.
htmx