Add a deprecation warning for the eventBusDispatchToDOM option/preference (PR 11631 follow-up)
#11667
Conversation
…events consistently with the rest of the viewer components (PR 11631 follow-up) I overlooked this in PR 11631; sorry about that! Also, ensure that `EventBus` instances *always* track "external" events using a boolean regardless of the actual option value.
|
/botio unittest |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/e99c02281732aa2/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/8725df675a46a29/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/8725df675a46a29/output.txt Total script time: 2.68 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/e99c02281732aa2/output.txt Total script time: 4.81 mins
|
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/de78f4b627ef22c/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/de78f4b627ef22c/output.txt Total script time: 2.53 mins Published |
… add a deprecation warning for the `eventBusDispatchToDOM` option/preference (PR 11631 follow-up)
It occured to me that similar to the `getGlobalEventBus` function, it's probably a good idea to *also* notify users of the fact that `eventBusDispatchToDOM` is now deprecated.
Rather than depending of the re-dispatching of internal events to the DOM, the default viewer can instead be used in e.g. the following way:
```javascript
document.addEventListener("webviewerloaded", function() {
PDFViewerApplication.initializedPromise.then(function() {
// The viewer has now been initialized, and its properties can be accessed.
PDFViewerApplication.eventBus.on("pagerendered", function(event) {
console.log("Has rendered page number: " + event.pageNumber);
});
});
});
```
Snuffleupagus
force-pushed
the
move-dispatchDOMEvent
branch
from
3e582ee to
0fb44f5
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/6d7528218f30866/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/6d7528218f30866/output.txt Total script time: 2.54 mins Published |
|
Yes, that's indeed a good idea. Thanks! |
Update the
waitOnEventOrTimeouthelper function to handle internal events consistently with the rest of the viewer components (PR 11631 follow-up)I overlooked this in PR [api-minor] Deprecate
getGlobalEventBusand update the "viewer components" examples accordingly #11631; sorry about that!Also, ensure that
EventBusinstances always track "external" events using a boolean regardless of the actual option value.Move the
dispatchDOMEventfunctionality out from theEventBusand add a deprecation warning for theeventBusDispatchToDOMoption/preference (PR 11631 follow-up)It occured to me that similar to the
getGlobalEventBusfunction, it's probably a good idea to also notify users of the fact thateventBusDispatchToDOMis now deprecated.Rather than depending of the re-dispatching of internal events to the DOM, the default viewer can instead be used in e.g. the following way: