-
Notifications
You must be signed in to change notification settings - Fork 149
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
Implement URL.from helper #443
Comments
This is discussed in #354. Looking at your implementation, where does it perform input validation? |
@annevk input validation is an open question, but please note that input is not as complicated as I see in the #354. I would like to get focus on performance leaving most of the validation for the users. You should know what you put there (also make writing 3rd party libraries easier). I'd like to do things like: const input = {}
// ...
input.protocol = 'https'
// ...
input.host = 'localhost'
// ...
input.query = querystring.stringify({ a: 1, b: 2 })
// ...
input.path = ['a', 'b']
// ...
input.path.pop()
// ...
const myURL = URL.from(input) If you did mistake you should get punished - sure. But what to do with users that are using typescript and checking things before using them in libraries? Punish them with double checks hurting performance? Anyway, if we can agree on the matter I am fine with strict checks (maybe with an option for I'd love to see it in Node.js. |
Move over to #354 to keep things together. |
Currently if you're handed a URL object you can be assured it conforms to a set of rules. Allowing someone to create a URL object that bypasses those rules would result in a security issue. |
@annevk I understand that. However, eventually there will be a 3rd party library(-ies) for doing such things which won't be controlled by the spec making this situation even worse. If spec defines strict rules on how to build a url from an object then at least you can control it and you don't get 5 different ways of solving this exact problem after N years/months. |
To some extent such a situation is good as we then get to "pick a winner" to standardize the ecosystem around. Otherwise we might end up designing something that nobody really wants to use at scale. |
Hello, everyone!
I've implemented
URL.from
over in Node.js project (PR), but we have a discussion there on to should we extendURL
object or not. Good points are made for not doing so.However, it feels like it would be convenient to have an option of creating a url object not only from string that should represent a url, but also from an object (or any other alternative according to any language) allowing builder pattern.Also it can be much faster than parsing the string.
I guess it would be a nice option in the browsers as well since making a url from an object-config is as common as making a url from string.
The text was updated successfully, but these errors were encountered: