Pdf.js: Suporte Systemjs

Criado em 22 dez. 2015 · 34Comentários · Fonte: mozilla/pdf.js

Adicione suporte para systemjs.

2-feature

Fonte

Vanuan

Todos 34 comentários

Eu solicitaria mais informações, pois nenhum exemplo é fornecido. E eu acho que o Browserify funciona com pdfjs-dist atualmente (com algumas exceções de módulos).

yurydelendik em 22 dez. 2015

Este é o exemplo mais comum para usar o 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

Vanuan em 22 dez. 2015

Obrigado por exemplo

yurydelendik em 22 dez. 2015

Nas versões anteriores, podíamos usar jspm shim para usar pdfjs.
https://github.com/jspm/registry/wiki/Configuring-Packages-for-jspm
Mas, após a inclusão de node-sure, não podemos (node-garantir não parece ser compatível com system.js).

Vanuan em 22 dez. 2015

Na verdade, este é um pedido para o jspm packager, não especificamente para o carregador Systemjs.
Ou seja, não haveria problema se fosse necessário shim jspm, mas não adicione alterações incompatíveis como o node-garantir.

Vanuan em 22 dez. 2015

@Vanuan

Ter o seguinte no config.js solução alternativa para o problema:

    "npm:[email protected]": {
      "process": "github:jspm/[email protected]",
      "node-ensure": "empty",
      "entry?name=[hash]-worker.js": "empty"
    },

(vazio é um arquivo empty.js sem conteúdo)

Hack semelhante é necessário para o Browserify

yurydelendik em 22 dez. 2015

Agora problema: pdf.worker.js é carregado duas vezes, esse problema foi resolvido por request.ensure () no webpack. O './pdf.worker.js' deve ser proibido de carregar até que seja realmente necessário.

yurydelendik em 22 dez. 2015

Eu pensei "PDFJS.disableWorker = true;" resolve isso? Não é?

Vanuan em 22 dez. 2015

Se você usar System.import('./pdf.worker') , ele emitirá apenas uma solicitação http.

Ou mesmo System.import('pdfjs-dist/build/pdf.worker')

Existe uma razão específica pela qual node-ensure foi usado? Eu acredito que o carregador do sistema funciona bem no Webpack.

Vanuan em 22 dez. 2015

"PDFJS.disableWorker = true;" não é uma opção, uma vez que queremos mover o processamento de PDF para o segmento diferente. Não queremos sugerir uma solução ruim para usuários de bibliotecas, queremos?

yurydelendik em 22 dez. 2015

Bem, eu preferiria uma solução ruim do que nenhuma solução. Para o meu caso de uso, mesmo o congelamento de página de 1 segundo é adequado.
Eu ficaria feliz se você encontrar uma solução melhor.

Vanuan em 22 dez. 2015

Existe uma razão específica pela qual o node-garantir foi usado?

Se você observar cuidadosamente quais exemplos / webpack / produz:

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" é o arquivo principal que carrega (isso significa que ele trará e inicializará a IU após 122796 bytes - inicialização de página mais rápida). "9d074593b165291f150e-worker.js" é um trabalhador que executa a lógica e não bloqueia a IU em dispositivos lentos. A parte "1.bundle.js" é carregada apenas se disableWorker for acionado e para navegadores legados, como o IE9.

yurydelendik em 22 dez. 2015

Eu ficaria feliz se você encontrar uma solução melhor.

Estou esperando que o systemjs tenha algum tipo de proteção para não analisar todos os requisitos (substituir "./pdf.worker.js" por "vazio" não funcionou para mim).

@Vanuan Você pode registrar um problema com o systemjs para ver se eles têm algo melhor em mente? Obrigado.

yurydelendik em 22 dez. 2015

Parece a última edição em systemjs https://github.com/systemjs/systemjs/issues/983 ?

yurydelendik em 22 dez. 2015

Bem, eu preferiria uma solução ruim do que nenhuma solução. Para o meu caso de uso, mesmo o congelamento de página de 1 segundo é adequado.

@Vanuan , nada mudou no uso do arquivo pdf.combined.js (espero) - parece que precisamos mantê-lo para esses casos. Você precisa usá-lo conforme descrito como um problema em # 6729. Pela sua descrição, não ficou claro se você planeja usar o systemjs para carregar o PDFJS.

yurydelendik em 22 dez. 2015

nada mudou no uso do arquivo pdf.combined.js

Ah, ótimo!

Vanuan em 22 dez. 2015

Enfim, algo mudou definitivamente em relação ao uso com o trabalhador.
Anteriormente, poderíamos usar o caminho completo para o trabalhador, mas obter Uncaught ReferenceError: require is not defined dentro dele:

PDFJS.workerSrc = 'jspm_packages/npm/[email protected]/build/pdf.worker.js';

Agora, parece que ele travou no carregamento de arquivos. Como se o retorno de chamada do módulo carregado nunca fosse concluído.
O último módulo solicitado é process .

Provavelmente, Systemjs não pode processar a seguinte construção:

(function(process) {
  if (typeof PDFJS === 'undefined') {
    (typeof window !== 'undefined' ? window : this).PDFJS = {};
  }
})(require('process'));

Vanuan em 23 dez. 2015

👍1

Enfim, algo mudou definitivamente em relação ao uso com o trabalhador.
Anteriormente, podíamos usar o caminho completo para o trabalhador,

pdf.combined.js totalmente incluído / inclui pdf.worker.js e não precisa de workerSrc para ser especificado.

yurydelendik em 23 dez. 2015

Alterações em pdf.combined.js https://github.com/mozilla/pdfjs-dist/commit/a7cd5f77b00bac19c0f6ee4c2cfd5bbf0fe45d8f#diff -eccf5b94af31b0939738de07167e026

yurydelendik em 23 dez. 2015

Sim, estou apenas avaliando opções de uso de workers junto com o jspm.

Vanuan em 23 dez. 2015

Agora problema: pdf.worker.js é carregado duas vezes, esse problema foi resolvido por request.ensure () no webpack

Então, agora ele está sendo carregado na thread principal e não usa importScripts ()?

Vanuan em 23 dez. 2015

Meu src / app.js é:

import pdfjs from 'pdfjs-dist';

console.log(PDFJS);

Portanto, ainda nem está usando getDocument, mas no monitor de rede ele mostra duas entradas para pdf.worker.js

yurydelendik em 23 dez. 2015

É estranho. Eu só vejo uma entrada.

Vanuan em 23 dez. 2015

É estranho. Eu só vejo uma entrada.

Não deve ser nenhum AFAIK :)

yurydelendik em 23 dez. 2015

O mesmo no Firefox e no Chrome:
screen shot 2015-12-22 at 5 34 42 pm

yurydelendik em 23 dez. 2015

Ah. Então, parece que Systemjs estupidamente analisa todos os require s e tenta carregá-los ...

Vanuan em 23 dez. 2015

A exigência condicional não é um caso de uso muito comum.

Vanuan em 23 dez. 2015

É por isso que ele tenta carregar o nó-garantir também.

Vanuan em 23 dez. 2015

@yurydelendik
Como tal requer ajuda do webpack? O Webpack ainda carrega o trabalhador usando importScripts, certo?

Vanuan em 23 dez. 2015

A exigência condicional não é um caso de uso muito comum.

Eu discordo, https://github.com/systemjs/systemjs/issues/983 e https://github.com/webpack/docs/wiki/code-splitting são casos de uso comuns.

O Webpack ainda carrega o trabalhador usando importScripts, certo?

~~É verdade.~~ via new Worker(..) . Mas também tem a opção de carregar pdf.worker.js como módulo se os trabalhadores estiverem desabilitados.

yurydelendik em 23 dez. 2015

O problema será resolvido por # 6775 - o systemjs tem detecção automática para o tipo de módulo. Agora é commonjs, com UMD será AMD, então não tentará analisar require ().

PS wip em https://github.com/yurydelendik/pdf.js/tree/pdfjsumd

yurydelendik em 28 dez. 2015

Uau, ótimo, vou tentar assim que for mesclado e lançado.

Vanuan em 28 dez. 2015

Fechamento corrigido por # 6825. Se houver problemas restantes, abra um novo problema.