print: Consider reverting loading content via page.goto()
Consider to revert commit https://github.com/ecamp/ecamp3/pull/3024/commits/9debca09f32fb91aa4671a0cc3b80e29c3798d50 (merged with PR #3024)
Why was this implemented in the first place?
Previously, we used nuxt.renderRoute to compile the HTML and then load it to browserless via page.setContent. Latter has some important caveats. If the HTML is loaded via setContent contains external content (CSS, fonts, images), they are loaded via separate network calls and awaited for ({ waitUntil: 'networkidle0' }). This works well for content on external resources (google webfonts, anything on a CDN) but fails for relative paths (see for example https://github.com/puppeteer/puppeteer/issues/4526).
Nothing that is unsolvable, but it can create strange and difficult to debug behavior for the developer (e.g. resources displaying properly when hitting Nuxt but not included in PDF). Happened to me with MDI-icons, which were served as separate assets. Fixed this by using @mdi/js instead of @mdi/font, but it could happen with any other resources, too.
Using page.goto creates a cleaner developer experience, as it does exactly what a developer is doing when hitting Nuxt via browser.
Issues with the new page.goto method
- Cookies have to be passed to browserless (as discussed already in the PR). This could be a security issue, if we want to use the cloud version of Browserless.
- A browserless chrome session is launched already at the beginning and utilised while data is fetched from API and HTML compiled in Nuxt. Assuming that the number of parallel chrome instances is a scarce resource, the previous method would be better, because a session is only launched for the actual PDF printing and not for the data fetching + HTML compilation.
Potential solutions
- Previous method and make developers aware, that relative resources need to be avoided
- Make a
page.gotocall to an empty file on the nuxt server to populate the url (see https://stackoverflow.com/a/62593436) before usingsetContent
@usu is this still an issue?
One year stale -> close
And seems to be a page.goto again: https://github.com/ecamp/ecamp3/blob/35542151d204dba0b408755723a000d78a9dc5d1/print/server/api/pdf.js#L110
And seems to be a page.goto again:
Yeah, currently it is page.goto. It was nuxt.renderRoute previously (before PR #3024).
In the meantime we have upgraded to Nuxt3, and in Nuxt3, the nuxt.renderRoute method is either not supported anymore or at least not documented (https://github.com/nuxt/nuxt/issues/26378). So I'm fine to close and take up again, if we believe we want to look into it in again.