The value of react-pdf is not in "React"

[wkrueger]

What does this lib does better than the others?

1. Building layouts comfortably require a consistent declarative document API. JSX provides a framework for that and added user experience (with typescript etc). Notice that we don't even need React for that kind of consistency, could be any other JSX pragma. Other libs have incosistent, arbitrary and sometimes imperative api (yuck!).

• React-native primitives / familiar CSS adds to that consistency

2. This lib does layout. Most others don't. You have to calculate pixels on other libs, which is huge.

Mostly, the big win here is stitching together JSX, yoga-layout and pdfkit.

I've never used this library in a React project. I didn't choose this lib because it is "reacty". I chose it because of 1 and 2. I even plugged it in Angular, Vue and backend node projects.

Where to I want to land?

• Development should focus on deliver a PDF. As a blob, buffer, dataUrl or whatever. Sometimes I have to dig into source to find those options;
• Any other react-specific front-end UI interactions should be out of scope. Ex: Add a react button, style that button, add a hooks API... Rule of thumb: if you can't do it outside a React frontend, it should be out of scope.

And with that we can easily drop like 50+ issues and focus more on what is really important.

[diegomura]

Thanks @wkrueger !

I 100% agree that the value is not in the React part. Actually (and this can be seen more clearly in the upcoming v2), react plays just a very small role in all the logic related to this library. It just give us a nested JSON object representing our document, it's just the glue that binds together the rendering engine and the markup provided by the user.

And actually I was thinking about this very same thing last night. There is great value on the rendering engine itself, and I feel the "react" part, although helpful for many situations, it might as well filter out many people or use cases. Once the v2 is in place, it would be very simple to have a pdf generation tool that just takes a nested JSON object as argument and produces the same output than react-pdf, but without the React part. I think it can be great since many people just wants a "plain" PDF rendering engine, and as you said, this one provides layout which is a great win.

That's not even considering that it will be also possible to render not just PDFs, but potentially any document you want (images, svgs, drawing in a canvas, even html)

[carlobeltrame]

I agree completely. I am using react-pdf without the react (renderer) part, and it works wonderfully. I have a Vue.js app which creates a document description object out of Vue components, and then I pass this object to the rest of the react-pdf packages:
https://github.com/ecamp/ecamp3/blob/devel/pdf/src/renderer/index.js

Once my whole project is migrated to Vue 3 (which is required for being able to render the Vue.js component tree into a plain JS object), I will be able to extract a small vue-pdf library which should be a drop-in replacement for @react-pdf/renderer.