Hermes: URL interface

Created on 14 Oct 2019  路  5Comments  路  Source: facebook/hermes

Other projects like Deno support this:

~~~

new URL('https://github.com')
URL { _parts: { protocol, username, password, hostname, port, path, query,
hash}, _searchParams: URLSearchParams { params: [], url: [Circular], append:
[Function], delete: [Function], set: [Function] } }
~~~

However Hermes does not:

~~~

new URL('https://github.com')
ReferenceError: Property 'URL' doesn't exist
~~~

https://developer.mozilla.org/docs/Web/API/URL

wontfix

Most helpful comment

IMO React Native shouldn't expose global URL then, because it does a lot of other things are build to be browser-compatible like fetch (and bare XMLHttpRequest), alert, requestAnimationFrame.

Keeping SOME compatible globals and having some well-known but incompatible is counter-intuitive.

And it's hard to fix issues caused by that sometimes (because if some library depends on global URL the only thing I can do is to override URL with compatible solution... while possibly breaking things that depended on non-compatible global implementation...).

I'd suggest in the next breaking release of RN to rename that non compatible global into something else.

To keep conversation clean - upvote if you agree. Discuss if you have different views/solutions.

All 5 comments

Thank you for pointing this our. Hermes doesn't currently implement the URL constructor because it is part of the web platform (https://spec.whatwg.org/), not ECMAScript, and Hermes is not supposed to run in browsers.

With that said, we realize that it can be a useful feature. Implementing in Hermes however would be a non-trivial binary size increase of Hermes, which would affect everybody, even apps that don't need it.

We recommend using a polyfill like https://www.npmjs.com/package/whatwg-url or https://www.npmjs.com/package/url-polyfill .

For more context a similar issue is being tracked at https://github.com/facebook/react-native/issues/16434 .

IMO React Native shouldn't expose global URL then, because it does a lot of other things are build to be browser-compatible like fetch (and bare XMLHttpRequest), alert, requestAnimationFrame.

Keeping SOME compatible globals and having some well-known but incompatible is counter-intuitive.

And it's hard to fix issues caused by that sometimes (because if some library depends on global URL the only thing I can do is to override URL with compatible solution... while possibly breaking things that depended on non-compatible global implementation...).

I'd suggest in the next breaking release of RN to rename that non compatible global into something else.

To keep conversation clean - upvote if you agree. Discuss if you have different views/solutions.

I agree. In fact I am not entirely sure that RN exposes a global URL. Does it? It has an URL module, but I didn't see code installing it in the global object (but I could have missed it).

I think it would be more constructive to discuss this in the RN issue rather than here.

Closing for now with "wontfix". If in the future our thinking changes, we can revisit.

For others ended up here in the future. The recommended polyfills doesn't even work, both throws when calling new URL(...).

Was this page helpful?
0 / 5 - 0 ratings