more parameters included than before 2.0.0-alpha1 -> 2.0.0 about htmx

[Telroshan]

Note that I am using hx-include here.

Oops, totally missed that 😆
Right, I understand the situation now!
hx-include, as per its doc:

The hx-include attribute allows you to include additional element values in an AJAX request

lets you define additional data to send along your request, but not replace it. So the default behavior is to retrieve all the form's value, then append whatever is hx-included on top of it.

Relevant parts of the codebase:

htmx/src/htmx.js

Lines 3421 to 3422 in 6f83885

	// include the element itself
	processInputValue(processed, formData, errors, elt, validate)

htmx/src/htmx.js

Lines 3432 to 3435 in 6f83885

	// include any explicit includes
	const includes = findAttributeTargets(elt, 'hx-include')
	forEach(includes, function(node) {
	processInputValue(processed, formData, errors, asElement(node), validate)

Actually, what sounds weird to me is that this was working with former htmx versions, which was not expected.

I'm afraid you'll have to find a workaround here, ideas that come to mind:

• Override in JS, in a htmx:configRequest event listener, the request payload to remove the select values you don't want if their associated checkbox isn't checked
• Define a name on your checkboxes, and check in the backend that each select value has its matching checkbox actually checked in the payload
• Don't wrap your elements in a form (meh) so that only hx-include processes values and not the form's standard behavior

I wouldn't suggest the 3rd one at all as it'd be a bit sad to move away from HTML standards for this, and would advise in favor of 1 or 2, depending on your tastes (client logic or backend logic)

[Telroshan]

Hey, I'm not sure I understand the situation here ; are you getting the unchecked checkboxes' name/value pairs on the backend?
Would you mind sharing a screenshot of your request's payload from your browser's dev tools' network tab?

I'm confused as I don't get the same result, see this JSFiddle where I only get the checked checkbox's name/value pair as you would expect

Let me know!

[gregjotau]

re you getting the unchecked checkboxes' name/value pairs on the backend?

Yep. the unchecked checkboxes' name/value pairs are sent to backed, and this was not the case for 1 or even 2.0.0-alpha1.

And this upgrade is the only change to the code, and reverting to 2.0.0-alpha1 fixed it.

Copy as curl below of the request.

--data 'orderNumber=283160SH&SKU1=1&returnType=refund&='

And when upgrading I get, without the checkbox for SKU2 and SKU3 being checked:

--data 'orderNumber=283160SH&SKU1=1&SKU2=1&SKU3=1&returnType=refund&='

curl 'http://127.0.0.1:8080/iframes/submit-return-request' \
-X 'POST' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-H 'Accept: */*' \
-H 'Referer: http://127.0.0.1:8080/iframes/return-request-form?domain=Y&shopifystore=Y' \
-H 'Origin: http://127.0.0.1:8080' \
-H 'Sec-Fetch-Dest: empty' \
-H 'Sec-Fetch-Mode: cors' \
-H 'Sec-Fetch-Site: same-origin' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15' \
-H 'HX-Request: true' \
-H 'HX-Target: submitReturnRequestButton' \
-H 'HX-Current-URL: http://127.0.0.1:8080/iframes/return-request-form?domain=X&shopifystore=Y' \
-H 'X-Domain: X' \
-H 'X-Shopify-Store: X' \
--data 'orderNumber=283160SH&SKU1=1&returnType=refund&='

[Telroshan]

I don't know shoelace at all, but are those values the name/value pairs of the checkboxes, or their what-seems-to-be-associated selects ? I'm asking as I don't see a name attribute defined for the checkboxes but do see one for the selects.
Is shoelace doing any values processing before htmx sends its request?

[gregjotau]

<sl-select class="sku-quantity"
                   th:label="#{return.quantity}"
                   th:name="${item.sku}"
                   th:required="${lineItems.size() == 1 ? 'required' : null}"
                   th:value="${item.quantity == 1 ?  '1' : ''}"
        >

name=SKU
value=1

I expect SKU:1 to be sent if it is checked off.

so yes, it is the associated select of quantity where the name value pair is that I do not want to be sent unless the checkbox is checked off.

But, I think the problem is that since the select has a value htmx still sends sends every name=value pair it finds.

Just a theory: Maybe my code relies for "suboptimal support for web components" and that some added support for web components from alpha1 -> 2.0.0 made it not work as I expected anymore?

Or it might be a bug. At least it is a very crucial change of functionality that I did not expect 😅

[Telroshan]

But, I think the problem is that since the select has a value htmx still sends sends every name=value pair it finds.

Yep, and that's normal! This is why I asked about shoelace ; any input-type that has a name/value pair will be sent in a standard form, unless explicitly disabled, and htmx simply follows along the standard behavior on this.
It's likely that shoelace is doing some internal processing, that maybe doesn't work anymore with htmx 2. The only change I can think of is that we moved to FormData internally instead of the old non-standard plain object to represent the form values.
Though, we implemented this as a proxy object specifically for retro compatiblity so this might not be the culprit, but it's a suspect at least.

From what I see, sounds to me like that's an issue you'd want to solve at the shoelace level, as again the behavior itself is perfectly standard and valid 😕

[gregjotau]

But, I think the problem is that since the select has a value htmx still sends sends every name=value pair it finds.

Yep, and that's normal! This is why I asked about shoelace ; any input-type that has a name/value pair will be sent in a standard form, unless explicitly disabled, and htmx simply follows along the standard behavior on this. It's likely that shoelace is doing some internal processing, that maybe doesn't work anymore with htmx 2. The only change I can think of is that we moved to FormData internally instead of the old non-standard plain object to represent the form values. Though, we implemented this as a proxy object specifically for retro compatiblity so this might not be the culprit, but it's a suspect at least.

From what I see, sounds to me like that's an issue you'd want to solve at the shoelace level, as again the behavior itself is perfectly standard and valid 😕

Maybe, but one thing though:

hx-include="#orderNumber, [checked] + .sku-quantity, #returnType"

Note that I am using hx-include here. And that it includes [checked] - I think that is the magic that made the unchecked ones not sent. Are you sure that is not a bug that this hx-include is changing which values are sent?

It is standard to send all name=values, but not when I use hx-include, right?