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 a getter for the global window #659

Closed
fitzgen opened this issue Aug 6, 2018 · 5 comments
Closed

Expose a getter for the global window #659

fitzgen opened this issue Aug 6, 2018 · 5 comments
Labels
web-sys Issues related to the `web-sys` crate

Comments

@fitzgen
Copy link
Member

fitzgen commented Aug 6, 2018

I think we could do something like

#[wasm_bindgen]
extern {
    #[wasm_bindgen(getter)]
    pub fn window() -> Window;
}

inside crates/web-sys/src/lib.rs and consider that the entry point to all globally exposed properties and methods.

@fitzgen fitzgen added web-sys Issues related to the `web-sys` crate Blocking Rust 2018 labels Aug 6, 2018
@fitzgen fitzgen mentioned this issue Aug 6, 2018
19 tasks
@alexcrichton
Copy link
Contributor

Currently the way to do this would look like:

#[wasm_bindgen]
extern {
    static window: Window;
}

// use `window`

but importing via a static is a little sketchy and I think I'd prefer to get something like a bare getter you've mentioned @fitzgen to work, that makes more sense to me.

@richard-uk1
Copy link
Contributor

Out of curiosity, why is using a static sketchy?

@alexcrichton
Copy link
Contributor

Ah just a personal gut feeling! Using a static creates a different type (a JsStatic) which has a different API to learn and can be non-obvious. Using a function seems much better to me as it's more isolated and fits well with the rest of the API.

@eminence
Copy link
Contributor

Another benefit of using a function is that it's easier to search for in the docs

@fitzgen
Copy link
Member Author

fitzgen commented Aug 24, 2018

We talked about this in the WG meeting today. We decided that when an interface has the [Global] attribute, then we should generate free functions for each of its operations and members without the &self parameter.

This didn't come up at the meeting, but since there are multiple interfaces with [Global] that represent workers, main window, worklets, etc... we probably want these to be static methods for disambiguation and context.

alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Aug 28, 2018
This commit adds further support for the `Global` attribute to not only emit
structural accessors but also emit functions that don't take `&self`. All
methods on a `[Global]` interface will not require `&self` and will call
functions and/or access properties on the global scope.

This should enable things like:

    Window::location() // returns `Location`
    Window::fetch(...) // invokes the `fetch` function

Closes rustwasm#659
alexcrichton added a commit to alexcrichton/wasm-bindgen that referenced this issue Aug 29, 2018
This commit adds further support for the `Global` attribute to not only emit
structural accessors but also emit functions that don't take `&self`. All
methods on a `[Global]` interface will not require `&self` and will call
functions and/or access properties on the global scope.

This should enable things like:

    Window::location() // returns `Location`
    Window::fetch(...) // invokes the `fetch` function

Closes rustwasm#659
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
web-sys Issues related to the `web-sys` crate
Projects
None yet
Development

No branches or pull requests

4 participants