Do you send just a full page and select oob elements from it?

if yes, I would say, that you should send these elements as normal oob elements from the server, instead of specifying it in the form

or, just swap an entire page

yep, what are you trying to achieve?

I have a page, on any click I want to swap these elements (in red)

It's working pretty well, no problems. But I thought maybe having this large select-oob is too much.

Some clicks require less swap, some more. When I was just starting the project, I was writing custom select-oob for every button. Over time I saw that it's very error-prone. I have to remember to keep select-oob in sync with what the server actually returns. So to improve code robustness, I came up with this approach: - Write single select-oob at the top, mentioning everything that I may want to swap on the page. - Send specific pieces from the server depending on the endpoint. That way the code is very robust, I don't have to worry about writing select-oob for every fking button.

html
<form hx-select-oob="{{const.stTableSwapOob}}" script="init noEnter(me)">

So this is just an annoyance, nothing more.

I just got a real problem, when using

morph:outerHTML

, the swapped element just disappears. When using regular

outerHTML

, it works well. So I'm debugging htmx source for few hours already, I found this line that removes the node:

js
oobElement.parentNode.removeChild(oobElement);

I'm not sure what is the contract between morph extension and the htmx core. Seems like extension is supposed to insert the node into the DOM, but I don't know how to fix this. Anyone can show me the direction how it should work?

My thinking here is, your server already knows which elements should be swapped

{{const.stTableSwapOob}}

, and it also has all the data that's gonna be swapped. Instead of having it selected by

hx-select-oob

on the page, I would just use knowledge of the server and respond

html
<div id="st-colors-search" hx-swap-oob="true">...</div>
<div id="st-impressionss-search" hx-swap-oob="true">...</div>
<div id="st-cpcs-search" hx-swap-oob="true">...</div>
...

this way you don't need to care about server response in your client-side selector at all

Hm, I didn't know that I could just do

hx-swap-oob="true"

That's cool, thank you @ripe-action-67367

The only thing i'm not sure about is potential target errors

Though it would require the templates to know whether they should add

hx-swap-oob

attribute or not

Like, I don't remember what the behavior is with OOB

May require testing

Yeah I'm trying to make it work now, getting frustrated a bit

The template should know which fragments to render, and the ones that should be swapped OOB should probably always set

hx-swap-oob="true"

morphing problems sounds like something that needs additional investigating

After applying hx-swap-oob="true" as you just said, it works!! 🔥

So instead of

hx-select-oob

I have to use

hx-swap-oob

with morphing

Fk, I need to write my own htmx to understand how it works

Very frustrating when I don't quite know who is wrong: is it the core wrong or extension?

I believe, hx-select-oob is relatively recent addition

So I think it's just a bug

htmx 2.0 is on the horizon, sooooooooo

I'm all in to help

Because I want to own my dependencies. Now I feel little horrified. If I stumble on bug, which I should be able to fix in 5 mins, and I waste 2 hours on it with zero progress

For 2.0 I would vote for zero inheritance. I want to see the full description of behavior on a single node. Now I need to scan everything to the top with my eyes. And my eyes are not compiler.

Inheritance is one of the ways to achieve DRY, I understand that. But it's not the only way. We can just use a variable in template. Done.