I’m working on a ember-data driven application but I want to use raw ajax calls to hit search endpoints to get values for filling in ember-data instances. As the user types in values I will receive a list of possible values from the backend. I’ve been thinking long and hard about where to put the Ember.$.ajax calls and I don’t know what’s best: route, controller, component, adapter? Here are my general thoughts on each of those:
Route: keeps all the API calls in one place. Highest level possible for handling application ajax requests. Very from away from where the type. Not a great spot to keep the URL building information.
Controller: good spot for observing the changes to the typeahead text input. Not a great spot to keep the AJAX API request logic because it’s not consistent with how data is typically loaded.
Component: would keep all the logic together but would again not where API calls are usually made. Maybe since AJAX calls are not ember-data requests (aka, don’t need the store) it’s OK to keep them encapsulated here.
Adapter: good spot for knowledge of how to build the URL to the backend. But I would want it to emit POJOs, not data objects. Is that OK?
How is everyone managing helper AJAX calls to fill in the ember-data values? I want something that’s idiomatic so new devs come in and don’t go WTF
To add to that, I find it’s often useful to throw a denounce around the Ajax call to ensure you don’t fire off a jillion Ajax calls while somebody’s speed typing.
So you’re thinking the best place to build the URL (and hold the smarts about how the API is built) is in the controller? Sounds OK to me, I really appreciate the encapsulation, but maybe I’d want to pass in a reference to the adapter or some service object that builds the URLs?
Yeah, the debouncing, etc should be handled. I’m worried about where to put the smarts for the API. ember-data uses adapters to encapsulate the URL-building and relation building, which I like, but AJAX calls for typeaheads different enough to be a separate design concern.