Anybody used Node.js to process forms?

[nixnerd]

I’m looking into use Nodemailer but I have a few questions:

#1: Is there still a need to use AJAX? I’m assuming that there is… I just don’t know. I would assume that you need to use AJAX conventions to get the form input TO the server. Then, you’d use a tool like Nodemailer to process the input from there.

#2: If you don’t use AJAX… is Node capable of submitting and sending the input WITHOUT a page reload?

Anyone who has tried… please let me know. Although, I’m assuming “anyone” consists of @traq.

[__]

I hadn’t looked at nodemailer before. It looks very nice.

You would need to get the form input (I assume we’re talking about contact forms) to the server somehow, so either ajax, a regular page request, whatever.

For processing the body of requests, I’ve been using bodyparser. It handles simple bodies only (no multipart bodies — e.g., file uploads), so I don’t know if I’ll stick with it in the long run, but a contact form is usually just a simple urlencoded request, so it should serve you well here.

is Node capable of submitting and sending the input WITHOUT a page reload?

Node can keep a connection open and continue pushing content to the browser …apparently, for as long as it likes. (Or, at least, as long as the browser is still there. I am assuming that node is smart enough to close connections when the client goes away).

I have read stuff that seems to imply that this is a two-way street, but I have not found anything that specifically confirms that, nor hints at how it actually works from the browser’s end.

I don’t think that is going to be a sticking point in many applications, and certainly not for yours. I’d say your #1 assumption is pretty sound, except that nodemailer will only send the message, and you’d need to use bodyparser (or similar) to process the form submission beforehand.

[nixnerd]

Dude… thanks for your help. MUCH appreciated.

I’d say your #1 assumption is pretty sound, except that nodemailer will only send the message…

You mean… get the form input TO an inbox or elsewhere right? Since AJAX is getting it TO the server.

I’m going to look into bodyparser. Seems legit. I’m guessing this is just a server-side Node tool to check for anything malicious.

[__]

Yeah, ajax gets it to the server, nodemailer sends the email.

By default, bodyparser only parses the request. It will add a req.body object that has the key: value pairs that were encoded in the request (also, supports JSON out-of-the-box).

You can set up validator functions but I haven’t dabbled much with that yet. There is no documentation on it, but you pass a function to verify in the options. It’s called like this:

if (verify) {    
    try {
        verify(req, res, body, encoding)
    } catch (err) {
        if (!err.status) err.status = 403
        return next(err)
    }
}

…which would indicate that your verify function gets the request and response objects, the body itself (not sure if it’s parsed at this point, or still a stream), and the character encoding. If you don’t like the body, throw an error and it will skip to your next error middleware.

It will take some experimenting and research.

[nixnerd]

Am I crazy or are contact forms like THE MOST OVERLY COMPLICATED piece of a simple website?

[__]

You’re just crazy.

Now, while bodyparser allows you to define validator functions, you could also just use it for parsing and run your own validator functions afterwards, as regular middleware.

Before you get too much further into express, do you grok the purpose of next()? That was the most confusing bit, for me.

[nixnerd]

You’re just crazy.

Probably true.

Before you get too much further into express, do you grok the purpose of next()?

You mean in general? Or in this specific context?

[__]

uhh… both?

next gives you linear control of how your application executes. This is the single most important thing to understand about it, and also more or less the only thing about it that they don’t explain.

Say you have a two-step application. You start step 1, then start step 2. Because JS is asynchronous, you have no way to know if step 2 actually happens after step 1 — they might happen at the same time, step 2 might even finish first, etc..

To account for situations where this is not workable, express puts all your steps (“middleware”) into a queue and waits. When you call next*, it starts the next middleware in the queue.

* note; this means you can still run asynchronously if you wish by calling next at the beginning of your middleware.

In this case, next( {error object} ) runs the next error middleware, skipping all non-error middleware in between. You can also do next( 'route' ) to skip to the next route middleware.

[nixnerd]

I thought this was the ONE THING everyone hates about node… callbacks. Isn’t that the only way to know if step 1 has completed?

[nixnerd]

The only negative thing I hear about node is “Blah blah blah… callback hell!”

[__]

yeah… next effectively reduces callback hell to a single, one-size-fits-all callback.

[nixnerd]

That sounds much more elegant and workable… you haven’t found an explanation anywhere?

I’m hitting up the IRC channel now to ask about it.

[nixnerd]

This looks promising (even though I know you hate tuts):

http://stephensugden.com/middleware_guide/

[__]

That sounds much more elegant and workable… you haven’t found an explanation anywhere?

I’ve found lots of stuff written about next. How to use it, common pitfalls, and so forth. But no one comes right out and says, “it makes a queue for your middleware and calls them in turn.” If someone had said that, I would’ve figured out how to use it in a few hours. Instead, it was weeks before I got a handle on it.

http://stephensugden.com/middleware_guide/

Ha! the one article I didn’t find.

NP; it’s not a “stack” of middleware, it’s a queue. First-in, first-out

[nixnerd]

So… that clears it up then? Because I’ll be honest… when I hit this roadblock in my Node journey… you’re going to be the first person I ask.

[Author]

Posts