Converting from one type to another frequently causes bugs or unexpected result if you’re not careful. For example, when converting a string to an integer, we use the following function:
1
var num = parseInt(string, radix);
Accidentally, I used an array of numeric strings in place of string for conversion.
One of the benefits coding in JavaScript is the ability to share code between browser (front-end) and Node (back-end) environments.
To share code between two different environment, first need to understand what are specific to browser and what are specific to Node. Shared code should be agnostic to both environments.
In browser environment, there is an obvious one: window object. In Node environment, there are a few objects that are not globally defined in browser: global, process, module, exports and more, see global objects. All these variables work, but exports is preferred.
This is a Setext-style headers, which are ‘underlined’ using equal signs (for first-level headers) and dashes (for second-level headers). In order to generate those underlined equal signs, a simple loop could be used to repeat the character = several times. By the way, it is not necessary to have exact number of the equal signs as the header length, but it just looks better. But there is another way:
1
Array(heading.length + 1).join('=')
It is using the JavaScript Array global object to construct an empty Array with the specified array length. Clever indeed!
Living on the bleeding edge means more to learn. I was learning about creating source maps by using UglifyJS. For some reason, the uncompressed JavaScript source codes were not able to load. After some diff with a working version from Source Maps 101, the problem is just resulting of one character difference. With newly updated UglifyJS v2.3.6, SourceMapping pragma has changed to //#:
//# sourceMappingURL=script.uglify.js.map
but my Chrome browser lags behind. It recognizes source maps as //@:
//@ sourceMappingURL=script.uglify.js.map
I did not use the latest or dev build, the current Chrome browser I am using is yet to support //#. What I really need is Chrome Canary. Unfortunately, it is not available for Linux :(.
When linting, different JSHint options are needed for front-end and back-end JavaScript. We can specify different targets in grunt-contrib-jshint. But there is something to be careful:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
jshint: {
// Task level options
options: {
jshintrc: './.jshintrc'
},
node: {
// Target level options
options: {
node: true
}
},
jquery: {
// Target level options
options: {
globals: {
jQuery: true
}
}
}
}
I thought the target level options will merge with the task level, but it does not happen. Need to dig deeper to figure out why jshintrc option is not merged with JSHint options. A quick fix is to load the JSHint JSON file directly:
1
2
3
4
5
6
7
8
9
10
jshint: {
// Task level options
options: grunt.file.readJSON('./.jshintrc'),
node: {
// Target level options
options: {
node: true
}
}
}
In this case, if jshint:node target was run, the merged options will be parsed to JSHint.