We are considering moving from Backbone to Ember. There are a few issues through I can't get answers to from the docs.
1) Ember-Data caches it's data. Our application is multi-user so other users need to be able to see new records created by everyone. Is there a way around this? I read on another post that when a query string is passed, ember data does not cache data, is this true? If it is, can I then just always send query string and nothing will be cached?
2) Ember data has a single model in the router that appears to be instantiated at route load time. I can see that your can request data from multiple sources by returning an object with many this.store.find calls. Say I have a select element and when you select an option, another select gets populated with items based on the first select (which requires a call back to the server). How would that work, how can I get model data on demand (not at route load time)?
I'm not sure if it answers your question but you can always call
model.reload()
to refetch data from server so you can work with up to date data.
You may want to consider Faye (http://faye.jcoglan.com/), which would let you have a pub/sub setup that could update your store by listening to topics of interest. This uses WebSocket for the streaming interface. You could then put new objects into the store, remove or update existing objects which the server could publish to the client.
Related
I have read Ember docs related to Substates etc and I understand how it works. In my current application my loading.hbs and other child loading.hbs templates work fine.
I just want to discuss a use case.
In my route A, in my model function I do fetchAll for my model.
I go to Route A, First time api request is sent and I see my loading screen.
now I navigate to some other route B.
now I come back to first route A, api request is sent again but this
time loading screen is not shown.
I want to develop my understanding here. Now the second time loading screen is not shown which tells us that store had data so there is no sense to put it on loading and after fetch store sent request to sync with backend.
QUESTION
Now I want to know if this is a default behaviour of Ember with Ember-data?
To show this loading screen, will I have to do something manually?
Ideally what I want is, if on second request data was fetched then show it and at the same time show loader to tell user that it is syncing with backend as well.
I know everything can be done manually, I don't want to reinvent the wheel or do things in non-conventional way. So I want to know best optimized solution for this as provided by Ember which an experienced Ember developer can help me understand.
Thanks in advance.
Now I want to know if this is a default behaviour of Ember with
Ember-data?
Yes, that's the default behavior of Ember data when you do a findRecord or findAll where shouldBackgroundReloadRecord or shouldBackgroundReloadAll event of the adapter respectively, is defaulted to true. You can turn this off by returning false and ensuring shouldReloadAll or shouldReloadRecord respectively are set at true to ensure the request always hits the API and not fetches from cache.
Ideally, showing data immediately on the screen is always advisable as it has a better UX in terms of giving the user a feel that data is already there and that some parts of the data is being fetched. Check here
To show this loading screen, will I have to do something manually?
You may also want to read this
To add further details after my own research, I found helpful and relevant details in Ember docs.This is all about caching.
If records were already there then promise will be resolved immediately that's why I don't see loading screen for already loaded record, at the same time Ember-Data syncs with backend as well and re-render the template.
Ember Model Docs
Caching
The store will automatically cache records for you. If a record had already been loaded, asking for it a second time will always return the same object instance. This minimizes the number of round-trips to the server, and allows your application to render its UI to the user as fast as possible.
For example, the first time your application asks the store for a person record with an ID of 1, it will fetch that information from your server.
However, the next time your app asks for a person with ID 1, the store will notice that it had already retrieved and cached that information from the server. Instead of sending another request for the same information, it will give your application the same record it had provided it the first time. This feature—always returning the same record object, no matter how many times you look it up—is sometimes called an identity map.
Using an identity map is important because it ensures that changes you make in one part of your UI are propagated to other parts of the UI. It also means that you don't have to manually keep records in sync—you can ask for a record by ID and not have to worry about whether other parts of your application have already asked for and loaded it.
One downside to returning a cached record is you may find the state of the data has changed since it was first loaded into the store's identity map. In order to prevent this stale data from being a problem for long, Ember Data will automatically make a request in the background each time a cached record is returned from the store. When the new data comes in, the record is updated, and if there have been changes to the record since the initial render, the template is re-rendered with the new information.
var batch = [someRecord, someRecord, someRecord...]
batch.invoke('save');
If I have an array of 50 newly created records and then invoke save on that array, then Ember Data will make 50 POST requests. I would rather bulk them into a single request and handle that on the API for performance. Is there any way to do this?
Right now it appears I will have to implement this manually with ajax. But if there is a better way, please share.
There used to be a bulkCommit feature in ember-data on the RESTAdapter, but it was removed.
As a workaround for today, the only way I can think of sending multiple records to the server at the same time would be to create custom Adapter that knows how to serialize multiple records then include all of the records you want to serialize in an hasMany relationship on a model.
https://github.com/emberjs/data/issues/2845
So no, you'll need to implement your own solution in your own adapter (or just straight up make an ajax call from wherever if you're feeling naughty).
Function:
App.Fullquiz.find(5)
queries my server api for this record, but this record is already available in the model.
How to get this record without querying the server?
I think you can use
store.getById()
http://emberjs.com/api/data/classes/DS.Store.html#method_getById
Get a record by a given type and ID without triggering a fetch.
Good luck
I have a real time emberjs app. I'm trying to implement a real time notification system, where any updates on one client will be propagated over all the other clients. Hence all the changes happen in real time over all the browsers.
I have Labels extending DS.Model objects. Every time one client creates a new record, the other clients run App.Label.find() which updates the record array correctly. Now the problem is when a client deletes a record and commits the store, App.Label.find() will no remove the record on the other clients. So my question is:
Is there a way you can update your local records from a persistent layer, which will remove all the deleted records?
I got it done by checking for .isDeleted
{{unless "model.isDeleted"}}
show only not deleted models
{{/unless}}
I was told that in order to not make a request all the time, one can use .all() method to load data that is kept in the store. But how does Ember deal with cache? I have a couple of questions.
How do you control cache? When do you use .find() and when .all(). Do you use .find() and then .all()? For how long?
Does .all() have some expiration date so that after some time it can make a new request? Or it uses Local Storage so that I have to clear it manually?
Suppose that I have some data I'd like to refresh only once a week? How should I go about this? Now every time I enter or re-visit the same route a new request is made. How can I avoid this?
So will start by answering question from your comment:
I'd rather to know how can I load data when an app starts (not via routes as I don't have to update it so often). Is it possible
So OK technically this is still via routes, but the best way to load data when an app "starts" is via the Application Route's model hook.
App.ApplicationRoute = Ember.Route.extend({
model: function({
return App.Post.find();
})
})
The router will wait for promise returned by find() to resolve, so you can be sure that response from server has come back before any other routes are entered.
How do you control cache?
Mostly you don't worry about it. You can refresh() an individual record after some timeout if needed.
When do you use .find() and when .all(). Do you use .find() and then .all()? For how long?
Depends what you want to achieve. In our app we use find() in the application route, then either all() or a filter() in other routes.
Does .all() have some expiration date so that after some time it can make a new request?
Nope. It will never make a new request
Or it uses Local Storage so that I have to clear it manually?
It does not use local storage, records are in memory. So for sure an F5 will clear the cache.
Suppose that I have some data I'd like to refresh only once a week? How should I go about this? Now every time I enter or re-visit the same route a new request is made. How can I avoid this?
So OK let's assume you use find() only in the application route, and that user keeps browser open for 1 week and the records have expired. There are many ways to refresh, what's easy/best depends on if they all expire at once or if they time-out one at a time.
Have some timer checks for expired records and calls refresh() as needed.
Have a Ping model that you update on some schedule. When server responds to update it can sideload any changed records.
Or can just refresh the browser once per week (via window.location...)
What you call cache is the content of the store. There are usually 2 ways to update the store to reflect changes made on the backend side:
the change happens with a user interaction/call to the server. If you update mulitple records on the backend side, you can sideload them with the response of that request.
the change happens asynchronously on the backend side (background job). You can use a websocket to push those changes to the client.