-
Notifications
You must be signed in to change notification settings - Fork 821
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
fix: do not access promise before resolve #1641
Conversation
This PR still does not solve the reference error. You cannot access the promise from within the lexical scope of the promise handler. Please test in the latest firefox as this seems to be where people are seeing the issue. It may have a stricter lexical scope policy than other browsers? |
Did you check out this PR and opened any web example in firefox ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving this with a more detailed explanation below because the fix was not obvious to me.
If you look at the actual text of the error Uncaught (in promise) ReferenceError: can't access lexical declaration 'promise' before initialization
it points you to this documentation https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Cant_access_lexical_declaration_before_init
The code in question does something like this:
// broken
const x = new Promise(resolve => {
console.log(x); // access x is illegal here
resolve();
});
// fixed
const x = new Promise(resolve => {
resolve();
console.log(x); // access x is fine here
});
new Promise(cb)
calls cb
synchronously and only returns a value when resolve
is called. This means in example 1, when the code tries to log x
, it has not yet been assigned. In example 2, calling resolve
causes new Promise
to return the new promise which makes it accessible.
@open-telemetry/javascript-approvers ^^ |
☝️ Thanks for the explanation. It's super helpful. |
It was not at all obvious to me. I think this is a good change for now but in the future we should refactor this to a more obvious implementation if possible. |
Which problem is this PR solving?
Short description of the changes