-
Notifications
You must be signed in to change notification settings - Fork 144
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
[request a pair of eyes] experiments with history api #70
Comments
One thought: You could expand the Related: This code: fn history() -> web_sys::History {
window().history().unwrap_throw()
}
fn window() -> web_sys::Window {
web_sys::window().unwrap_throw()
} , along with related things like |
I agree with @David-OConnor that a Similarly, it needs a way to retrieve the current state (from
Actually, no event is fired. The As far as I know, it is not possible to be notified when the URL changes with This is a major annoyance, but there's not too much we can do about it (other than creating our own event system, which might be a good idea!)
Is this function actually needed? The browser will already throw an exception if the URL is invalid. So you should be able to pattern match on that. |
Do y'all think integrating |
I think accepting I think direct support for Serde should be in a higher layer (such as a router). |
I like that approach. |
My personal opinion is that there is definitely space for a routing library in gloo that is strongly typed, but that there will be several layers below this that need implementing first. Equivalent in JS would be
This design will need some iterations/improvements, at the moment I'm just getting it to work. Could you try running the test suite for $ wasm-pack test --headless --firefox # takes aggggges but works
$ wasm-pack test --headless --chrome # crashes with very weird error
$ wasm-pack test --chrome # open chrom{e|ium} and navigate to tests to cause a crash the headless chrome error I get is
So basically none of this output makes sense. 3626 is too big for an ipv4 address, it shouldn't be starting on a random ip anyway, what's being parsed at the bottom? I have no idea. Maybe I should raise this with |
UPDATE The error is caused by OOM: (from cli logging)
|
Another update so I've changed the code to look for exceptions rather than parse the URL, and I'm no longer having problems. It all runs fast and I don't get any crashes. However, the problem I was experiencing here is clearly a bug somewhere. I'll raise it against wasm-bindgen to start with, but I'm not sure if it shouldn't be upstream in the browsers. I will create a new issue when I've got a working API to get feedback (I'll incorporate what's been said in this thread). |
I'm playing with wrapping the history api, which should be easy. I've got a crate, but the test in it takes ages to run on firefox, and full-on crashes chrome. It might be a bug in what I've done - but I would appreciate other people taking a look.
The code is currently called wasm-history.
The text was updated successfully, but these errors were encountered: