Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for async/await, using Babel, and convert some (applicable) code to make use of it #9944

Closed
wants to merge 7 commits into from

Conversation

Snuffleupagus
Copy link
Collaborator

@Snuffleupagus Snuffleupagus commented Jul 31, 2018

A good introduction to async/await, explaining the differences to Promises, can be found in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function

For proof-of-concept, this patch converts a couple of Promise returning methods to use async instead.
Please note that the generic build, based on this patch, has been successfully testing in IE11 (i.e. the viewer loads and nothing is obviously broken).

Being able to use modern JavaScript features like async/await is a huge plus, but there's one (obvious) side-effect: The size of the built files will increase slightly (unless SKIP_BABEL == true). That's unavoidable, but seems like a small price to pay in the grand scheme of things.

Finally, note that the chromium build target was changed to no longer skip Babel translation, since the Chrome extension still supports version 49 of the browser (where native async support isn't available).

Much more manageable diff with https://github.com/mozilla/pdf.js/pull/9944/files?w=1

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/6b623451ef99c32/output.txt

@pdfjsbot
Copy link

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/6b623451ef99c32/output.txt

Total script time: 2.88 mins

Published

Copy link
Contributor

@timvandermeij timvandermeij left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like how this works and how it makes the code easier. Especially getting rid of the Promise.resolve().then construction makes it easier to reason about the code. I'm personally in favor of starting to use async/await, especially if we can make it work in the supported browsers. @brendandahl @yurydelendik Thoughts?

@@ -300,7 +300,7 @@ function setReferer(url, callback) {
let storageArea = chrome.storage.sync || chrome.storage.local;

class ChromePreferences extends BasePreferences {
_writeToStorage(prefObj) {
async _writeToStorage(prefObj) {
Copy link
Contributor

@timvandermeij timvandermeij Jul 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that this is async, we should be able to remove the return new Promise code a line below. This also applies to the other change in this file and the changes in web/firefoxcom.js.

Copy link
Collaborator Author

@Snuffleupagus Snuffleupagus Jul 31, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that this is async, we should be able to remove the return new Promise code a line below.

Nope, that won't work :-)
Please note that, both here and in the other file you refer to, the Promises are resolved from callback functions and that doesn't really work with async/await. (Maybe these shouldn't be marked as async, but that'd look slightly strange since the BasePreferences ones are.)


I really like how this works and how it makes the code easier.

It can (greatly) simplify certain code, as long as you keep in mind that not all Promise usage can/should be replaced with async/await; it really depends on the situation!
Keep in mind that await will suspend the following code, whereas a Promise allows code placed after it to run; these examples are quite good at highlighting the differences.

@Snuffleupagus Snuffleupagus changed the title Add support for async/await, using Babel, and convert some (primarly /web) code to make use of it Add support for async/await, using Babel, and convert some (applicable) code to make use of it Aug 3, 2018
@pdfjsbot
Copy link

pdfjsbot commented Aug 3, 2018

From: Bot.io (Linux m4)


Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/0f10e2eac4afc03/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Aug 3, 2018

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/0f10e2eac4afc03/output.txt

Total script time: 6.98 mins

Published

@Snuffleupagus
Copy link
Collaborator Author

Snuffleupagus commented Aug 4, 2018

Locally on Windows, I get the results as below (all sizes in bytes) for the build/mozcentral respectively build/generic directories for the corresponding builds:

gulp mozcentral gulp generic
master 3 442 404 10 831 041
patch 3 440 333 11 039 049

The size of the mozcentral build is reduced slightly, which is great!
The size of the generic build does increase, but that's hopefully acceptable given the value that async/await support brings.

Edit: Note that the latest version of the PR converts code in all major folders (i.e. src/core, src/display, and web/) to utilize async/await. Hence the size increase for gulp generic builds will be a one-time event, since all of the built files (i.e. build/pdf.js, build/pdf.worker.js, and web/viewer.js) now includes the necessary polyfills.

@Snuffleupagus
Copy link
Collaborator Author

/botio test

@pdfjsbot
Copy link

pdfjsbot commented Aug 7, 2018

From: Bot.io (Linux m4)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/0f44a703f0c9d5a/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Aug 7, 2018

From: Bot.io (Windows)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.215.176.217:8877/9ba1c81d0640402/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Aug 7, 2018

From: Bot.io (Windows)


Success

Full output at http://54.215.176.217:8877/9ba1c81d0640402/output.txt

Total script time: 28.39 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

@pdfjsbot
Copy link

pdfjsbot commented Aug 7, 2018

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/0f44a703f0c9d5a/output.txt

Total script time: 36.21 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

@Snuffleupagus
Copy link
Collaborator Author

/botio-linux preview

@pdfjsbot
Copy link

pdfjsbot commented Aug 9, 2018

From: Bot.io (Linux m4)


Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/913f175ef4663a3/output.txt

@pdfjsbot
Copy link

pdfjsbot commented Aug 9, 2018

From: Bot.io (Linux m4)


Success

Full output at http://54.67.70.0:8877/913f175ef4663a3/output.txt

Total script time: 7.06 mins

Published

@Snuffleupagus
Copy link
Collaborator Author

Snuffleupagus commented Aug 12, 2018

I'm personally in favor of starting to use async/await, especially if we can make it work in the supported browsers. @brendandahl @yurydelendik Thoughts?

It's most likely presumptuous to assume that this old IRC comment by bdahl implies support for this particular PR; however, it does seem to indicate a wish to be able to use async/await in PDF.js.

Given that no one has objected "violent" to either using async/await in general or the specific approach suggested here, and the fact that all tests pass on the bots (where Babel translation is disabled, i.e. the code is tested as-is), I'm wondering if we could just consider landing this PR!?

@timvandermeij
Copy link
Contributor

timvandermeij commented Aug 12, 2018

I'm fine with that. There is also #9521 (comment). I'm glad that Babel seems to handle IE11 for us. I'll land it if I find nothing after another review.

For proof-of-concept, this patch converts a couple of `Promise` returning methods to use `async` instead.
Please note that the `generic` build, based on this patch, has been successfully testing in IE11 (i.e. the viewer loads and nothing is obviously broken).

Being able to use modern JavaScript features like `async`/`await` is a huge plus, but there's one (obvious) side-effect: The size of the built files will increase slightly (unless `SKIP_BABEL == true`). That's unavoidable, but seems like a small price to pay in the grand scheme of things.

Finally, note that the `chromium` build target was changed to no longer skip Babel translation, since the Chrome extension still supports version `49` of the browser (where native `async` support isn't available).
…r than manually returning `Promise`s

This changes the methods signatures of `GenericL10n`, `MozL10n`, and `NullL10n`.
…rather than manually returning `Promise`s

*Ignoring whitespace changes is probably necessary, in order for the diff to be readable.*
…number of Promises and temporary variables necessary when setting the initial document location
@brendandahl
Copy link
Contributor

I'm good with this, I would like to roll it out in chunks though. Can we open a PR with just the first commit? I'll review then we can land and start adding more pieces after a little time to make sure everything is going as expected.

@Snuffleupagus
Copy link
Collaborator Author

/botio-windows test

@pdfjsbot
Copy link

From: Bot.io (Windows)


Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.215.176.217:8877/1e6d2933dffc657/output.txt

@pdfjsbot
Copy link

From: Bot.io (Windows)


Success

Full output at http://54.215.176.217:8877/1e6d2933dffc657/output.txt

Total script time: 29.50 mins

  • Font tests: Passed
  • Unit tests: Passed
  • Regression tests: Passed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants