Ability to use query string params with store.find()


#1

Recently the following issue was opened https://github.com/emberjs/data/issues/1576, basically asking to allow query params to be specified with find and id. store.find('post', 1,{include: 'comments'}) this would also allow to do things like request related documents

I opened the following pull-request https://github.com/emberjs/data/pull/1579 supporting query params with store.find and also allowing to pass a query to record.reload().

I’m myself requiring this not just for loading related documents but for handling partially loaded records.

Currently people is doing stuff like having two different models with 2 different endpoints, for this kind of situation. See for example

So is this something you would like to see built-in in ED or is just an edge-case particular to a few of us?


#2

I would like to see this with the exact use case that you specify. It would be nice to request which related documents that you require in the query string rather than just always including them in the API response.

Adding the functionality in won’t really change how the find and reload functions work currently so I don’t see any issues with adding it to ED master. It seems rather hacky to have to have different endpoints to do this.

Adam


#3

Yes I would like to see this as well. However I have had success setting up my model hooks on show and edit to do a full query like so.

#edit/show route
model: function(params) {
  params = {
    id: params.invoice_id,
    includes: ['line_items']
  }

  return this.store.find('invoice', params ).then( function(invoices) {
    return invoices.get('firstObject');
  });
}

In this case I am also partially loading all invoices. So my Index model hook looks something like.

model: function(params) {
  params = {
    fields: ['id', 'total', 'description', 'date']
  }
  
  return this.store.find('invoice', params );
}

#4

I am using the same solution as @arenoir.

Being able to pass a query object to store.find('invoice', 42, query ) and have it return a DS.PromiseObject instead of DS.PromiseArray, would be handy so we can skip the ..get('firstObject') in the success handler.

Caching wise it should just behave like findQuery (no caching).


#5

+1 for an option to return a DS.PromiseObject instead of DS.PromiseArray