How many instances of adapter:application may there be?

1

I just came back from a third party persistence library to ember-data, and I was just running into something I entirely did not expect. Inside of my only adapter (which is application.js), I was storing a reference to the socket my application is using. After migrating to ember data, I noticed that the first request my app was making was using an entirely different adapter than the second request. Is this expected behaviour and there should not be any state kept within the adapter, or is there something strange going on?

2

I think this might be related:

Pretty early in my application, I am getting the application adapter in a service, which manages the initial authentication in case a persisted token to automatically log in is found:

this.set('adapter', this.get('container').lookup('adapter:application'));

The request I am sending is quite different from what ember data expects. I am just sending the users email and the token and I am getting back the whole user data.

I guess, in this case I am getting a different instance of the adapter than the one ember data is using.

3

I think generally speaking, you’ll only have one adapter:application instance while the app is running … but that said, I don’t think you can count on this behavior being constant for several reasons.

  1. Adapters are no longer configured as singletons at the container level. That means:

    // returns false container.lookup(‘adapter:application’) === container.lookup(‘adapter:application’)

  2. There was some work done about a year ago to make it possible to have multiple stores. This work involved making the adapters stateless. More on that: Store Managed Adapters & Serializers by jmurphyau · Pull Request #2617 · emberjs/data · GitHub

So to answer your real question, I have this exact use case too and here is what I do:

store: Ember.inject.service(),

auth() {
   let appAdapter = this.get('store').adapterFor('application');

   /* do auth */
}

Also, you’ll notice that adapterFor does return the same adapter instance for duplicate calls.

// return true
this.get('store').adapterFor('application') === this.get('store').adapterFor('application');

That said, you should treat adapters as stateless.

Hope that helps,

– Wesley

1 Like
4

Ah, Thank you! I have been trying something similar, but I was querying the store for the adapter for my model, which also returned a different instance of the adapter. The code you posted seems to work fine

In particular I was having issues with having callbacks registered multiple times for the different instances of the adapter on the single socket. It’s kind of difficult to handle all situation where there just might be multiple instances of the same adapter. It would be great if this could be documented more clearly.

5

Yeap. I couldn’t agree more.

6

Would one of you be willing to send in a pull request with some additional details for the docs? We on the docs team would greatly appreciate it!

7

I don’t want to speak for Hummingbird, but what I was referring to is documentation for the whole lifecycle of server requests. AFAIK the old guides (I know new ones are coming) only mentioned ajax calls through Ember-Data lifecycles (CRUD). This doesn’t feel like a small PR, it feels like an overall kind of posture. Perhaps if the network service lands it’ll provide a good foundation for this.

8

Hmm, agreed, that’s a larger piece of work. Would you mind filing an issue about that? While there are new pieces being worked on regularly for the guides, I haven’t heard anything about documenting the lifecycle of server requests. So having an issue explaining what is missing would help make sure it doesn’t stay missing :wink:

9

Yeah, I would be willing, but I have no idea why things are the way they are, how that makes sense or under which conditions it might happen. Right now, I am just able to say that it might happen and I am afraid I won’t have the time to dig deep enough to find out about all those things at the moment.

However, I agree with workmanw, these would make a lot of sense for the whole lifecycle, and should not only cover the adapter. If things aren’t singleton anymore and it isn’t clear when it is instantiated (it is obvious from reading the project code) it should be clear when things are instantiated, how many will be there and how long they live in my opinion, but I understand that this will be a lot of work to document.