You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to have a block that allows to add extra attributes to the top-level element of an inserted or replaced fragment. I see 2 use cases for this:
Inline SVG images where you want to add class attributes to style the SVG.
When using htmx, you want to re-use the same fragment for an out-of-band swap. In that case, I would like to dynamically add hx-swap-oob="true" to the fragment when using it.
Example syntax
(The th:child-attrappend is obviously a first idea, we could iterate on a different/better name)
While working on an htmx + spring project myself, i run into the same need; while searching i found issue #716 which i belive asks for more or less the same thing. I think having a new attribute that mimics the replace but allows to add new attributes on top, as suggested in 716, would be a nice solution.
EDIT:
I should also add that at the moment as a workaround im running the following attribute on the fragment: th:attr="hx-swap-oob=${isSwapOob!=null && isSwapOob}?true"
This way i am able to set a flag isSwapOob in the model and control the optional attribute when the template is rendered.
The use case i am looking for is being able to define a component only once and use it for the first load, the standard targeted swaps and oob swaps, without having to add the conditional attribute and specify the flag before every render.
I would like to have a block that allows to add extra attributes to the top-level element of an inserted or replaced fragment. I see 2 use cases for this:
class
attributes to style the SVG.hx-swap-oob="true"
to the fragment when using it.Example syntax
(The
th:child-attrappend
is obviously a first idea, we could iterate on a different/better name)If the
myfragment
looks like this:Then the rendered result should be:
SVG example
With an SVG, it could be similar:
would render as:
Current alternative
I now use multiple almost identical fragments to work around this, but I would love to be able to avoid this.
The text was updated successfully, but these errors were encountered: