-
Notifications
You must be signed in to change notification settings - Fork 78
Function parameters anti-pattern #123
Comments
You're right. |
This will mess up es6 arrow functions.
:/ |
Hum, indeed... What would you suggest? |
Personally I think the API is fine, but if it were to change, just swap the args around.
Sometimes anti-patterns are necessary. (not that I consider this an anti-pattern to begin with) |
Indeed, It seems the best way to do it. I plan this change for a future major release then. I need to refactor qwest's code a bit, it's kinda messy ^^ |
Sorry this question is only slightly related but I didn't find the answer in the docs. If I have:
The first then returns a promise that is resolved with |
You're right, at this point |
It's pretty easy to keep the xhr but you're getting into pyramid territory. Return a new promise chain.
|
Right now the parameters are passed to the handler functions like this:
Isn't this a promise anti-pattern? I have to use intermediate functions to get the response instead of directly manipulating it like:
Having the XHR object as the primary parameter in the function would be useful only in a few situations, where for example you care more about the status code instead of the response, which only happens rarely.
The text was updated successfully, but these errors were encountered: