Support non-blocking rendering (Node/Web Workers)
See original GitHub issueDescribe the bug React PDF rendering hogs the main thread on a Hapi web server, blocking other operations, e.g. HTTP responses and resulting in HTTP 500/503 errors
To Reproduce
Render a document to PDF by streaming ReactPDF.renderToStream
to Node’s HTTP response (which takes >5000ms) while also trying to handle lots of normal incoming HTTP requests 🤣 (I can provide a reproducible sample if needed)
Expected behavior
Ideally, ReactPDF.renderToStream
would optionally return a Promise resolving to a stream that didn’t block the main thread. This could be by delegating the actual PDF creation to another thread, like in a Worker thread in Node or a Web Worker in the browser. Although Node seems a higher priority right now, it seems it would be relatively trivial to code for both. We could then stream the PDF back to the calling thread.
I have started working on a solution along these lines but wanted to see if this sounds like a good approach to take. Let me know what you think @diegomura and other contributors.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:11
- Comments:7 (4 by maintainers)
Top GitHub Comments
I’ve successfully used a web worker that uses
react-pdf/render
to generate a multiple PDF documents in a batchHere’s how that looks like
web.worker.js
ExportReports.js
If you want to preview the PDF you can use
URL.createObjectURL(zipBlob)
and use the created url in aniframe
It should be possible to have this implemented in
react-pdf/renderer
, but in the meantime this can serve anyone who deals with large PDFs that cause UI freezesHello, is it this non-blocking rendering is resolved?