Why doesn't store.query() auto-reload a view?

Ember Data
1

I guess maybe my real question is “how is store.query supposed to work?” because I might just be misunderstanding this completely. We use store.query a lot in our app as we need to limit what data is returned from our API endpoints. We also currently use (store.query) polling in some views because we haven’t switched to websockets or anything like that yet.

What I expected was that if I call store.query in my route’s model hook, and then load more data into the store via my poller (also using store.query) that the view would auto-reload with the new data as it does with peekAll or findAll. Unfortunately it does not.

What I had to do to get the desired behavior was to do a peekAll in the model hook, then manage all my polling in the controller. Unfortunately there are a few more complications with that approach in our app (not to mention this issue where store.query was leaking memory) and even if there weren’t, it still seems like an ugly workaround.

I suspect that store.query is intended to work differently than the other store methods and my problem is that I just expect it to work the same, but if it does have a different philosophy of action it doesn’t seem to be well documented. Can anyone enlighten me? Why doesn’t store.query auto-update a view? Is it a misuse of the query method as intended to use it in a route’s model hook? Are there other philosophical differences between a query vs a find/peekAll or find/peekRecord?

Or is store.query supposed to function exactly like the other methods and result in auto-updated views and there’s a bug in ED or in my code?

2

There used to be store.filter(…) method. But its gone because of reasons…

3

Are you sure filter was dropped? It still seems to be documented:

And it doesn’t show up in any of the deprecations pages.

We’re using the filter/query combo with websockets, which is a bit different to the OP.

4

It is marked as private in current ember-data master and I don’t think it is present in ember-data 2.4.0-beta.1.

5

It’s been converted to an addon and supposedly deprecated on the main project. The documentation doesn’t suggest this though. We use it in our app but I’m hesitant to use it in the context I described because the reason it was moved to an addon is that it needed lots of work and had problems like memory leaks. Development on the addon seems spotty at best.

6

Yeap, this is a very very common use case. I’ve seen many ember-data issues overtime where people are begging for this style of paging. I’m not really sure why, but in one issue it was said this won’t be supported by ED.

So we wrote our own QueryArray and QueryManager. In our QueryManager it keeps track of state like offset/count/hasMore/meta/filtering/sorting. The QueryManager has functions like fetchMore which will issue a subsequent store.query to fetch the next page of data, then push it into our custom QueryArray instance.

We use this for “infinite paging” in our app.

7

I know it’s a bit OT, but will there be a straight line equivalent to filter(), that will allow views to respond to items pushed into the store? I can’t spot one.

8

The store#filter method was deprecated in Ember Data 1.13 and removed in Ember Data 2.0 because it causes memory leaks (The store maintains a reference to each RecordArray returned by store#filter preventing the garbage collector form cleaning them up once they are no longer needed).

The Ember Data team maintains the ember-data-filter addon which re-enables the 1.13 store#filter functionality in Ember Data’s store. Today this works by using an internal flag to functionality in Ember Data to support store#filter however, in the future more of the functionality will be moved out of Ember Data and into the addon.