You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think one way of expanding the practical capabilities of react-pdf without expanding the public API much at all would be to expose a renderer explicitly intended for custom multi-pass rendering operations, where a consumer of react-pdf could run just the layout step on a component tree identical to any other they would call a public render method on, and observe the results by passing in something stateful through props or context see the pageTracker example in #1210.
The reason I propose to have a separate renderToNull for this purpose is that while some use cases (such as rendering a table of contents or index) would only require a single additional pass, others (such as cross references which include page numbers whose width could change text flow) could potentially require conditionally re-rendering until none of the observed values change. renderToNull could make these passes less expensive computationally by skipping a few things:
The most obvious one is that it would neither instantiate nor make any calls to the pdfkit step of rendering, as no direct output is expected, only the caller's intended side-effects.
We could also discard any style props which don't have the potential to affect pagination (essentially the same as those which don't cause reflow in screen media: colors and background colors, background images, outlines, box shadows, transforms, etc), and avoid fetching any assets whose dimensions are already defined across both dimensions.
Lastly, the type of the renderer could be exposed to the component tree through context so that users could manually opt out of expensive operations they know will not cause reflows.
Implementation-wise, this would allow users to achieve many of the same things as they would having a stable and public API for react-pdf's internal representation of paged media layout for the intermediate stage between yoga layout and pdfkit construction, while deferring the need to finalize and document such a format.
Thanks for the awesome library and let me know what you think of this idea!
Addendum: Of course the intermediate format as an output option is more powerful in the long run, as multiple output formats could share a single layout pass through composition. But I thought as escape hatches go this would be a pretty useful one.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I think one way of expanding the practical capabilities of react-pdf without expanding the public API much at all would be to expose a renderer explicitly intended for custom multi-pass rendering operations, where a consumer of react-pdf could run just the layout step on a component tree identical to any other they would call a public render method on, and observe the results by passing in something stateful through props or context see the
pageTracker
example in #1210.The reason I propose to have a separate
renderToNull
for this purpose is that while some use cases (such as rendering a table of contents or index) would only require a single additional pass, others (such as cross references which include page numbers whose width could change text flow) could potentially require conditionally re-rendering until none of the observed values change.renderToNull
could make these passes less expensive computationally by skipping a few things:The most obvious one is that it would neither instantiate nor make any calls to the pdfkit step of rendering, as no direct output is expected, only the caller's intended side-effects.
We could also discard any style props which don't have the potential to affect pagination (essentially the same as those which don't cause reflow in screen media: colors and background colors, background images, outlines, box shadows, transforms, etc), and avoid fetching any assets whose dimensions are already defined across both dimensions.
Lastly, the type of the renderer could be exposed to the component tree through context so that users could manually opt out of expensive operations they know will not cause reflows.
Implementation-wise, this would allow users to achieve many of the same things as they would having a stable and public API for react-pdf's internal representation of paged media layout for the intermediate stage between yoga layout and pdfkit construction, while deferring the need to finalize and document such a format.
Thanks for the awesome library and let me know what you think of this idea!
Addendum: Of course the intermediate format as an output option is more powerful in the long run, as multiple output formats could share a single layout pass through composition. But I thought as escape hatches go this would be a pretty useful one.
Beta Was this translation helpful? Give feedback.
All reactions