Client-side printing with Vue

[carlobeltrame]

In a nutshell: Replaces React with Vue 3, but keeps the client-side printing capabilities of react-pdf. It looks and feels exactly like the existing react-pdf implementation, but is implemented using Vue components instead of React JSX files.

How does this work?

React-pdf consists of several modules:

• @react-pdf/renderer is a React renderer which takes a React component structure as input and produces a description of the PDF as a JS object as the output
• @react-pdf/layout takes this object as input, and uses yoga (a JS flexbox implementation which is commonly used in React Native) and some other magic to calculate the dimensions of all elements, and writes the dimensions into the object.
• @react-pdf/render takes the object with dimensions, and translates it into instructions for pdfkit (a low-level PDF creation library)
• There are some other modules which are used by layout and render, which aren't important for the big picture

Only the first module (@react-pdf/renderer) actually has anything to do with React. All the other modules are framework-agnostic.

This PR adds a Vue 3 custom renderer which does the same as @react-pdf/renderer does, but with Vue 3. There have been several attempts at similar renderers documented on the internet [1] [2], although none of them went far enough to be really practical.

The biggest hurdle I had to overcome was that we cannot install Vue 2 and Vue 3 alongside each other in our frontend. For this reason, I created a new separate pdf module as a Vue 3 project. This module is built using vite build --watch whenever some PDF code is changed, and the resulting output file is imported in our normal frontend code. The bundled pdf module code is ~400KB and is typically rebuilt within less than a second. This way, we can develop with hot module reloading on the PDF preview.

Additional features

• We can write more CSS-like styles in custom <pdf-style></pdf-style> blocks in the .vue files
• Works seamlessly in web workers, because the core of Vue 3 (unlike Vue 2 and React) does not make any assumptions about the context it is run in
• Some convenience improvements over react-pdf (e.g. not all text has to be strictly wrapped in <Text> tags, global helpers such as this.$date or this.$tc or this.api are more natural to use in Vue than in React/JSX)
• The renderer code potentially could become a separate NPM package in the future, or be integrated into the react-pdf repository
• This approach with separated component structure and PDF rendering lowers our vendor lock-in a little. E.g. http://pdfmake.org also uses a declarative document structure object and renders a PDF using pdfmake.
• While I was at it, I implemented similar layout and typography improvements like the ones we introduced in nuxt print in Improve print nuxt design #3577

Open TODOs

• Auto-remove optional display: flex statements during compile time (flex is the default display in react-pdf) not doing that for now, to avoid cascading style issues
• Move prepareInMainThread to a separate entrypoint so the fonts aren't loaded in the main thread
• Disable v-for key warning and remove all :key attrs
• Remove everything related to react
• Add some (dummy) tests with vitest
• remove demo code
• Fix frontend test setup
• Try to remove the components in pdf/renderer/components, adjust the htmlToPdfElementMap, and see how that feels for devs

[manuelmeister]

Deployment is generating errors: https://github.com/ecamp/ecamp3/actions/runs/5431444930

[github-actions]

⛔ Feature branch deployment currently inactive.

If the PR is still open, you can add the deploy! label to this PR to trigger a feature branch deployment.

[BacLuc]

LGTM

Thank you very much

[pmattmann]

A few questions for the CoreMeeting:

• Does nodeOps.js need to be complete?
• How big do we estimate the maintenance effort?
• How do we determine if there are additional requirements for nodeOps.js in the future?