I am hoping for some advice around data-fetching strategies in an ember-data app.
What are the advantages/disadvantages and tradeoffs between the following two strategies:
Server fetch on route transitions - e.g. this.store.findAll('post') on index routes and this.store.findRecord('post', id) on show routes.
Cached data strategy - e.g. this.store.findAll('post') in the ApplicationRoute, with this.store.peekAll('post') in any route that needs the data (this.store.peekRecord() if only need a single item).
What is more common? Why? What is the disadvantage of using the peekAll strategy, and keeping all lookups on the client?
As far as I know the difference between peek and find that peek will not make request to the server if no appropriate data in store. But both commands will take data from store (without additional requests) if it exists in store.
Right, peek doesn’t make a server request. So, if you know a parent route will fetch the model from the server, then peek on the child route. Also, you can tell a find request not to ping the server if the requested model already exists in the store, that way you’re safe either way.
I actually pre-load all records for a few “common” models (used throughout the app) on the application route. That way I know I can safely use peek everywhere else. The other nice thing with peek’s is they return the requested model right away, instead of a promise.
I thought that in current versions of ember-data, find will still go to the server for new data, but it will used cached data for a first render of the page and schedule a subsequent background update.
If this is still true, you’d have to figure that using peek everywhere (with initial fetch in the application route) is going to greatly decrease API traffic. I’m just not sure what the tradeoffs are in terms of stale data and the fact that using peek the whole app is going to be built assuming synchronous responses, and (may?) be hard to refactor later into an asynchronous response from find.