Bitte fügen Sie Unterstützung für systemjs hinzu.
Ich würde weitere Informationen anfordern, da keine Beispiele angegeben sind. Und ich denke, Browserify funktioniert derzeit mit pdfjs-dist (mit einigen Modulausnahmen).
Hier ist das häufigste Beispiel für die Verwendung von systemjs:
npm install jspm
jspm init # use defaults
jspm install pdfjs-dist
index.html
<!DOCTYPE html>
<html lang="en-us">
<head>
<meta charset="utf-8">
<title>Title</title>
</head>
<body>
<script src="jspm_packages/system.js"></script>
<script src="config.js"></script>
<script>
System.import('src/app.js');
</script>
</body>
</html>
src / app.js.
# ES6 syntax
import pdfjs from 'pdfjs-dist';
# expected pdfjs to be a window.PDFJS object
Danke zum Beispiel
In früheren Versionen konnten wir jspm shim verwenden, um pdfjs zu verwenden.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
Nach der Aufnahme von Node-Sure können wir dies jedoch nicht (Node-Sure scheint nicht mit system.js kompatibel zu sein).
Tatsächlich ist dies eine Anfrage für jspm packager, nicht speziell für Systemjs Loader.
Dh es wäre in Ordnung, wenn es jspm shim erfordern würde, aber füge keine inkompatiblen Änderungen wie Node-Sureise hinzu.
@ Vanuan
Folgendes in der Datei config.js umgeht das Problem:
"npm:[email protected]": {
"process": "github:jspm/[email protected]",
"node-ensure": "empty",
"entry?name=[hash]-worker.js": "empty"
},
(leer ist eine empty.js-Datei ohne Inhalt)
Ein ähnlicher Hack ist für Browserify erforderlich
Jetzt Problem: pdf.worker.js wird zweimal geladen, das ist ein Problem, das durch request.ensure () im Webpack behoben wurde. Das Laden der Datei './pdf.worker.js' muss verboten werden, bis sie wirklich benötigt wird.
Ich dachte "PDFJS.disableWorker = true;" löst das? Ist es nicht?
Wenn Sie System.import('./pdf.worker')
, wird nur eine http-Anfrage ausgegeben.
Oder sogar System.import('pdfjs-dist/build/pdf.worker')
Gibt es einen bestimmten Grund, warum node-ensure
verwendet wurde? Ich glaube, dass System Loader in Webpack gut funktioniert.
"PDFJS.disableWorker = true;" ist keine Option, da wir die PDF-Verarbeitung auf den anderen Thread verschieben möchten. Wir wollen keine miese Lösung für Bibliotheksbenutzer vorschlagen, oder?
Nun, ich würde eine miese Lösung vorziehen als gar keine Lösung. Für meinen Anwendungsfall ist sogar das Einfrieren einer Seite von 1 Sekunde in Ordnung.
Ich würde mich freuen, wenn Sie eine bessere Lösung finden.
Gibt es einen bestimmten Grund, warum Node-Sure verwendet wurde?
Wenn Sie sich genau ansehen, welche Beispiele / webpack / produziert:
pdf.js yury$ ls -la build/webpack/
total 2384
drwxr-xr-x 5 yury staff 170 Dec 22 15:20 .
drwxr-xr-x 34 yury staff 1156 Dec 22 10:08 ..
-rw-r--r-- 1 yury staff 546125 Dec 21 16:35 1.bundle.js
-rw-r--r-- 1 yury staff 546463 Dec 21 16:35 9d074593b165291f150e-worker.js
-rw-r--r-- 1 yury staff 122796 Dec 21 16:35 bundle.js
"bundle.js" ist die Hauptdatei, die geladen wird (das heißt, sie bringt die Benutzeroberfläche nach 122796 Bytes und initialisiert sie - schnellerer Seitenstart). "9d074593b165291f150e-worker.js" ist ein Worker, der die Logik ausführt und die Benutzeroberfläche auf langsamen Geräten nicht sperrt. Der Teil "1.bundle.js" wird nur geladen, wenn disableWorker ausgelöst wird und für ältere Browser wie IE9.
Ich würde mich freuen, wenn Sie eine bessere Lösung finden.
Ich gehe davon aus, dass das System möglicherweise eine Art Schutz hat, der nicht alle Anforderungen analysiert (das Ersetzen von "./pdf.worker.js" durch "leer" hat bei mir nicht funktioniert).
@ Vanuan Können Sie ein Problem mit systemjs einreichen, um zu sehen, ob sie etwas Besseres im Sinn haben? Vielen Dank.
Klingt nach der allerletzten Ausgabe unter systemjs https://github.com/systemjs/systemjs/issues/983 ?
Nun, ich würde eine miese Lösung vorziehen als gar keine Lösung. Für meinen Anwendungsfall ist sogar das Einfrieren einer Seite von 1 Sekunde in Ordnung.
@ Vanuan , an der Verwendung der Datei
An der Verwendung der Datei pdf.combined.js hat sich nichts geändert
Ah gut!
Wie auch immer, etwas hat sich definitiv geändert, was die Verwendung mit Arbeitern betrifft.
Zuvor konnten wir den vollständigen Pfad zum Worker verwenden, aber Uncaught ReferenceError: require is not defined
darin enthalten:
PDFJS.workerSrc = 'jspm_packages/npm/[email protected]/build/pdf.worker.js';
Jetzt scheint es, als ob es beim Laden von Dateien hängen bleibt. Als ob der vom Modul geladene Rückruf niemals abgeschlossen wird.
Das zuletzt angeforderte Modul ist process
.
Wahrscheinlich kann Systemjs die folgende Konstruktion nicht verarbeiten:
(function(process) {
if (typeof PDFJS === 'undefined') {
(typeof window !== 'undefined' ? window : this).PDFJS = {};
}
})(require('process'));
Wie auch immer, etwas hat sich definitiv geändert, was die Verwendung mit Arbeitern betrifft.
Zuvor konnten wir den vollständigen Pfad zum Arbeiter verwenden.
pdf.combined.js ist vollständig enthalten / enthält pdf.worker.js und erfordert nicht, dass workerSrc angegeben wird.
Änderungen an pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff -eccf5b94e31b0939738de07167e02
Ja, ich prüfe nur die Möglichkeiten, Worker zusammen mit JSPM einzusetzen.
Jetzt Problem: pdf.worker.js wird zweimal geladen, das Problem wurde durch request.ensure () im Webpack behoben
Also, jetzt wird es in den Hauptthread geladen und verwendet keine importScripts ()?
Meine src / app.js ist:
import pdfjs from 'pdfjs-dist';
console.log(PDFJS);
Es wird also noch nicht einmal getDocument verwendet, aber im Netzwerkmonitor werden zwei Einträge für pdf.worker.js angezeigt
Es ist komisch. Ich sehe nur einen Eintrag.
Es ist komisch. Ich sehe nur einen Eintrag.
Es soll keine AFAIK sein :)
Das gleiche gilt für Firefox und Chrome:
Ah. Es sieht also so aus, als würde Systemjs alle require
s dumm analysieren und versuchen, sie zu laden ...
Bedingte Anforderungen sind kein sehr häufiger Anwendungsfall.
Aus diesem Grund wird auch versucht, Node-Aure zu laden.
@yurydelendik
Wie benötigt solche Hilfe Webpack? Webpack lädt immer noch Worker mit importScripts, oder?
Bedingte Anforderungen sind kein sehr häufiger Anwendungsfall.
Ich würde nicht zustimmen, https://github.com/systemjs/systemjs/issues/983 und https://github.com/webpack/docs/wiki/code-splitting sind häufige Anwendungsfälle.
Webpack lädt immer noch Worker mit importScripts, oder?
Es tut. über new Worker(..)
. Es besteht jedoch auch die Möglichkeit, pdf.worker.js als Modul zu laden, wenn Worker deaktiviert sind.
Das Problem wird durch # 6775 behoben - das System hat eine automatische Erkennung für den Modultyp. Jetzt ist es üblich, mit UMD wird es AMD sein, so dass es nicht versucht, require () zu analysieren.
PS-Wip unter https://github.com/yurydelendik/pdf.js/tree/pdfjsumd
Wow, großartig, ich werde es versuchen, sobald es zusammengeführt und veröffentlicht ist.
Schließen wie durch # 6825 festgelegt. Wenn es noch Probleme gibt, öffnen Sie bitte eine neue Ausgabe.
Ich empfehle außerdem, das Modulformat bei Verwendung von jspm zu überschreiben: jspm install npm:pdfjs-dist -o "{format: 'amd'}"