Add Response.json() static method to Fetch

[ddbeck]

This is a Baseline 2023 feature, albeit a minor one.

A question here: should we have a fetch group? Or just let this be swept up by fetch snapshots?

[foolip]

I am really on the fence about this addition. I think we'll have a hard time coming up with guidelines for notability that explains why this is a feature but for example MIDIOutput's clear() isn't.

@ddbeck if we had all of the tools to express composite features, subfeatures, feature evolution, etc., that we've been discussing, do you think this would still have its own identifier?

[foolip]

Suggested change

	name: Response.JSON()
	description: The `Response.JSON()` static method creates a `Response` object from a JSON body.
	name: Response.json()
	description: The `Response.json()` static method creates a `Response` object from a JSON body.

[ddbeck]

I am really on the fence about this addition. I think we'll have a hard time coming up with guidelines for notability that explains why this is a feature but for example MIDIOutput's clear() isn't.

I was also on the fence about this one, but we have several other static method features. I think it's only been implied so far, but static methods seem somewhat special. If a static method was a new global method, it'd definitely become a new feature, right?

@ddbeck if we had all of the tools to express composite features, subfeatures, feature evolution, etc., that we've been discussing, do you think this would still have its own identifier?

If we had all of them? No, probably not. I'd probably be OK with this being a later addition on the main fetch feature, unless we had developer feedback that it was distinct (at which point I'd welcome feature composition or other relationships). Single-key features feel like a smell to me. Some probably merit a feature entry (e.g., new JS syntax, new CSS properties, etc.), but I'd prefer to not make them if there's an alternative open to me.

If you like, I can recast this as a later addition comment on fetch and maybe we could spend some time in the first or second week of June to put together a concrete "later additions" proposal (ideally, a PR).

[foolip]

I am really on the fence about this addition. I think we'll have a hard time coming up with guidelines for notability that explains why this is a feature but for example MIDIOutput's clear() isn't.

I was also on the fence about this one, but we have several other static method features. I think it's only been implied so far, but static methods seem somewhat special. If a static method was a new global method, it'd definitely become a new feature, right?

A lot of global methods stand on their own, but some like createImageBitmap() are part of a larger feature. But I would say that whenever a global methods ships in isolation, it's almost certainly a new feature. There could be exceptions in principle, but I don't know of any so far.

Static methods more generally I think we can handle like any other API surface, be it constructors, instance methods, properties, or whatnot. CSS.registerProperty() is the entry point to registered custom properties and part of that feature, AudioEncoder.isConfigSupported() is part of WebCodecs, but others like URL.canParse() shipped in isolation and are either standalone features or "later additions". The tradeoff between when we do what is hard.

@ddbeck if we had all of the tools to express composite features, subfeatures, feature evolution, etc., that we've been discussing, do you think this would still have its own identifier?

If we had all of them? No, probably not. I'd probably be OK with this being a later addition on the main fetch feature, unless we had developer feedback that it was distinct (at which point I'd welcome feature composition or other relationships). Single-key features feel like a smell to me. Some probably merit a feature entry (e.g., new JS syntax, new CSS properties, etc.), but I'd prefer to not make them if there's an alternative open to me.

If you like, I can recast this as a later addition comment on fetch and maybe we could spend some time in the first or second week of June to put together a concrete "later additions" proposal (ideally, a PR).

I think adding this now won't have any long term ill effects, so I'm OK with adding it. But yes, I think it's a good case to figure out as part of a "later additions" model.

[foolip]

Approving to leave the door open to landing this now, or waiting to figure out "later additions". I don't feel strongly enough to make a decision.

[ddbeck]

I'm sitting on this until we get later additions. Switching to draft.

[ddbeck]

@foolip I've redone this as a later addition to fetch. What do you think?

[foolip]

This single entry would be enough I think, but listing a few more doesn't change anything. We'll need some kind of guidance for what people should prefer, however.

[ddbeck]

I was on the fence about this myself, but here's a possible heuristic:

I looked at the first few code samples on the MDN overview page for the feature. On some of the samples, Headers preceded fetch(), so I figured: where's the first place you're likely to hit a non-available feature? That should go in compute_from.

Though I guess now that I've said this, Response could probably be dropped. Feels… impure to leave just one interface out though.

[foolip]

What's wrong with just compute_from: api.fetch?

[foolip]

Yay, dist grouping works!

[foolip]

@ddbeck I changed the name here. I feel like we'll have very few "initial support" features left in the long term, but am not sure what the name guideline should be.

[ddbeck]

Good call on renaming this. Thank you!