Replace xhr with fetch

[koddsson]

Best viewed, commit and commit.

Mostly wanted to drop the text/html; fragment accept header and did that in 6703c3e. This matches <auto-check> which does not check for text/html; fragment anymore. Otherwise cleaned up a few things so it's more similar to the work we've done in <auto-check>. Using fetch and minor things.

[muan]

Mostly wanted to drop the text/html; fragment accept header and did that in 6703c3e.

Can you add more on the reasoning for this change? <auto-complete> needs a HTML fragment to function, like <remote-input>; <auto-check> does not.

[koddsson]

Can you add more on the reasoning for this change?

Apparently nginx doesn't handle spaces in mimetypes so we need to do something here. <auto-check> didn't seem to use it at all so I opted to drop it.

<auto-complete> needs a HTML fragment to function

Could you expand on this? I didn't see any checks that make sure that the content type are text/html; fragment.

[dgraham]

I have the same question as @muan regarding the removal of content negotiation. We need to be able to identify these requests in the server so full error pages and 404 pages are not served in responses. Removing content negotiation in auto-check needs to be revisited as well.

[koddsson]

I have the same question as @muan regarding the removal of content negotiation. We need to be able to identify these requests in the server so full error pages and 404 pages are not served in responses. Removing content negotiation in auto-check needs to be revisited as well.

Yeah, looking at this more I didn't realize that we have this header in so many components already and it seemed to be missing in <auto-check> so I figured it wasn't needed. I'm gonna have to figure out a better solution to this.

I'm still not sure auto complete needs the text/html; fragment content type to function since it doesn't check for it in the code.

[muan]

I'm still not sure auto complete needs the text/html; fragment content type to function since it doesn't check for it in the code.

What I meant is that the element needs a HTML fragment response, and users of the element needs to know that somehow. This is done properly through content negotiation. Content negotiation is thus essential because the element requires this specific type of content to do its primary job; otherwise, apps can be sending back a JSON string because the element did not ask for the right thing, and the element wouldn’t work.

I view “asking for the right thing” as the element’s responsibility, especially considering all the troubles we’ve had with <include-fragment> not asking for the right thing and requiring us to add an accept attribute.

<auto-check> on the other hand does not use the response content, so I’d argue content negotiation isn’t essential.