Should modules really be 'null' if the HTTP status code is not-ok?

[jakearchibald]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script:~:text=response%27s%20status%20is%20not%20an%20ok%20status%2C,-then%20set

Right now, entries in the module graph are set to null (meaning failure) if the status code is not-ok. Is this really the right pattern? Now that we have 'json' and 'text' imports, and maybe soon 'bytes', should we revisit this?

If you made an API request for /some/api/users/jakearchibalf and jakearchibalf didn't exist, the general pattern is to return a 404, but with valid JSON explaining the error. Hiding that valid JSON seems weird for a JSON import.

With 'text' and 'bytes' imports, it's less clear, as developers may not consider the occasional HTTP 500 resulting in a response.

Perhaps we need to extend the import syntax with something like:

import text from 'whatever' with { type: 'text', status: 'any' };

[mkrause]

import text from 'whatever' with { type: 'css', status: 'any' };

Wouldn't this only make sense if the 404 (or other status) also returned CSS? Which would be unusual. The JSON example where both the success and error case return the same type of data would sort of work, but I would think that's the exception?

But also, just getting the data without the status code means I won't be able to unambiguously differentiate between the different cases.

[jakearchibald]

Wouldn't this only make sense if the 404 (or other status) also returned CSS?

Apologies. Copy/paste error. That was supposed to be a text import. I've updated it.

just getting the data without the status code means I won't be able to unambiguously differentiate between the different error cases.

In some cases the response data will offer you more insight than the status code. And definitely more insight than a failed graph.

[vrugtehagel]

Personally I think we should keep rejecting imports whose request returned a non-ok response.

I feel there is a bit of a semantic difference between a request to an API endpoint that returns JSON (regardless of status), and a request resulting from a static JSON import. For these types of API endpoints, it is usually not necessarily expected that the result will be the same throughout the lifetime of a document. On the other hand, static JSON imports, much like JS imports (or text, CSS, etcetera), are (generally) only used to fetch static content. In other words, an API request returns data, whereas import statements import static files. I know this isn't technically true, and you can absolutely break this pattern if you wanted, in either direction, but this is my intuition.

Ultimately I think fetch() is more appropriate for requests whose contents are useful even if the status was non-ok. The use of fetch() is a signal that the server may respond with an error, that that is intentional, and that this is to be handled explicitly.

I'm not opposed to extending the import syntax with status: 'any' to achieve the proposed behavior, but I would oppose intruducing it as the default.

[loucyx]

I'm in the same boat with @vrugtehagel. From my point of view, import should ideally be meant for stuff that's "always there", and if for some reason a file is missing in the import tree, then it's ok for the program to throw instead of having gracious handlers around it like the body of the failed responses (and I say this as a public "throw hater"). If we think something might fail and we have to check, we can use fetch to have full control over the response, or we can use import() if we only want a simple try/catch if the import is gonna fail.

Maybe its just me on this last thing, but I don't even think is great to add status: 'any' because it's adding even more complexity to import definitions that should ideally be simpler than that. It made sense to add support to type for other files that have to "always be there", but adding error request body parsing to every import feels to me like something we "shouldn't need".