We've got a server endpoint that's returning two models (in the example, Apples and Oranges). It makes sense for the server to do the computation in this way, so we ideally don't want to change this response structure. So, image you hit an endpoint /fruits
that returns apples and oranges in a side-loaded fashion. In the example JSBin, we're mocking this response.
So far, so good. However, we want to be able to request Apples or Oranges indepently from the Store (e.g. store.findAll('orange')
or store.findAll('apple')
). We found a way to do this by overriding pathForType
, which works great, but we are double-requesting the data from server when we request Apples and Oranges on the same page. Imagine you were able to swap in different components containing info about Apples or Oranges, and it needs to request itself from the store to ensure we have the data in the store to show the user (or request from the server if we don't have the data).
I've written a quick JSBin that shows the issue. Make sure you open the network tab and filter to 4.js
to see the double request. Here's a screenshot with what you'll see:
NOTE: You might have to do a hard-refresh (command + shift + r) to see the problem. The issue does not seem to occur once the response is cached.
Is it possible to do something like this? We have thought of a few ways to work around this, but none are ideal. We could keep track of the endpoints to request and present a facade for requesting each group of data, but this is not very declarative. Ideally, we'd like to have a way that Ember sees that we already have a Promise to the shared endpoint, and only make one AJAX call to the server.
Thanks for taking a few minutes to look at this issue! If you have any ideas or suggestions, I'd love to hear them in the comments section below.
@blimmer I see what you're trying to achieve. I think you should be able to retrieve a list of on-going requests in the
Store
. However, I feel this is going to be hacky. Another way I'm seeing would be to override theajax
method on both theOrangeAdapter
andAppleAdapter
(create a common Adapter and let both of them inherit from that one) that would set a flagisResolving
before performing the request, and would only perform the actual request ifisResolving
is false. Then you need some support for the adapter to wait until the other request has completed before resolving its promise, so that all the "magic" is contained within the adapter.This is purely an idea of how I think it could work, I haven't actually tried implementing any of it.