htmx
htmx copied to clipboard
Specify multiple targets to swap
This is a related note to this: https://github.com/bigskysoftware/htmx/issues/26
And I appreciate possibly a hard ask, but...
I understand how the oob
feature lets me return multiple containers that can get injected into the page, but this requires architecting my app such that it only returns fragments in response to an htmx request. However I would prefer to always send a single, full-page HTML response, and leave it to the front-end to pick and choose what to inject or discard.
For example if I'm building a store, and I want a user to be able to add an item to their cart, there are at least 2 DIVs in the response that I'd like to select & inject; a flash/notice confirming the add, and an update to the cart icon along my navigation bar.
I'm curious to hear your thoughts on this scenario. Thanks!
that seems reasonable to me
would it make more sense on the select attribute?
https://htmx.org/attributes/hx-select/
@chg20 Yeah I think so... I'm just trying to imagine how it would work, without being a breaking change. As it stands now, whatever element(s) from the response match the value of hx-select
are injected into hx-target
. If no hx-select
is specified, then the entire contents are injected into hx-target
.
But the way I imagine it (which is based on Unpoly's behaviour), is that hx-select
would find matching elements in the response, and inject them into the same matching elements on the page.
So would this be about changing the "mode"? Or should it instead introduce a new hx-match
attribute that does it all?
OR - is there a reason why hx-swap-oob
is limited to the top-level of the response? Because if we could overcome that limitation, this all might work. hx-target
would specify the page container, and by default swap the entire contents of the response into it; hx-select
would let you select element(s) to take from the response to put into hx-target
; and any hx-swap-oob
elements found would be swapped into their in-page counterparts.
?
I can see the argument that hx-swap-oob
elements outside the content that is being swapped into target should be able to live anywhere, rather than just on the top level.
Would that change address your needs?
@chg20 I think so! :)
I'm not sure if this makes sense, but to me it seems possible to solve it by accepting a javascript target like so: hx-target="javascript:myfunction"
, which then would be called with the server response.
Then I could just write a javascript function to update the parts making sense in the page - while still enjoying the nice htmx syntax for the input.
The whole point of htmx is so we can write less javascript.
The whole point of htmx is so we can write less javascript.
As far as I can tell, we haven't reached a working mechanism for specify multiple targets to swap. So I came up with a suggestion that might work in the special cases where the standard functionality doesn't cut it.
Given this, did you have anything constructive to add or were you satisfied with taking a dump on my suggestion?
Current mechanism specifies target in the source element, would it be possible to target some kind of wrapper element and inside that element specify multiple receivers? hx-target-wrapper
would specify which node is searched for receivers. When receiver is found, HTML is swapper by HTML specified by given selector from received document.
Main document
<button hx-target-wrapper="#gift-module"></button>
<div id="shipping-module">
Shop for <div hx-wrapper-reveicer=".gift-remaining-price"></div> and get <div hx-wrapper-reveicer=".gift-name"></div> for free.
</div>
Received document
<div class="gift-remaining-price">25$</div>
<div class="gift-name">Potato Chips</div>
@sandebert that's a reasonable feature request, I am considering it.
i'm considering to use htmx
for a redo of a project that includes a book's representation. my goal would be to keep the individual server-rendered page views while giving the users an impression of seamless page changes. as book page-specific contents are scattered over the webpage this would require to update more than one element at a time.
here's an example i came up with that only includes relevant bits and a proposal for a syntax extension of the hx-swap
attribute:
<head>
<!-- there's also this problem, that is probably unsolvable with this technology-->
<title>Adams, D.: A hitchiker's … (page 42)</title>
</head>
<body>
<div id="title">
<h1>Adams, Douglas: …</h1>
<h2 id="chapter-title">Chapter 4</h2>
</div>
<div id="controls">
<div id="page-selection" hx-boost="true" hx-swap="fragments(#chapter-title, #pages-selection, #facsimile, #transcription) swap:500ms">
<a href="/page/41">Previous page</a>
<div>
<a href="/page/0">Cover</a>
<a href="/page/1">Chapter 1, Page 1</a>
<a href="/page/1">Chapter 1, Page 2</a>
…
</div>
<a href="/page/43">Next page</a>
</div>
</div>
<div id="facsimile">
<img src="…">
</div>
<section id="transcription">…</<section>
</body>
since i'm putting some effort into the whole project anyway, i could also try to implement an agreed design.
Would out of band swaps work for you?
https://htmx.org/docs/#oob_swaps
no, my example is maybe too sparse, as it doesn't show elements between and around those in question. so, my requirement would also be to swap multiple scattered elements by one hyperlink invocation.
in hope to stimulate a discussion on the design, i throw in further ideas and half-baked thoughts:
<div hx-boost="true" hx-targets="#title, #contents">
<a href="/foo.html">Follow me</a>
</div>
but targets
is far too close to target
which is already a keyword, so one could introduce fragments
:
<div hx-boost="true" hx-fragments="#title, #contents">
<a href="/foo.html">Follow me</a>
</div>
as the main aim wouldn't be to speed up responses in my case, the boost
keyword doesn't really fit. swap
on the contrary is well fitting and i can also think of designs that could make use of what hx-swap
is currently intended for and targeting scattered parts. e.g. a table to display and edit datapoints and another element that displays aggregated data derived from the whole dataset. but that'd require the mixing of different replacement modes and a reasonable syntax that can express it. that might be a topic for my next nap.
I would recommend exploring these ideas with an extension:
https://htmx.org/extensions/
In particular, the handleSwap
extension point, as shown in the morphdom extension:
https://unpkg.com/[email protected]/dist/ext/morphdom-swap.js
if you meant that morphdom
could be used for that case, i'd answer that i'm one of the explicit is better than implicit guys.
implementing an extension is a good idea and might happen from my side, but not too soon. i appreciate any feedback and proposals on syntax and behaviour.
Jus to thrown in another use case that I am working on, namely pressing "add to cart" would change the button to a disabled "added to cart", and update the number of cart items.
Right now I am implementing number of cart items to be a hx-get='/cart/count' hx-trigger="every 5s"
, but I would appreciate someway to push the cart count to frontend after cart change.
Edit: I am testing if hx-trigger='load delay:1s, click from:.cart-change-action delay:1s'
would work. Basically the click of add-to-cart
would trigger the update of the item-count
.
Edit: The above does not work after I add cart-change-action
to add to cart
button, maybe because the button does not exist when the cart element was created.
Edit: https://github.com/bigskysoftware/htmx/issues/339 works.
Any progress on this..?
OK, resurrecting this issue:
I like the idea in general, but I think this should be implemented as an extension first by someone who needs the functionality, then we can consider moving it into the core. The morphdom swap extension is a good place to start:
https://htmx.org/extensions/morphdom-swap/
Not sure if it helps, but I do multiple fragment updates via websockets and OOB swaps. It does require an extra websocket connection though ...
And about a scenario where we have several elements with the same class
attribute, for example.
If we use hx-target=[class=classname]
this will catch just the first.
What if a hx-targets
attribute where under the hood performs a querySelectAll
?
Would a viable solution be something like the following?
<div hx-target="{
'.container':'.responseContainer',
'#otherDiv':'#responseId'
}">
Basically having an object with targets mapped to selects (combination of what is now hx-select and hx-target).
Any update on this. Basically I am trying to achieve the following
Update 2 div with the response of hx-get
<button
hx-get="/views/users/byId/userId"
hx-target="#id1,#id2">Details</button>
<div id="id1"></div>
<div id="id2"></div>
You probably want the multiswap extension (https://htmx.org/extensions/multi-swap/) or, my favorite, idiomorph.
Is there any objection to support this? or we should go for the extensions way?
what about hx-select-oob="#div1,#div2"
with hx-select="none"
?
i am considering merging the extension behavior into htmx proper as it obviously is a need people have
for now, please use the extension
If you merge this sometimes, could you remove the "multi:" prefix - as it makes not really sense. If there is a comma, it is a list.
I only want to add a thought, a common use case.
You trigger a htmx request by a select change, and want two other input fields of that form react on that (typical example of dynamic form). These two fields have 2 different ids, and you want to use a GET request on ".", using hx-select
and hx-target
attrs. With one field, this works perfectly, with multi fields, it would need something like
hx-target="id_input_one,id_input_b"
and hx-trigger="id_input_one,id_input_b"
.
Does multi-swap cope with that?
@1cg My use case is a multi-swap but I have 2 additional complexities.
- One of the swapped elements is "self," if you will. Swapping, among other elements, the element which holds the
hx
attrs. While this works for a non-multi-swap, I'm having trouble with multi-swap and it appears others online have similar difficulties. Is this supposed to be possible with the extension? - I'm also using the
handlebars-template
extension. However, the 2nd of my multi-swaps should not use the template. Does not look like multi-swap extension supports that, correct?
eg (this is my pseudo-syntax, not real htmx syntax)
hx-swap='multi:#evaluation-{{this.BibNumber}}:outerHTML:handlebars-template:my-evaluation-template,#evaluation-{{this.BibNumber}}-comments:innerHTML [this 2nd swap should not use a template, just replacing text['>
Suggestions? Thx!
oldest but very important issue :)
my case is that I want to be able to use different parts of response on multiple targets using client-side-templates extension
and my suggestion.. supporting multiple targets (think this is the most clear notation and shouldnt be a breaking change I think?), multiple overridable templates specified either as now or on the target element (shoudnt either be a breaking change):
<button
hx-ext="client-side-templates"
hx-get="/user/details"
hx-target="#id1,#id2"
mustache-template="a"
>Details</button>
<div id="id1"></div>
<div id="id2" mustache-template="b"></div>
<template id="a">{{name}}</template>
<template id="b">{{age}}</template>