Releases: ember-cli/ember-ajax
v4.0.1
A bug, fixed
What happened?
There was a bug fixed in v3.1.1
that resulted in a "breaking change" for many users. This bug was related to the fact that ember-ajax
previously always made relative URLs into absolute URLs. I didn't correctly think about the fact that this would break people that depended on this behavior, and released the change within a "patch" release.
#383 and the resulting conversation was the outcome of this error on my (@alexlafroscia's) part.
Going forward
Two releases were made to attempt to address this fact.
v3.1.3
was released that reverts the new behavior. If you were banking on your relative URLs being made absolute implicitly, please upgrade to that version.v4.0.0
was released frommaster
, including no new behavior fromv3.1.2
. This means that, if you've already upgraded tov3.1.1
or later, you can safely move tov4.0.0
without changing any code on your end.
I'm sorry for whatever frustration this issue caused and appreciate the assistance of those that brought the issue to my attention.
v3.1.0
Make it Simple(r)
Breaking Changes
Simplifying normalizeErrorResponse
After much discussion, the team around ember-ajax
decided that it was probably not a great idea to reformat the error payload to match some arbitrary format that we designed. Instead, we should just use the payload that the server returned.
If you want to maintain the old behavior, you can include the the legacy/normalize-error-response
mixin, which has the old version of the method included and will override the new behavior.
// app/services/ajax.js
import AjaxService from 'ember-ajax/services/ajax';
import LegacyNormalizeErrorResponse from 'ember-ajax/mixins/legacy/normalize-error-response';
export default AjaxService.extend(LegacyNormalizeErrorResponse, {
// Your other configuration here
});
Replacing AjaxError.errors
with AjaxError.payload
The errors
property on any AjaxError
subclass has been deprecated in favor of a payload
property for a while now. If you want access to the response from the server, you should now use the payload
property, like so:
return this.get('ajax').request('/posts')
.then((posts) => {
// Do something with your posts
})
.catch((error) => {
this.displayError(error.payload); // `error.payload` will be whatever the server responded with
});
No longer modify null or undefined server response (#232)
If your server response is interpreted by jQuery#ajax to be null
or undefined
, we will resolve that value, instead of turning it into an empty object.
v3.0.0-beta.1
Released v3.0.0-beta.1
v3.0.0-beta.0
Released v3.0.0-beta.0
v2.5.6
v2.5.5
v2.5.4
v2.5.0
Addon Changes
- Add whitelist of files to publish (#137) @alexlafroscia
- Refactor request logic to avoid duplicate calls/Refactor tests (#128) @alexlafroscia
- Allow payload response to be a falsey but non-null or undefined value (#126) @SteelBurgher
- Improve error normalization (#118) @alexlafroscia
- Add service property for default contentType (#116) @alexlafroscia
- Add mixin for Ember Data integration (#114) @alexlafroscia
- Add ConflictError class and AbortError handler (#113) @alexlafroscia
- Allow configuring namespace on per-request basis (#112) @alexlafroscia
Housekeeping
- Document stand-alone usage (#135) @knownasilya
- Move to tests to Mocha (#121) @alexlafroscia
- Improve JSDoc documentation (#117) @alexlafroscia
- Switch to ESLint (#78) @alexlafroscia
- Remove reference to Ember Data (#115) @alexlafroscia
Plus a bunch of dependency updates