Code Journal 8/2/14 — Mixins, Digging into Express a bit

by admcee

WHAT IS A MIXIN?

‘…a class which contains a combination of methods from other classes.’

According to Wikipedia this should not be done by inheritence

Angus Croll is the man.

In Express 4, app.’s has a ‘mixing’ object which uses the utils-merge package. Based on a quick read of utils-merge @ npmjs.org utils-merge is not a ‘true’ mixin, or at least a different implementation than described in Angus’ post above. Because utils-merge literally merges objects – variables, methods, and all.

I am attempting to gain a better understanding of what happens on require(‘express’), and require(‘http’), and require(‘socket.i’). Since I’ve encountered this issue (getting socket.io to work with express 4), I might as well take advantage of it and learn something.

My current unanswered question? What’s up with app.handle in:

function createApplication() {
  var app = function(req, res, next) {
  app.handle(req, res, next);
};
mixin(app, proto);
mixin(app, EventEmitter.prototype);

app.request = { __proto__: req, app: app };
app.response = { __proto__: res, app: app };
app.init();
return app;
}

My current best answer? Well, I still get confused sometimes. The handle() function does not actually get called at any point in this code. Because, the createApplication function is only being defined, not called. So most likely there is a handle() function in one of the mixins. That means all will be fine later when createApplications is actually called.

I also want to understand where Express starts up a web server, because that seems to be part of my socket.io issue – I need to get socket.io linked up/listening to a port on a server, but there is a conflict if I’m creating a second server and there are two different ports or something.

This stack overflow post has a good overview of how the server is started.

Based on that, I took a look at mysite/bin/www
This is what I saw:

#!/usr/bin/env node
var debug = require(‘debug’)(‘mysite’);
var app = require(‘../app’);
app.set(‘port’, process.env.PORT || 3000);
var server = app.listen(app.get(‘port’), function() {
debug(‘Express server listening on port ‘ + server.address().port);
});

First we tell Bash were to go to find the node executable to run node from the command line – or something like that.
Then our debug object is set up.
I am not sure where ‘app’ comes from but there’s a good chance it is from Express’s app.’s.
Here’s the doc on it.

And, actually, here is a very nice related post which my solve my express/socket.io issue.
In any case, the app object in the www file clearly starts up a server, because app.listen() sets that server listening on a port.

—————

Alright, success! My web socket connection is now working. I am getting an error reported in the console, but it is either an issue specific to Firefox or something where things are more-or-less OK, but I need to handle when the socket connection closes. Not going to deal with it now as it’s not crucial. Relevant links for future use:

https://github.com/Automattic/socket.io/issues/1123
http://stackoverflow.com/questions/14140414/websocket-interrupted-while-page-is-loading-on-firefox-for-socket-io