Allow query parameters to be specified when finding records via Ember Data's Store

[HeroicEric]

Rendered

[bmac]

before adapterOptions were attached to the snapshot we considered passing adapterOptions into findRecord as an extra argument. In the end we decided to attach it to the snapshot in order to make it work with colaced requests.

I think we should follow the same pattern here and copy query into adapterOptions.query. This means

const articles = this.store.findAll('article', {
  query: {
    include: 'comments'
  }
});

would be equivalent to

const articles = this.store.findAll('article', {
  adapterOptions: {
    query: {
      include: 'comments'
    }
  }
});

[HeroicEric]

Nice! I wasn't aware that those were already being passed via the snapshot. I'll update the RFC.

[HeroicEric]

@bmac I just updated this to nest query under adapterOptions in the examples but I think I just realized that you were suggesting to keep query as the as option to findRecord but inside findRecord copy the query over to adapterOptions.

So the api would still be something like:

this.store.findRecord('post', 1, {
  query: {
    include: 'author'
  }
});

but that query would be copied over into adapterOptions before the snapshot is created and sent to the adapter. Is that what you meant?

[mwpastore]

It would also be useful to be able to supply adapterOptions when fetching associated records, e.g.:

this.store.peekRecord('foo', 1).get('bars', {
  adapterOptions: {
    include: 'quuxes'
  }
});

And/or when defining relationships:

// app/models/foo.js

import DS from 'ember-data';  

export default DS.Model.extend({
  bars: DS.hasMany('bar', {
    adapterOptions: {
      include: 'quuxes'
    }
  })
});

[bmac]

Hi @HeroicEric I'm a little weary about the potential for the query parameter to load a record in an incomplete state. My fear is that a record may be loaded into the store with fields missing when visiting one route then retrieved from the cache when the user navigates to a new route.

I would like to start with a more conservative API that only exposes the ability to specify the include parameter when making a find request.

const article = this.store.findRecord('article', 1, { include: 'comments' });
const articles = this.store.findAll('article', { include: 'comments' });
article.save({ include: 'comments' });
article.destroyRecord({ include: 'comments' });

This still has the potential for the same problem of expected relationship data not being loaded when loading a record from the cache, however, Ember Data has better tools (namely async relationships) for dealing with this case then it has for partially loaded fields.

[mwpastore]

That sounds great to me, @bmac. Thoughts on extending that functionality to relationship fetching? Have you seen the ember-data-has-many-query add-on?

[luxzeitlos]

I would love a official ember way to query data with a cache.
At the moment I've written my own hack here.

It hacks into the store and asks shouldReloadQuery on the adapter if the query result is cachable.

Something to notice: Think about how to handle with pagination and infinity-scroll.
If you query the first page, then load the second, you want to access both if you access the cache.

[HeroicEric]

This was added in warp-drive-data/warp-drive#3976