[sequoia]

I can't really understand what you're describing. You have form on left & results on right, but you're requesting the new form state & re-rendering the form HTML on each request? Why? My naive understanding is that you could use something like hx-target to have the response to the form submissions update only the results area & the form should not need rerendered at all.

Why does the form need rerendered on a per request basis? HTML/Browser already tracks the current form state.

[james2doyle]

Because the form changed based on the selections you made. Like facet search.

Say you have a clothing store listing page and you filter for only "Shirts". Well, the filter that has "Material" might remove (or disable) the option for "Denim" because that is only for "Pants". So that state needs to be computed some where. My thought was, "Ok, refetch the whole thing with the updated options within the form (disable options that can’t be combined together) + the product results for those filters". But that was just a lot of HTML to ask for after each change.

So decoupling it so that the form never refetched, just the results, made it a lot snappier. But you still have the form state issue where you want to update the options based on selections. So the form became a little Alpine data component and the results stayed as an HTML partial.

[tored]

Did you try out-of-bound swap (oob) in HTMX? With that you can update any element on page, e.g. three different form elements changed due to <select> change, request returns only these three form elements with oob selectors and keep the rest of the form intact.

https://htmx.org/attributes/hx-swap-oob/

[sequoia]

Ah OK, so you had a level of dynamic behaviour in the form itself that warranted an applet/data component for the form. I can see how HTMX would not help with that.