Document RequestInit as a standalone dictionary

[wbamberg]

Usually we don't document dictionaries as standalone pages, unless they're referenced by several different features or some other exceptional circumstances apply.

I think we should, though, document the options parameter RequestInit, that's passed as a parameter to both fetch() and the Request() constructor.

Duplicating the options parameter, as we currently do (1, 2) has two bad effects:

1. it obscures the symmetry of the Fetch API, which is a very intentional part of its design, in which you can create a request with options or call fetch() with options, or override some of the options applied to an existing Request when calling fetch() and so on.

2. it's inevitable that the copies diverge, which is confusing for people. Are they the same thing not? When there are subtle differences between the copies, do they reflect real differences that readers need to pay attention to?

So I think we should have a new page for RequestInit and refer both the fetch() page and the Request() page to it.

[Josh-Cena]

Would it be less confusing if we just say:

- `options`
  - : See [`fetch`](...#options) for an exhaustive list of properties.

For Request()?

[wbamberg]

I would be OK with that as well. I just don't want the current two-copies situation.

[Ashish-CodeJourney]

[queengooborg]

Hi there, it appears that your content is AI generated. Please note that posting a verbatim response from an AI in a discussion is unhelpful, and in some cases, disruptive.

Please refer to GitHub's policies about AI generated content: https://docs.github.com/en/site-policy/github-terms/github-community-code-of-conduct#reasonable-use-of-ai-generated-content

[Rumyra]

I'm ok with making a separate page in this instance - I really don't want it to be the norm, but looking at the dictionary in this case and agreeing with point 2. @wbamberg - it would be clearer on a separate page 👍

[wbamberg]

-> mdn/content#34437