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

Expose objects and functions from the JavaScript global scope #274

Merged
merged 6 commits into from
Jun 19, 2018

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Jun 18, 2018

These are bindings to JavaScript's standard, built-in objects and their methods and properties.

This does not include any Web, Node, or any other JS environment APIs. Only the things that are guaranteed to exist in the global scope by the ECMAScript standard. They are available in the wasm_bindgen::js module when the js_globals feature is enabled.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects

This is intentionally an incomplete set of imports, and I intend to create a big issue with a big checklist of everything else that we need to add.

@ohanar @spastorino if one of you could review this, that would be very appreciated :)

This can happen when a nested dependency crate exports things but the root crate
doesn't use them. In these cases, it is fine to ignore the missing descriptor,
because the thing it describes was removed as dead code.
These are bindings to JavaScript's standard, built-in objects and their methods
and properties.

This does *not* include any Web, Node, or any other JS environment APIs. Only
the things that are guaranteed to exist in the global scope by the ECMAScript
standard.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects
They aren't part of any public API, and are just an implementation detail of
wasm-bindgen.
@fitzgen
Copy link
Member Author

fitzgen commented Jun 18, 2018

This is intentionally an incomplete set of imports, and I intend to create a big issue with a big checklist of everything else that we need to add.

And here is the big issue with a big checklist: #275

assert!(js::decode_uri("%E0%A4%A").is_err());
}
"#)
.file("test.ts", r#"
Copy link
Member

Choose a reason for hiding this comment

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

This test.ts isn't needed anymore. The changes I made for WebIDL will automatically generate a test.ts equivalent to this one if no test.ts is found.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch! I forgot about that :)

assert_eq!(x, "ABC%20abc%20123");
}
"#)
.file("test.ts", r#"
Copy link
Member

Choose a reason for hiding this comment

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

Same goes for this one.

}

#[allow(non_snake_case)]
mod Object {
Copy link
Member

Choose a reason for hiding this comment

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

Rather than adding an inline module, maybe a new directory should be added? (Especially in preparation for more to be added to js_globals.)

The testing infrastructure will add exactly this default `test.ts` when it isn't
explicitly specified.
@fitzgen fitzgen merged commit 224d203 into rustwasm:master Jun 19, 2018
@spastorino
Copy link
Contributor

I've arrived a bit late to the party but this looks perfect!!!

@fitzgen fitzgen deleted the js-sys branch July 5, 2018 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants