Next.js: renderToHTML with getServerSideProps send response instead of return html from 9.3.1

[superkoh]

Bug report

Describe the bug

when upgrade from 9.3.0 to higher version, pages with renderToHtml direct send response instead of html. it work correct when using getInitialProps.

Expected behavior

rendertohtml should always return html instead of send response

[timneutkens]

A complete reproduction is missing, please provide one.

[ngdnghia28]

related to: https://github.com/zeit/next.js/discussions/11525

[visum]

Reproduction repo: https://github.com/visum/next-renderToHTML-test

[superkoh]

@timneutkens , as @visum provided. i have the same issue like him

[leanazulyoro]

The problem as stated in the title is that the method renderToHtml is sending the response, not just rendering the HTML. I agree that the method should return the html, ence it's name.
In the meantime, I ask:
https://github.com/zeit/next.js/blob/canary/packages/next/next-server/server/next-server.ts#L1009-L1015
What if the method returns the html after it's sent? we would need to remove the line 1014 in next-server.js. I tryed that and it works good enought to cache the response and make this work again

[na-ji]

In case it's not clear, another complete reproduction: https://github.com/zeit/next.js/tree/canary/examples/ssr-caching

[visum]

The problem appears to be in renderToHTMLWithComponents, which has a number of cases where it calls sendPayload instead of returning the HTML. There are a lot of cases in there and I'm having a hard time sorting through them all, but adding getServerSideProps to a page apparently triggers one of those cases.

Given that renderToHTML depends on renderToHTMLWithComponents, seems like the latter should always return HTML and let its caller handle sending the response. The name renderToHTMLWithComponents wouldn't suggest to me that it does anything more than render the HTML and return it.

[Timer]

This is the expected behavior, as pages powered by getServerSideProps must control the entire request lifecycle, including caching headers. This is necessary to prevent user-specific information from leaking into the application. Please open an issue for the specific use case you're looking to accomplish by getting the HTML response!

[visum]

It makes sense that a page using getServerSideProps needs more control over the request lifecycle, and in fact setting caching headers is one of the reasons I use it. However, I'm not following how that influences where Next.js sends the response back. The sending of the response is the part of the lifecycle that the page itself doesn't handle.

The specific use case is one that the existing documentation and examples seem to indicate should be possible using renderToHTML - a custom caching mechanism. If I ask Next.js for the HTML and it sends the response (and doesn't give me the HTML), I don't have an opportunity to cache the page. For a page using getServerSideProps because it can't be statically optimized, this is especially important.

At the very least, the API could make more sense. renderToHTML sounds like it should return HTML.

[Timer]

renderToHTML is a private API that's not documented, however, we knew some users were relying on it so we didn't break any existing behavior (with getInitialProps). The new lifecycles cannot return the HTML for further processing.

I've opened an issue to remove all usage of renderToHTML from our examples:
https://github.com/vercel/next.js/issues/14737

These examples will be updated with the appropriate (public API) approaches.

---

Reiterating above:

Please open an issue for the specific use case you're looking to accomplish by getting the HTML response! We're happy to entertain use cases.

[P233]

@Timer My current project heavily relies on the renderToHTML method to cache the dynamically generated pages which grab data from both a headless CMS and a regular database. The caches live 24 hours to speed up the loading speed and reduce the number of API requests. It works pretty well, but we have to stay with the next version 9.3.0. Please provide an alternative recommended way for SSR caching :)

[ycscholes]

@Timer My current project heavily relies on the renderToHTML method to cache the dynamically generated pages which grab data from both a headless CMS and a regular database. The caches live 24 hours to speed up the loading speed and reduce the number of API requests. It works pretty well, but we have to stay with the next version 9.3.0. Please provide an alternative recommended way for SSR caching :)

So does our project

[P233]

After carefully reading the RFC: Incremental Static Regeneration, I believe we will switch to the Incremental Static Regeneration solution later.

Sorry for polluting this thread!

[jack-pallot]

If renderToHTML potentially breaks existing functionality, or isn't the intended behaviour of the function, then it might be better to create a new one like getStaticHTML instead specifically for this use case. It's unfortunate that the renderToHTML name is already taken, but if it's no longer in example code it shouldn't cause confusion going forward.