We generate the HTML for a document in two steps: First, we generate the body (i.e. everything under `<div id="__next">`). Then we generate the rest of the document and embed the body in it.
This doesn't work when the body is a stream, because React can't render the body for us unless we buffer it, and buffering it means not streaming. This PR takes the existing approach for AMP and uses it for all scenarios: instead of rendering HTML, we just render a placeholder that we can replace with HTML later. This will be used in a follow-up PR to let us know where to concatenate the body stream.
I also used the opportunity to split out `HtmlContext` from `DocumentProps`, as these will not be the same thing with functional document components.
Currently there is a lot of mutation in the Next.js Server and the checks for Locale are directly coded in the general request handler. Ideally, we should have a function where we just pass the request input (url + headers + config) and generate a bunch of metadata that analyzes it generating all metadata we might require for both the URL and i18n + basePath information.
This PR brings:
- A new parsing function `parseUrl` that joins parsing an absolute/relative URL into a data structure compatible with the Node parsing output but missing redundant properties.
- A wrapper `parseNextURL` that extends `parseUrl` analyzing `i18n` and `basePath` based on the provided configuration, url and headers. This function is pure and stateless so it can be used outside of the Next.js context.
- Types improvements and reuse.
- Refactors `next-server.ts` request handling using the above mentioned functions so that the code there just apply effects to the `req` object and the `parsedUrl.query` leaving the code much more straightforward.
- Refactors `getRouteRegex` decomposing in two different functions where `getParametrizedRoute` can be used to retrieve the serializable data that is used to generate the Regex.
