Identical to 4.0.0; release made to remove deprecation warning when installing the latest version.

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 from master, including no new behavior from v3.1.2. This means that, if you've already upgraded to v3.1.1 or later, you can safely move to v4.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.

Features

• Expose error codes #318 (@spruce)

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.

Changlog

• errors: Recognize HTTP status 0 as AbortError (#243) @Turbo87

Note: This release was not cut from master, which contains breaking changes in preparation for v3.0.0

Changelog

• Clone options object before modifying it (#226 and #227) @gnapse

Note: This release was not cut from master, which contains breaking changes in preparation for v3.0.0

Changelog

• Ensure that requestData has the correct method and type (#231)

Note: This release was not cut from master, which contains breaking changes in preparation for v3.0.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