I'm working on a client-server application built with angularJS. For data exchanges I'm using HTML5 WebSockets. My server has a dataset that also exists as copy on my client. I refer to this as my model as here is all the raw data.
Via WebSockets I'm able to get/set those data. There may also be random data updates from the server (push).
I'm using different custom services/factories to provide a layer that allows all my modules to create data packets and send them to my server. They also provide wrapper for my model and may change the reprasentation of this data in the view (like timestamps converted to real time, etc.). I have different controllers that access those services to reach for functions or values.
I hope this describes my current architecture good enough. Now my question:
On data updates from the server I update my model data and then inform all modules that make use of this data with the new value. It's like:
Server -> Model -> ViewModel -> View
That works fine and I guess it's ok from the view of the MVVM pattern.
But I'm struggling a bit with publishing updates from the view. At the moment it's like:
View -> ViewModel -> Model (at first update the model)
|
-------> Server (after that send the data to the server)
So, when there's a user updating data in the view, the viewmodel gets updated via angulars data binding. Then the viewmodel calls a service to create an output packet that will be sent to the server. When the packets gets commited my model will be updated with the new data and the packet will be given over to my websocket connection, updating the data on the server.
Is this the/one right way to do so? Is it ok to update my model even before the packet is sent to the server? Should I send the update to the server, wait for an OK and only then update the model?
Related
We have a mobile app where the client gets a bunch of data from the server, stores and uses that data on a local db, and then syncs the new/modified data back to the server. My team is very concerned about the reliability of the data and want me to verify that syncing went correctly by first sending a "sync manifest". This would contain things like the number of rows that are to be sent so that can be compared with what the client actually stores.
My question is: Is there a point to doing something like this? If there is an actual error either when sending the request or storing the data we will get that error message. Is there a point to having this kind of extra verification when sending data and if so what would you look for?
I have a Node.js server with Angular on the client side. I'd like the following to happen.
User posts a large JSON to /postjson. The large JSON object is used in the controller to render some data visualization. I don't want to store the JSON in a database, it should disappear when the window closes. How do I pass this data to the controller?
A potential solution is to use a route /api/postjson and receive the JSON server side. But I don't want to store it. How do I then pass this object to the controller/service/provider whatever is required?
I am very new to angular and this one is striking in my head a lot. So scenario is : Suppose angular http returns me model containing array of object like:
[{name:"Ankur",lastName:"aggarwal",updation_date:"23-08-2014"},{name:"xyz",lastName:"abc",updation_date:"29-08-2013"}]
Out of this updation_date is not required but coming for some reason. So is it right to update the array with third object without creation date like {name:"def",lastName:"jbc"} . Is it a good practice or array object model should be consistent?
Also what should be the approach? Update the model array first so binding take place instantly, then send it to the server or send it to server and get the updated object? Might be basic one but very new to angular and JMVC.
Is it a good practice or array object model should be consistent?
It depends , if backend expects all array entries to contain updation_date then you have no choice and are forced to add some sensible default value. However, if possible then avoid sending too much unnecessary data from backend since it impacts application performance(like data transfer, adding unnecessary logic to generate sensible default values, etc.)
Update the model array first so binding take place instantly, then
send it to the server or send it to server and get the updated object?
If the nature of your application permits reverting model value when save is unsuccessful then just go ahead with
0.Perform data validation, and make sure valid data is supplied to the backend.
1.Update model.
2.Send data to backend
3.If something bad happens then execute error handling depending on app needs
However if presenting consistent value in the GUI is uttermost importance(e.g. finance applications) then
0.Perform data validation, and make sure valid data is supplied to the backend.
1.Show some message to user like "saving"
2.Perform ajax request
3.If successful, update model, else execute error handling depending on app needs
It depend on your error handling.
As saving on the server-side might be not successful, you should take it into consideration.
My approach is to
Update angular object immediately
Then send AJAX request to server and
Wait for response. If error happen during server save, you shoulde:
revert values,
repeat AJAX
show information to user.
In Backbone terms, What is the correct scheme to persistently update a model which is a member of a collection and reperesented in the user interface?
By utilising a DOM event and method in the view.
Then grabbing the id of the element to be processed by from the event objects, eg. from click.
finding the model in the collection, by findWhere.
Then using set on the model changing attributes.
Then using save() on the model to update the model on server side and client side.
But one may need to wait for success on server side process and only then update the client side model and collection. This can be done by {wait: true} in order to wait server response, but does this mean if and only if the server process succeeds to persist the model in the db this attributes will be set in the client side model. What if it fails on server side what about the preceding lines that set() the model found.
Also adding the new state of the model into the collection.
Lastly, re-rendering the view with the new state of the collection.
It sounds a little bit like you may be wanting 2-way data binding.
Backbone.Stickit is a great plugin for that.
I'm persisting my model from my controller via a call to this.get('model').save(). This results in a PUT to an endpoint that just returns a 200 message and nothing further. On the server side however, some custom rules are in place that are changing the data so that it's different than what Ember sent to the server. This puts my UI and my persistence tier into an inconsistent state.
What's the correct way to make sure the UI reflects what the correct state of the data after it was persisted to the server? Should my server-side endpoint return the updated model? I've tried just calling this.get('model').reload() after the save() but the UI isn't updating. When I did this I could see that it's asking and getting the new model from the server but as I said, it's not reflected in the UI.
I feel like there's some knowledge fundamental to Ember that I'm missing. Thanks for the help.
I guess that you are not waiting for the record to complete the updating process.
http://emberjs.com/api/data/classes/DS.Model.html#method_reload
So this would be:
this.get('model').reload().then(function() {
console.log("Now I am ready !");
})
Always remember that javascript is async.