Re-factor the PDFScriptingManager-class for the viewer-components

Currently this class contains a few "special" code-paths for the COMPONENTS build-target, which normally wouldn't be a problem. However, in this particular case that means accessing code that we don't want to include unconditionally in all builds.
This is currently implemented using build-time `require`-calls which we nowadays want to avoid, and we should strive to remove all such cases from the code-base. (Generally speaking `import` is the future, and build-tools may not always play well with a mix of both formats.)

We can easily improve things here by using sub-classing for the COMPONENTS build-target, and then use the ability to re-name when exporting (to avoid breaking existing code).
This commit is contained in:
Jonas Jenwald 2023-07-13 13:10:06 +02:00
parent 337cba736e
commit 86a868189c
4 changed files with 46 additions and 26 deletions

View file

@ -66,30 +66,6 @@ class PDFScriptingManager {
}
this.#externalServices = externalServices;
this.#docProperties = docProperties;
if (typeof PDFJSDev !== "undefined" && PDFJSDev.test("COMPONENTS")) {
const gs = require("./generic_scripting.js");
this.#externalServices ||= {
createScripting: options => {
return new gs.GenericScripting(options.sandboxBundleSrc);
},
};
this.#docProperties ||= pdfDocument => {
return gs.docProperties(pdfDocument);
};
// The default viewer already handles adding/removing of DOM events,
// hence limit this to only the viewer components.
if (!externalServices) {
window.addEventListener("updatefromsandbox", event => {
this.#eventBus.dispatch("updatefromsandbox", {
source: window,
detail: event.detail,
});
});
}
}
}
setViewer(pdfViewer) {