-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add warning where request/request compatible code would silently fail #58
Comments
ya don't need to add extra overhead of supporting querystring. if someone wants that they should use a shitty-qs or something like it |
I mean the other way around than shitty-qs works, but that's the main point - you can use anything to put query params in the url (I like how |
console warnings break the unix rule of silence. If you want to warn the user, throw an exception. |
Ok, thanks for the reminder. |
In the browser, I think console warnings are better than giving no indication. I've added that in one of my own libraries and been very glad I did, it's saved me a good amount of debugging time. Throwing an exception is fine too. It seems like overly-aggressive duck typing in the browser - in the browser I'm more willing to allow warnings instead of exceptions in cases like this - but I would support throwing an error in the case of input options that aren't implemented. |
It's a hard decision. Sometimes, when you're reusing code between node and browser and put I was thinking we could expose a |
request
has some options that would be silently ignored if one tried to use them with xhr, eg.request
will send the query, butxhr
doesn't support qs (if it should is a totally different matter, we keep the size small)Proposal:
run
console.warn(optionKey+' option not implemented')
The text was updated successfully, but these errors were encountered: