Agregue soporte para systemjs.
Vanuan
Todos 34 comentarios
Solicitaría más información ya que no se proporcionan ejemplos. Y creo que Browserify funciona con pdfjs-dist actualmente (con algunas excepciones de módulos).
yurydelendik
en 22 dic. 2015
Este es el ejemplo más común para usar 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
Gracias por ejemplo
yurydelendik
en 22 dic. 2015
En versiones anteriores, podíamos usar jspm shim para usar pdfjs.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
Pero después de la inclusión de node-secure, no podemos (node-sure no parece ser compatible con system.js).
Vanuan
en 22 dic. 2015
En realidad, esta es una solicitud para jspm packager, no específicamente Systemjs loader.
Es decir, estaría bien si requiriera jspm shim, pero no agregue cambios incompatibles como node-secure.
Vanuan
en 22 dic. 2015
@Vanuan
Tener lo siguiente en la solución config.js del problema:
"npm:[email protected]": {
"process": "github:jspm/[email protected]",
"node-ensure": "empty",
"entry?name=[hash]-worker.js": "empty"
},
(vacío es un archivo.js vacío sin contenido)
Se necesita un truco similar para Browserify
yurydelendik
en 22 dic. 2015
Ahora problema: pdf.worker.js se carga dos veces, ese es un problema que se resolvió con request.ensure () en el paquete web. El './pdf.worker.js' tiene que tener prohibido cargarse hasta que sea realmente necesario.
yurydelendik
en 22 dic. 2015
Pensé "PDFJS.disableWorker = true;" resuelve eso? ¿No es así?
Vanuan
en 22 dic. 2015
Si usa System.import('./pdf.worker') , solo emitirá una solicitud http.
O incluso System.import('pdfjs-dist/build/pdf.worker')
¿Existe una razón específica por la que se utilizó node-ensure ? Creo que el cargador del sistema funciona bien en Webpack.
Vanuan
en 22 dic. 2015
"PDFJS.disableWorker = true;" no es una opción, ya que queremos mover el procesamiento de PDF en el hilo diferente. No queremos sugerir una pésima solución para los usuarios de la biblioteca, ¿verdad?
yurydelendik
en 22 dic. 2015
Bueno, preferiría una pésima solución a ninguna solución. Para mi caso de uso, incluso una congelación de página de 1 segundo está bien.
Me alegraría si encuentra una mejor solución.
Vanuan
en 22 dic. 2015
¿Existe una razón específica por la que se utilizó node-sure?
Si observa detenidamente lo que examples / webpack / produce:
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" es el archivo principal que se carga (eso significa que traerá e inicializará la IU después de 122796 bytes - inicio de página más rápido). "9d074593b165291f150e-worker.js" es un trabajador que ejecutará la lógica y no bloqueará la interfaz de usuario en dispositivos lentos. La parte "1.bundle.js" se carga solo si se activa disableWorker y para navegadores heredados como IE9.
yurydelendik
en 22 dic. 2015
Me alegraría si encuentra una mejor solución.
Espero que systemjs tenga algún tipo de protección para no analizar todos los requisitos (reemplazar "./pdf.worker.js" con "vacío" no funcionó para mí).
@Vanuan ¿Puede presentar un problema con systemjs para ver si tienen algo mejor en mente? Gracias.
yurydelendik
en 22 dic. 2015
Suena como el último problema en systemjs https://github.com/systemjs/systemjs/issues/983 ?
yurydelendik
en 22 dic. 2015
Bueno, preferiría una pésima solución a ninguna solución. Para mi caso de uso, incluso una congelación de página de 1 segundo está bien.
@Vanuan , nada cambió en el uso del archivo pdf.combined.js (espero) - parece que debemos conservarlo para tales casos. Debe usarlo como describió como un problema en # 6729. A partir de su descripción, no estaba claro si planea usar systemjs para cargar PDFJS.
yurydelendik
en 22 dic. 2015
nada cambió en el uso del archivo pdf.combined.js
¡Ah, genial!
Vanuan
en 22 dic. 2015
De todos modos, algo definitivamente ha cambiado con respecto a su uso con trabajador.
Anteriormente, podíamos usar la ruta completa al trabajador, pero obtener Uncaught ReferenceError: require is not defined dentro de ella:
PDFJS.workerSrc = 'jspm_packages/npm/[email protected]/build/pdf.worker.js';
Ahora, parece que está atascado al cargar archivos. Como si la devolución de llamada cargada en el módulo nunca se completara.
El último módulo solicitado es process .
Probablemente, Systemjs no puede procesar la siguiente construcción:
(function(process) {
if (typeof PDFJS === 'undefined') {
(typeof window !== 'undefined' ? window : this).PDFJS = {};
}
})(require('process'));
De todos modos, algo definitivamente ha cambiado con respecto a su uso con trabajador.
Anteriormente, podíamos usar la ruta completa al trabajador,
pdf.combined.js totalmente incluido / incluye pdf.worker.js y no necesita que se especifique workerSrc.
yurydelendik
en 23 dic. 2015
Cambios en pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff -eccf5b94e31b0939738de07167e02af6
yurydelendik
en 23 dic. 2015
Sí, solo estoy evaluando las opciones de usar trabajadores junto con jspm.
Vanuan
en 23 dic. 2015
Ahora problema: pdf.worker.js se carga dos veces, ese es un problema que se resolvió mediante request.ensure () en el paquete web
Entonces, ¿ahora se está cargando en el hilo principal y no usa importScripts ()?
Vanuan
en 23 dic. 2015
Mi src / app.js es:
import pdfjs from 'pdfjs-dist';
console.log(PDFJS);
Entonces ni siquiera está usando getDocument todavía, pero en el monitor de red muestra dos entradas para pdf.worker.js
yurydelendik
en 23 dic. 2015
Es extraño. Solo veo una entrada.
Vanuan
en 23 dic. 2015
Es extraño. Solo veo una entrada.
No será ninguno AFAIK :)
yurydelendik
en 23 dic. 2015
Lo mismo en Firefox y Chrome:
yurydelendik
en 23 dic. 2015
¡Ah! Entonces parece que Systemjs analiza tontamente todos los require s e intenta cargarlos ...
Vanuan
en 23 dic. 2015
El requisito condicional no es un caso de uso muy común.
Vanuan
en 23 dic. 2015
Es por eso que también intenta cargar node-secure.
Vanuan
en 23 dic. 2015
@yurydelendik
¿Cómo tal requiere ayuda webpack? Webpack todavía carga al trabajador usando importScripts, ¿verdad?
Vanuan
en 23 dic. 2015
El requisito condicional no es un caso de uso muy común.
No estoy de acuerdo, https://github.com/systemjs/systemjs/issues/983 y https://github.com/webpack/docs/wiki/code-splitting son casos de uso comunes.
Webpack todavía carga al trabajador usando importScripts, ¿verdad?
Lo hace. a través de new Worker(..) . Pero también tiene una opción para cargar pdf.worker.js como módulo si los trabajadores están deshabilitados.
yurydelendik
en 23 dic. 2015
El problema se resolverá con # 6775: systemjs tiene detección automática del tipo de módulo. Ahora es commonjs, con UMD será AMD, por lo que no intentará analizar require ().
PS wip en https://github.com/yurydelendik/pdf.js/tree/pdfjsumd
yurydelendik
en 28 dic. 2015
Vaya, genial, lo intentaré tan pronto como fusionado y lanzado
Vanuan
en 28 dic. 2015
Cierre según lo fijado por # 6825. Si quedan problemas, abra un nuevo problema.
timvandermeij
en 8 ene. 2016
También recomiendo anular el formato del módulo al usar jspm: jspm install npm:pdfjs-dist -o "{format: 'amd'}"
yurydelendik
en 4 abr. 2016
Temas relacionados
BrennanDuffey
·
3Comentarios
SehyunPark
·
3Comentarios
kleins05
·
3Comentarios
sujit-baniya
·
3Comentarios
patelsumit5192
·
3Comentarios