I'm wondering how favorite, subscribe or like buttons work.
I don't understand something.
For exemple:
A user like a post with id 243.
A ajax request is sent to the server with the id of the post (243) [here comes back end stuff, the user's favorite list is updated, including that post] and the server sends back a success response.
Now, how I suppose to deal with modifying the like button to actually display that is liked (permanently, including refresh).
How can I achieve that in Vue JS. How things get updated? I don't understand this part.
If the server sends back a successful response you can increment the number that is already there.
This initial number is something you have gotten either through a prop, directly from the server or through an initial AJAX request.
If you want to "permanently" update the amount of likes on your button you have to persist it to a database(or some other storage medium). On you server you could have a route that accepts a post id as an argument and increment that specific user post:
/incrementlike/243
That is where you would make a POST ajax request to. Most of the time in an MVC framework you would have a controller action/method mapped to this route that holds the logic to respond to this call.
If you are interested in the part that happens after you make an AJAX request to the server to increment your like on the backend side, I suggest you read up on routing or MVC structure.
How you would do this is really done on a case by case basis. It really depends on a number of things, for example what your backend does to a post when it is liked.
If you would like a general 'explanation' to the process I attach it below, this is not really Vue specific, but the general idea is the same:
Frontend side:
Modify the local state of you post to set the proper flag, ex. post1.liked = true immediately when it is clicked, before sending the request to the server.
Make sure your GUI represent this change. ex. Base the color of the button on the property 'liked' of each post.
If a failure response it received from the server, notify the user and allow them to 'try again' or something similar.
When refreshing the page, make sure changes are fetched from the server, If you have done the backend part correctly, the modification of the state of the post will be correct in the data you receive from your backend (post1.liked will be true)
Backend side
When the request comes in, modify the state of the post the correct way and make sure that next time the post is fetched, the new state is sent.
Related
As the frontend application has its own state, now the user updated his/her contact and the frontend state got updated and PUT API is called to update with the current state.
So while updating the user contact details through PUT call, should another GET call be made to fetch the user details or should the current state is enough for the frontend.
Just curious what is the advised pattern to follow.
Your PUTrequest should send a 200 ok so you know that the data frontside is now valid.
You could of course (this is what I do in some instances), is send the object back as a response of your PUT request with a 200 ok. With this object you can update your view as needed, ensuring that the object is exactly the same as the one on the server side.
A GET is not needed in this case.
Another get request is not necessary, If you really want to maintain the state from backend (which is also not necessary), you can respond from the server to the PUT Request with the state. This may come in handy if to know execution is successful.
After update(PUT call) you should make GET call to get the details from DB and display in the front end.
So that the user will get to know that the details are successfully updated.
OR
if you want to show update success message then in the backend you can return the updated values in PUT API call response and you can use this response to show details without making GET API call again.
OR else
Based on PUT call success response you can show the details that you set in the state without making a GET call
Not required.However,in the PUT request itself you can send the changed state.And you can concatenate/update the frontend state with the db state using filter method.In order to keep your frontend state intact with the db.
After a user login, the data is stored on a client side.
There are some pages which don't require a logged user to be viewed...
for example, I have a route on node.js which render a profile page through a URL parameter.
app.get("Profile/:id",function(req,res){ //render page and send it.}
anyone can see this page... but here is the situation... in my app, users can post notes on this pages so they can see it later. So the idea is, if a user is logged in when the user access that page he can see all his notes.
the data of the notes are in server side.
So my question is...
how can I pass the user data into app.get("profile/:id "... function so that the notes can be loaded and sent when is rendered
...
one thing is important to be known. I have a solution in wich I pass a unique key though the url which references to the active socket of the user so that the data is post on a json, is there any other way to pass data from client to server before the page is rendered?
After several days I have manage to achieve the resolution of this question
The idea is to have a Session tipe variable like $_SESSION in php.
you need express-session npm and assign session on require parameter on a express post function. After you have set a value, every time that browser change from location, you can extract that same session variable and use the data to post a response when you are rendering.
I used ejs to render.
In the next link, there is a full tutorial to achieve this.
https://codeforgeek.com/2014/09/manage-session-using-node-js-express-4/
On page load, say for a particular route for (e.g. https://localhost:8000/home/index), a service is called and the response from the service is rendered to the page at the client side.
On the same page, I have a link that pops up a Backbone.js modal and from the modal a click event triggers which hits another url (e.g. https://localhost:8000/home/index2) upon which another service call triggers and the response is rendered to another html page.
On the same html page, I want to display a value which I got from the first service call on page load. However, I am unable to retain that value as there are two different requests each time. Hence, I cannot even append the value from first response to the request object and use it a second time.
You can use JavaScripts Web Storage API to storage information on client browser.
MDN Web Storage API
For example, If you are on the first screen and call a service, store the service information on localStorage
localStorage.setItem('firstService', serviceResponseObject);
Once you are navigated to second page, you can use localStorage to read to previous service information
localStorage.getItem('firstService');
There are multiple ways to store state between requests.
From the server, if you're using say Express etc, you could store the result in a Session. Or you can even store state in the requests query params, or from a POST request.
You could also store some data on the client end, using say Cookies or localstorage.
What you choose really depends, it might be best if you explain in more detail what sort of information your passing between pages.
If it's just a simple value, I would go for using query params.
eg. Just place in your url https://localhost:8000/home/index2?value=123, and then from node.js, req.query.value would have your value.
I have a JavaScript application that regularly saves new and updated data. However I need it to work on slow connection as well.
Data is submitted in one single HTTP POST request. The response will return newly inserted ids for newly created records.
What I'm finding is that data submitted is fully saved, however sometimes the return result times out. The browser application therefore does not know the data has been submitted successfully and will try to save it again.
I know I can detect the timeout in the browser, but how can I make sure the data is saved correctly?
What are some good methods of handling this case?
I see from here https://dba.stackexchange.com/a/94309/2599 that I could include a pending state:
Get transaction number from server
send data, gets saved as pending on server
if pending transaction already exists, do not overwrite data, but send same results back
if success received, commit pending transaction
if error back, retry later
if timeout, retry later
However I'm looking for a simpler solution?
Really, it seems you need to get to the bottom of why the client thinks the data was not saved, but it actually was. If the issue is purely one of timing, then perhaps a client timeout just needs to be lengthened so it doesn't give up too soon or the amount of data you're sending back in the response needs to be reduced so the response comes back quicker on a slow link.
But, if you can't get rid of the problem that way, there are a bunch of possibilities to program around the issue:
The server can keep track of the last save request from each client (or a hash of such request) and if it sees a duplicate save request come in from the same client, then it can simply return something like "already-saved".
The code flow in the server can be modified so that a small response is sent back to the client immediately after the database operation has committed (no delays for any other types of back-end operations), thus lessening the chance that the client would timeout after the data has been saved.
The client can coin a unique ID for each save request and if the server sees the same saveID being used on multiple requests, then it can know that the client thinks it is just trying to save this data again.
After any type of failure, before retrying, the client can query the server to see if the previous save attempt succeeded or failed.
You can have multiple retries count as a simple global int.
You can also automatically retry, but this isn't good for an auto save app.
A third option is use the auto-save plugins for jQuery.
Few suggestions
Increase the time out, don't handle timeout as success.
You can flush output of each record as soon as you get using ob_flush and flush.
Since you are making request in regular interval. Check for connection_aborted method on each API call, if client has disconnected you can save the response in temp file and on next request you can append the last response with new response but this method is more resource consuming.
Typically an ajax interaction would involve sending the request, providing feedback to the user that the request is in process, then once the response arrives handle it.
Waiting for the response is obviously unavoidable when the next action requires the data sent from the server but what if the interaction is an update to the some data on the server such as sorting the order of a list. Would it be bad practice to assume success? So you'd make the request and simply update the DOM based on the assumption that the sort will be successful. I'd imagine you'd then have to provide a rollback method should the request fail as well as notify the user but 99% of the time the request should go through and appear instantaneous to the user.
Is this a common pattern and are there any other factors that should be considered other than a rollback and notification method?
Any advice would be much appreciated,
Rich
You probably want to take a look at the command pattern http://en.wikipedia.org/wiki/Command_pattern. It looks like you want to modify some data and assume that the server gets modified as well. If the AJAX handler fails than you can rollback the command (and notify the user).
If the user is to receive feedback about the success or not, then it would be bad practice to assume success.
Just return a success/fail response from the server, and let the user know that their action was successful. You're not really losing anything by this extra trip back from the server, and any request could potentially fail.