1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
[express]
$ express
- do '# npm install -g express' beforehand, express command
generates nice template dir structure to get started
- last param in functions usually implies a callback
- app.param
map/assosiate some logic to a 'route parameter(s)', so when you enter such route
you can expect to have a variable filled for you, e.g. route: /sys/:id, let's say
id is 'listdb', then a db would get preloaded by the time we stepped into the route logic
- doing next(new Error('foo')) will stall and end middleware chain
[code analysis]
# npm install -g jslint
$ jslint --sloppy --white <file.js>
[make a copy of an array]
var foo = [1, 2, 3];
var bar = foo.slice(0);
- an object that listen for event must be subclass of
of events.EventEmitter, e.g. http.createServer()
I'm an eventer, I will emit events, and have a list of
who responds/listens to those, so we will see statements
such eventer.on('foo', somehandler)
[mongodb]
$ mongo; show dbs; use nodejs1; show collections; db.getCollectionNames(), db.users.find(), db.users.remove(), db.users.drop()
[debug node]
$ node --debug-brk app.js
$ node-inspector &
http://0.0.0.0:8080/debug?port=5858
[module.exports vs exports]
- if you want your module to be of a specific object type (boolean, string, etc),
use module.exports; if you want your module to be a typical module instance, use exports
- result of attaching properties to module.exports is akin (same) to attaching properties to exports
- http://www.hacksparrow.com/node-js-exports-vs-module-exports.html
|
