Add mixin for Ember Data integration

[alexlafroscia]

@taras and I worked on this PR together, to introduce a mixin that can be added to an Ember Data adapter. This should be seen as a first step toward solving #85.

When included, the mixin will use the ajax service for networking, instead of the code provided as part of the RestAdapter. Since the ember-ajax code was based on the code that it is now replacing, bridging the gap here was pretty straightforward.

The one thing that I'm not sure about right now is the naming of file that the mixin is found in. I think having it simply called ajax-support is a little ambigious, especially when the implementation file is called ajax-request. They're just a little too similar. I'd love suggestions on a better name.

[taras]

This looks great. We need to describe the migration path for people who're looking to adopt this. It can serve as a transition path towards using Ember Ajax with Ember Data. Primarily, we need to show how error handling needs to be adjusted to work with Ember Ajax in Ember Data.

On that note, we'll need to add Ember Data Error object detection to our error detection helpers.

[alexlafroscia]

Yeah, agreed. Definitely need to add some docs, but I'd rather not just add more to the README... There's a lot of information in there already. Maybe usage example in the mixin file? I can add some of that.

What's the right way to add detection of the Ember Data errors? We'd need to import the errors and then do an instanceof check, so Ember Data would become an Ember Ajax dependency?

[taras]

What do you think about moving the mixin to /adapters/ajax-support-mixin.js and creating a README.md file there with this information.

[alexlafroscia]

I think that's kind of confusing, having a mixin in the adapters directory. It feels like straying from the convention without a strong reason.

[taras]

That's kinda how Ember Data does it, Not exactly, but similar https://github.com/emberjs/data/blob/master/addon/-private/adapters/build-url-mixin.js

[alexlafroscia]

I see what you're saying... But that's also a "private" module, not public. To me, addons have a given structure and I think adhering to the convention is a better way to go.

[taras]

@alexlafroscia ok, what do you think about putting the upgrade instructions into the README for now and later we can give it a section on a documentation site.

[taras]

What's the right way to add detection of the Ember Data errors? We'd need to import the errors and then do an instanceof check, so Ember Data would become an Ember Ajax dependency?

@alexlafroscia that's a great point. I'll think about this today and get back to you.

[alexlafroscia]

I'm wondering if it's really necessary to add the ED error checkers... I mean, if they're opting into using the Ember AJAX mixin, they need our error checkers for network errors. If the ED networking code isn't being run, how do those errors crop up?

[taras]

Yeah, you're right. Wi this strategy, it's not necessary because the assumption is that we will be running all of the Ajax code through Ember Ajax with the mixin. We should make this available as beta and have people try it.

[alexlafroscia]

Cool. I'll add a commit with some docs and we can cut a release with this. Would you want to include this as part of 3.0-beta.1? Or 2.5?

[taras]

Let's stick within 2.x series for now. So, 2.5-beta.1?

[alexlafroscia]

@taras Can I get one last check-over before pulling this?

[taras]

This should alias namespace, right?

[alexlafroscia]

Good find, thanks!

[alexlafroscia]

@taras can I get one last once-over on this before merging? I fixed that thing you caught.

[taras]

The mixin does this, we don't need this line and we need to move `namespace: 'api'`` to the service. Right?

[alexlafroscia]

RE: the ajaxService line, I know we don't need it. I just wanted to illustrate that you can specify the service to use, but maybe that was confusing? What do you think @taras?

---

RE: the namespace line, I wanted to show how you can specify certain things on the adapter. Otherwise, the whole adapter is just

export default JSONAPIAdapter.extend(AjaxServiceSupport);

which isn't much to show, really... Although maybe that's okay? What do you think?

[taras]

Yeah, I think that's fine. We want to show people that they can allow ember-ajax to take care of everything related to the request.

[alexlafroscia]

Alright, I'll update the example code to show a "minimal" example, and also include an "extended" one that's similar to what I originally put. Sounds good?

[taras]

Other than the 1 comment, it's good to go.

[dwickern]

This appears to add the namespace twice: first in the ember-data adapter and again in the ember-ajax service.

[alexlafroscia]

@dwickern can you make a new big ticket with some more information?