React PDF komplizierte Beispiele ausprobieren

[carlobeltrame]

• [x] Picasso

• [x] ContentNodes

[carlobeltrame]

Learnings bisher:

• Hot Module Reloading habe ich mit Web Components nicht zum laufen gebracht, daher habe ich den Middleman Web Components entfernt und direkt die React-Komponente in Vue eingebunden. Ist gar nicht so aufwändig, besonders da wir keine Slots und Events brauchen.
• Wenn man die React-Komponenten via '@/components/...' importiert, funktioniert der Hot Module Reloading (HMR) Algorithmus von Vite nicht, und die Seite wird bei so importierten Dateien immer vollständig neu geladen. Workaround: Immer relative Pfade mit vollständiger Dateierweiterung importieren (in ESLint forcieren?). Aliases funktionieren in Vite nämlich leicht anders: https://github.com/vitejs/vite/issues/279.
• Vertikales "flexGrow: 1" funktioniert nur zuverlässig wenn gleichzeitig "height: 0" gesetzt wird -> ev. Issue bei react-pdf eröffnen wurde anscheinend inzwischen in react-pdf gefixt. Vertikales flexGrow funktioniert derzeit einwandfrei.
• Ich habe das Gefühl es hat tatsächlich ein Memory-Leak: Nach stundenlang offenem Tab ist der Browser abgestürzt und der Memory-Verbrauch auf meiner Maschine schlagartig gesunken. Bei jedem Mal Seite neu laden steigt der Memory-Verbrauch leicht an. Könnte an der nativen Library "Yoga" liegen, welche Flexbox implementiert.
• An react-pdf wird aktiv gearbeitet, einige Issues [1] [2] denen ich über den Weg gelaufen bin wurden im inzwischen veröffentlichten Patch Release gefixt.
• Der einzige Ort an dem ich bisher das Gefühl hatte, ich hätte davon profitiert wenn ich einfach eine Vue Komponente hätte wiederverwenden können, war der User Avatar. Den Code für die Berechnung der Farbe und Initialen habe ich bisher mal dupliziert, aber der könnte ja auch in einem Plain JS File liegen das wir sowohl in Vue wie auch in React importieren können. Alle anderen Komponenten unterscheiden sich sowieso stark von den interagierbaren Komponenten, weil sie statisch und flach sind, und es für das Detail-Layouting im PDF besser ist, wenn der Komponentenbaum möglichst simpel ist. Ein Beispiel für diesen Unterschied ist die Klickbarkeit von Blöcken im Picasso: Zwar müssen Blöcke in beiden Ansichten grob gesagt "klickbar" sein, aber beim Web-Picasso haben wir dafür Doppelklick, und die "Links" müssen an komplett unterschiedliche Orte führen. Ich glaube wenn wir das alles basierend auf gemeinsamen HTML-Komponenten machen würden, würde viel unnötige Komplexität entstehen.

Einige übliche Konsolenfehler während der Entwicklung, und wie man sie lösen kann:

• xyz constructor: 'new' is required -> ein Import von xyz vergessen (z.B. Text oder View müssen aus dem pdf Import gefischt werden: const { View, Text } = pdf)
• node.box is undefined -> Irgendwo im Template ist Text der nicht in einem <Text> Element gewrappt ist
• node.lines is undefined -> Text wurde während dem Layouten falsch behandelt, sollte mit react-pdf 2.0.21 eigentlich behoben sein. Das kann auftreten wenn man mit Text und height / width spielt, oder wenn man Text-Elemente direkt als Flex-Items benutzt (oft geht das aber ohne Probleme).
• Styles funktionieren nicht / werden nicht angewendet / haben keine Wirkung -> Hast du wo nötig den Spread-Operator verwendet? Korrekt: style={{ ...myStyles, backgroundColor: 'red' }} oder style={ myStyles }. Falsch: style={{ myStyles, backgroundColor: 'red' }}

[carlobeltrame]

Ich habe noch Activity Rendering implementiert: react-pdf.pdf

Nochmals zusammenfassend meine Notizen wie sich das Entwickeln angefühlt hat (ich plane, genau dasselbe auch noch mit Nuxt zu machen, um den direkten Vergleich zu haben):

Developer Experience und Debuggability

• Live reloading funktioniert sehr schnell, es fühlt sich meistens angenehm an vom Tempo her wie lange ich auf eine Änderung warten muss
• Live reload kann mal "kaputt" gehen wenn man zirkuläre Imports hat, oder Imports-Ketten die an mehreren Orten beginnen. Ist immer lösbar, aber oft nicht gerade durchsichtig wo das Problem liegt. Solange es "kaputt" ist wird einfach jedes Mal die Seite neu geladen, was halt einfach etwas länger dauert. Man kann weiterentwickeln, aber es ist weniger angenehm. Das erste Mal als mir das passiert ist musste ich den Vite Code lesen um zu verstehen unter welchen Umständen Live Reloading deaktiviert wird.
• Um Layout-Probleme zu debuggen kann man auf den React-Komponenten das Prop debug={true} setzen, dann wird auf das Rechteck drauf halbtransparent farbig eine Visualisierung von Margin, Padding und Inhalt und Mittelpunkt gerendert, und die Abmessungen des Rechtecks in pt hingeschrieben. Das ist immer wieder mal sehr nützlich, da man nicht einfach die Vue oder React Dev Tools aufmachen kann, weil die Komponenten nicht in ein DOM gerendert werden.
• Fehler kommen als Browserkonsolenfehler und sind meist unverständlich, an gewisse davon gewöhnt man sich, siehe letzter Kommentar
• Selten mal zwischendurch ist ein Refresh nötig, wenn ein Konsolenfehler nicht weggehen will
• Das Memory Leak kann während der Entwicklung in den Weg kommen, es hilft dann jeweils das Browser-Tab ganz zu schliessen und ein neues zu öffnen. Ich musste das glaube ich 2 oder 3 Mal machen während der Entwicklung des Renderings von Activities und ContentNodes

Wartungsaufwand

• Um React in Vue zum Laufen zu bringen musste ich ja eine Adapter-Komponente schreiben. Diese müsste man potenziell in Zukunft up-to-date halten wenn man React aktualisiert nicht mehr nötig, ich habe inzwischen Komponenten für Print Preview und Print Download Button in Vue implementiert. React wird somit nirgends mehr zum HTML rendern verwendet, und diese Adapter-Komponente entfällt.
• Damit react-pdf funktioniert in unserem vite-setup habe ich noch ein Polyfill gebraucht das von jemandem in einem Issue vorgeschlagen wurde. Ist potenziell auch ein Schwachpunkt dieses Techstacks, aber bisher scheints noch weiterhin aktiv unterhalten zu werden. Ausserdem musste ich dieses Polyfill inzwischen für Web Workers (Background Thread, siehe Kommentar weiter unten) selber noch erweitern, darum verstehe ich was gemacht wird, und es ist ziemlich simpel.
• Im Deployment und am lokalen Docker-Setup musste ich überhaupt nichts ändern, das hat einfach so out of the box funktioniert. Infrastruktur-Aufwand gleich null, dafür begegnet man Problemen eher mit mehr Code. Das ist mir persönlich halt sympathisch.
• Fehler auf Produktion kommen vermutlich als die genau gleichen Konsolenfehler wie lokal im Sentry an, was beim Reproduzieren hilft

Features

• Im Allgemeinen ist das Style-System natürlich weniger mächtig wie vollwertiges CSS. Aber genau die Styles die in einem statischen Dokument nötig und nützlich sind sind natürlich vorhanden. Es fühlt sich so an als gäbe es weniger verschiedene Lösungen für ein gegebenes Problem, aber bisher habe ich noch für jedes Problem eine Lösung gefunden.
• Tabellen die sich in beiden Richtungen komplett dem Inhalt anpassen sind nicht möglich. Aber wenn man für einen Use Case entweder die Breiten oder Höhen fixieren oder als Prozentangaben setzen kann gehts. Für Aktivitäten und die ContentNodes die wir bisher haben hats gereicht.
• Die Dokumentation der Styles ist manchmal sehr dürftig, z.B. textOverflow. gap in der Flexbox ist gar nicht unterstützt.
• Seitenumbrüche funktionieren von Haus aus perfekt (soweit ich bisher sehe), auch mit mehreren parallelen umbrechenden Elementen (siehe hochgeladenes PDF oben mit zwei Storyboards nebeneinander). Das ist meiner Meinung nach wirklich der grosse Pluspunkt dieser Lösung, und ich bin gespannt herauszufinden wie gut das mit paged.js geht.
  • Man kann sagen "diese Box darf nicht über mehrere Seiten hinweg gehen"
  • Man kann auch explizit sagen "hier eine neue Seite beginnen"
  • Bilder brechen standardmässig nie über zwei Seiten hinweg, Text, View und Link standardmässig schon
  • Orphan & widow protection für Text, plus ein ähnlicher Mechanismus für alle Komponenten :partying_face:
  • Dieser Mechanismus kann aber manchmal zu langen (infinite?) Loops beim Rendern führen wenn man zu grosse Werte verwendet...?
• Kann von Haus aus keinen RichText rendern
  • Konnte ich mit einem HTML Parser lösen der den RichText liest und in React-Komponenten gemäss meinen Instruktionen übersetzt
  • Alternativ könnte man vermutlich die React-Variante von TipTap verwenden, in einem Read-Only Modus. Das ist von TipTap auch so vorgesehen, als primärer Weg, Rich Text wieder anzuzeigen.
• Je nach Schriftart ist das PDF nicht richtig selektierbar / kopierbar / durchsuchbar https://github.com/diegomura/react-pdf/issues/629 https://github.com/diegomura/react-pdf/issues/915
  • Wenn ich keine Schriftart angebe nimmts glaube ich Arial oder Helvetica oder so, aber Bold funktioniert dann nicht
  • Mit OpenSans funktionierts aber einigermassen, und die ist sowieso besser für Print optimiert als Inter
• Das PDF wird anscheinend tatsächlich im Main Thread gerendert, und zwar auch beim DownloadLink sobald dieser angezeigt wird. Es gibt aber schon einen POC wie man das auch in einem service worker machen kann. Dieser POC müsste sicher noch verbessert werden, indem statt der undokumentierten pdf() Funktion der React Hook usePdf verwendet wird Rendering im Web Worker ist inzwischen implementiert
• Dinge wie Schriftgrösse und Seitenränder könnten wir den Usern als präzise Konfigurationsoptionen anbieten, um Ringbücher und A5-Druck besser zu unterstützen.

[carlobeltrame]

Ich habe hier noch ausprobiert, das PDF beim Download-Button in einem Web Worker (separater Thread) zu generieren, um bei grossen PDFs das UI nicht zu freezen. Nach einigem Gepröbel habe ichs hinbekommen. Caveat: Für Vuex Daten und Übersetzungen können nicht mehr einfach $tc und this.api an React weitergegeben werden, weil der separate Thread nur via Promises mit dem Main Thread kommunizieren kann, aber man in React Komponenten nicht einfach Promises "awaiten" kann: Die Annahme ist, dass die Komponente auch wissen muss, wie "loading" State gerendert werden soll. Beim PDF Rendern wollen wir aber nicht zuerst im "loading" State rendern, sondern nur ein einziges Mal, und allfällige Daten müssen blockierend zusammengesucht werden. Das bedeutet, dass wir vermutlich den Vuex State und die verfügbaren Translations als plain JS-Objekte "serialisiert" an den Worker Thread übertragen müssen, und dort eigene limitierte Instanzen von hal-json-vuex und vue-i18n laufen lassen müssen.

Ausserdem ist das Logging aus dem Worker Thread schlechter, und live reload habe ich noch nicht versucht einzurichten. Das machts also etwas schwieriger zum Probleme debuggen. Wenn wir diesen Weg gehen müssten wir vermutlich einen Kompromiss finden, sodass wir während der Entwicklung das PDF möglichst noch im Main Thread mit live reload etc. arbeiten können, aber später das definitive PDF im Background Thread generieren können.

[BacLuc]

Ich habe noch bisschen gemessen Stand 676a63c (mit mehr daten in der db, ohne web worker) Chromium: 01:17 Minuten für 127 Seiten. e5be6187-87c2-4533-b6d3-06e5b5216172.pdf

00:26 für 25 Seiten e12c3ac9-2e95-49df-a508-fd8c7b3eeb7c.pdf

Firefox: Mit Firefox kommt die preview gar nicht...