I currently use res.error('message'); to show a message on the page that I load using res.redirect(url); in my Express/Node.js app.
Is there another way of showing a message, if I don't want it to be error message, but something else?
Thanks!
res.redirect(url) will actually issue an HTTP 302 redirect which will cause your user's browser to make a brand new request for whatever page is specified by the value in the url variable.
If you want to show the user a message after the redirect, you would need to store that message somewhere that will persist between requests and then read it on the subsequent page load. This is often accomplished by storing the message in a cookie or in server-side session state and is often referred to as flash storage.
The express-flash middleware can help you with this, although I'm not 100% certain of its compatibility with Express 4.
You also might find this SO question helpful.
You could use one of the other res method to send the message:
send('message') or end('message') seems being the most appropriated.
You could otherwise display some page with .render (view, templateParam).
More details here, on express request documentation
Use flash. They provide templates for error, success and informational messages. Very useful if your users are coming in with web browsers.
Related
I am developing a single page application that has a client side router. so although the base url to run the application will be either http:://example.com or http:://example.com/index.html - skipping the domain name that is routes '/' and '/index.html'
But somewhere in my application, because of my client side router, I may call up a route something like '/appointments/20160113 and the client router will redirect me to the appropriate "Appointments Page" inside my SPA passing the parameter of todays date.
But if the user calls directly http://example.com/appointments/20160113, I am led to believe that the server should respond directly with /index.html so the browser doesn't get a 404.
I am building the server using nodejs (specifically the http2 module, but I don't think that is very important, and my examples don't use https, although with http2 they do). I just tried changing the server so if its hit with an unknown url it responds with the index.html file.
However, the browser sees this as its first response and then makes requests for the rest of its attached files relative to the url (so for instance follows up with /appointments/20160113/styles/main.css). This leads to an infinite loop, as the server responds with another copy in index.html (and immediately gets a request back for /appointments/20160113/styles/styles/main.css ).
Its too early in the lifecycle of the page for the javascript to be running yet (and specifically the router software), so clearly the approach is too simplistic.
I have also written the client side router (using the history api) so I can change things if I need to.
How should this situation be handled. I am thinking perhaps a 301 redirect to /index.html or something and then the router's initial dispatch knows this and can do a popstate or something. I ideally want to support the passing of urls via external means between users, but until I actually tried to implement it I hadn't realise the implications.
I don't know if this is the best way or not, but having not received any answers on here, I decided to try a number of different ways and see which worked out the best.
Each way involved doing a 301 redirect to /index.html, and then providing the url from which I was redirecting via different mechanisms
This is what I tried
Setting a cookie with a short expiry date the value of which was the url
Adding a query string with a ?redirect= parameter with the url
Adding a #fragment after /index.html with the url
In the end I rejected 1) because chrome wasn't deleting the cookie after I had used it and making the value shorted lived depends on accurate timing between client and server. The solution appeared too fragile.
I tried 2) and it was looking good until I came to test it. Unfortunately setting window.location.search causes a page reload, and I was really struggling with finding out what was happening. However, what I discovered in 3) about mocking could well be provided to a solution based on 2) so it is one that could be used. I still might return to this solution as it "feels" right to me.
I tried 3) and it worked quite well. However I was struggling with timing issues in testing since my router element was using the #fragment during initialisation, but I couldn't set the window.location.hash until after the router was established in the test suite. I wanted to mock window.location.hash with sinon so I could control it, but it turns out you can't
The solution to this was for the router to wrap its own calls to window.location.hash in a library, so that I could mock the library. And that is what I did in the end and it all worked.
I could go back to using a query string and wrapping window.location.search in a library call, so I could stub that call and avoid the problems of page reloading.
I am running an express app and in a section I need to pass the page I'm serving some data. I am sending the file with the res.sendFile() function. I would prefer it to be in the form of query parameters, so that the page being sent is able to read them easily.
I am unable to run any templating tool or set cookies since the files are part of a cdn uploaded by users, so the information has to be contained so that it is not easily read by other files also served from my server.
Query parameters can only be sent by doing a redirect where your server returns a 3xx status (probably 302) which redirects the browser to a different URL with the query parameters set. This is not particularly efficient because it requires an extra request from the server. See res.redirect() for more info.
A more common way to give data to a browser is to set a few Javascript variables in the web page and the client Javascript can then just read those variables directly. You would have to switch from res.sendFile() to something that can modify specific parts of the web page before sending it - probably one of the many template engines available for Express (jade, handlebars, etc...).
You could also send data by returning a cookie with the response, though a cookie is not really the ideal mechanism for variables just for one particular instance of one particular page.
Why should we use a flash/message middleware like connect-flash? What benefits/values does it brings to a nodejs web application?
Can't we simply send a response object instead of using it?
Does it complement a front-end notification tools like toastr?
"Flash" middleware helps you send information (an object, array, etc.) to a request you are redirecting to.
Example: you are displaying a list of users and want to delete a specific user. In your DELETE /users/123 handler you'd probably want to redirect to GET /users to display all remaining users. But probably you also want to display a message "User 123 deleted successfully".
Flash middleware makes it easy to send this message to the next request handler.
The alternative would be to:
Encode the information into the URL you are redirecting to.
Store the information in your session. But this is exactly what flash middleware does, so it's probably easier to use one out of the box instead of implementing it yourself.
I have used express-flash which is used by the server to send flash messages to the rendering engine. If you are using jade as your rendering engine, you can use a partial jade file to detect the presence of these flash messages and show appropriate animations or display. Whereas on the other hand if we are using a front end notification tool we need to implement a listener on the client side to explicitly detect these toasts. I assume connect-flash is similar
I am writing node js application without using templates, because it will be mobile application or something else. While writing post method I check with test status code, and try to check response. I do: res.send("success");. Node unit told: AssertionError: "success" == ".
And I come up with fundamental question: can method POST return response without redirecting on GET method or I did something wrong with node js?
Technically it can but check out the discussion here Is it ok by REST to return content after POST? it's specifically talking about REST principles but I think it may help you here.
It's also worth mentioning that you may end up with unintended browser behaviour if you return an html page after a post - if the user refreshes the page they will get a browser warning about reposting content. So, if you are returning an html page, don't send content in the response, redirect to a get. If you are writing an api then you can return the posted entity but it may be more expected by calling clients that the location of the posted resource is returned.
While trying to serve a page from node.js app I hit with this question. how multiple files are serving from a server with a simple request from user?
For eg:
A user enters www.google.co.in in address bar
browser make a request to that url and it should end there with a response. But whats happening is, few more requests are sending from that page to server like a chain.
What I am thinking now is, how my web browser(chrome) is sending those extra requests... Or who is prompting chrome to do it? and ofcourse, how can I do the same for my node.js app.
Once chrome gets the html back from the website, it will try to get all resources (images, javascript files, stylesheets) mentioned on the page, as well as favicon.ico That's what I think you are seeing
You can have as many requests as you want, from the client side (browser), using ajax. Here's a basic example using jQuery.get, an abstraction of an ajax call:
$.get(
"http://site.com",
function(data) { alert(data); }
);