-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Fix js_sys::Intl methods returning Function
s instead of calling them directly
#2506
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
base: main
Are you sure you want to change the base?
Fix js_sys::Intl methods returning Function
s instead of calling them directly
#2506
Conversation
According to the the specification it actually is a getter that returns a DateTime format function. That happens to work out well in JavaScript where it's indistinguishable from a method. It's not so useful as a rust binding though. Perhaps an argument can be made for a |
Thanks for the PR! Unfortunately this is a breaking change so it can't land just yet, but I'll tag it as such for now. |
No problem. Would you like me to do the same with the other similar APIs in the Also, is there any kind of ETA on a breaking release? Judging by the history it seems it might take a while. And I do need these APIs, so perhaps it would be better to make a local copy. |
If you'd like feel free! Unfortunately there is no eta on a new breaking release |
Function
s instead of calling them directly
Done. |
Would it also be good to make the options objects strongly typed? I've tried to mimic the way it's done in |
I think it's probably fine to leave as-is for now, but thanks! |
Since it doesn't look like this will be fixed any time soon. let locales = js_sys::Array::of1(&JsValue::from("en-US"));
let options = js_sys::Object::new();
let intl = js_sys::Intl::NumberFormat::new(&locales, &options);
let num = JsValue::from_f64(140.90);
intl.format().call1(&intl, &num).unwrap().as_string().unwrap() |
According to MDN 'Intl.DateTimeFormat.format' takes a
Date
and returns aString
.I'm not sure why the current binding was made as it is, but the fact that there's a test for it that checks that it does the wrong thing makes it look deliberate. This was originally added in #691, but I see no rationale for it there either. Perhaps there's some obscure historical reason for it. I do see several similar mistakes in the
Intl
namespace however, but figured I'd start with something small and simple to make sure I'm not misunderstanding something.Also, the value returned apparently isn't an instance of
JsString
, butis_string()
still returnstrue
so I'm hoping that's fine.