Node 开发离不开 npm，而脚本功能是 npm 最强大、最常用的功能之一。
本文介绍如何使用 npm 脚本（npm scripts）。

什么是 npm 脚本？

npm 允许在package.json文件里面，使用scripts字段定义脚本命令。

1
2
3
4
5
6

{
  // ...
  "scripts": {
    "build": "node build.js"
  }
}

上面代码是package.json文件的一个片段，里面的scripts字段是一个对象。它的每一个属性，对应一段脚本。比如，build命令对应的脚本是node build.js。
命令行下使用npm run命令，就可以执行这段脚本。

1
2
3

$ npm run build
# 等同于执行
$ node build.js

这些定义在package.json里面的脚本，就称为 npm 脚本。它的优点很多。

1
2
3

项目的相关脚本，可以集中在一个地方。
不同项目的脚本命令，只要功能相同，就可以有同样的对外接口。用户不需要知道怎么测试你的项目，只要运行npm run test即可。
可以利用 npm 提供的很多辅助功能。

查看当前项目的所有 npm 脚本命令，可以使用不带任何参数的npm run命令。

1

$ npm run

原理

npm 脚本的原理非常简单。每当执行npm run，就会自动新建一个 Shell，在这个 Shell 里面执行指定的脚本命令。因此，只要是 Shell（一般是 Bash）可以运行的命令，就可以写在 npm 脚本里面。
比较特别的是，npm run新建的这个 Shell，会将当前目录的node_modules/.bin子目录加入PATH变量，执行结束后，再将PATH变量恢复原样。
这意味着，当前目录的node_modules/.bin子目录里面的所有脚本，都可以直接用脚本名调用，而不必加上路径。比如，当前项目的依赖里面有 Mocha，只要直接写mocha test就可以了。

1

"test": "mocha test"

而不用写成下面这样。

1

"test": "./node_modules/.bin/mocha test"

由于 npm 脚本的唯一要求就是可以在 Shell 执行，因此它不一定是 Node 脚本，任何可执行文件都可以写在里面。
npm 脚本的退出码，也遵守 Shell 脚本规则。如果退出码不是0，npm 就认为这个脚本执行失败。

通配符

由于 npm 脚本就是 Shell 脚本，因为可以使用 Shell 通配符。

1
2

"lint": "jshint *.js"
"lint": "jshint **/*.js"

上面代码中，*表示任意文件名，**表示任意一层子目录。
如果要将通配符传入原始命令，防止被 Shell 转义，要将星号转义。

1

"test": "tap test/\*.js"

传参

向 npm 脚本传入参数，要使用–标明。

1

"lint": "jshint **.js"

向上面的npm run lint命令传入参数，必须写成下面这样。

1

$ npm run lint --  --reporter checkstyle > checkstyle.xml

也可以在package.json里面再封装一个命令。

1
2

"lint": "jshint **.js",
"lint:checkstyle": "npm run lint -- --reporter checkstyle > checkstyle.xml"

执行顺序

如果 npm 脚本里面需要执行多个任务，那么需要明确它们的执行顺序。
如果是并行执行（即同时的平行执行），可以使用&符号。

1

$ npm run script1.js & npm run script2.js

如果是继发执行（即只有前一个任务成功，才执行下一个任务），可以使用&&符号。

1

$ npm run script1.js && npm run script2.js

这两个符号是 Bash 的功能。此外，还可以使用 node 的任务管理模块：script-runner、npm-run-all、redrun。

默认值

一般来说，npm 脚本由用户提供。但是，npm 对两个脚本提供了默认值。也就是说，这两个脚本不用定义，就可以直接使用。

1
2

"start": "node server.js"，
"install": "node-gyp rebuild"

上面代码中，npm run start的默认值是node server.js，前提是项目根目录下有server.js这个脚本；npm run install的默认值是node-gyp rebuild，前提是项目根目录下有binding.gyp文件。

钩子

npm 脚本有pre和post两个钩子。举例来说，build脚本命令的钩子就是prebuild和postbuild。

1
2
3

"prebuild": "echo I run before the build script",
"build": "cross-env NODE_ENV=production webpack",
"postbuild": "echo I run after the build script"

用户执行npm run build的时候，会自动按照下面的顺序执行。

1

npm run prebuild && npm run build && npm run postbuild

因此，可以在这两个钩子里面，完成一些准备工作和清理工作。下面是一个例子。

1
2
3

"clean": "rimraf ./dist && mkdir dist",
"prebuild": "npm run clean",
"build": "cross-env NODE_ENV=production webpack"

npm 默认提供下面这些钩子。

1
2
3
4
5
6
7
8

prepublish，postpublish
preinstall，postinstall
preuninstall，postuninstall
preversion，postversion
pretest，posttest
prestop，poststop
prestart，poststart
prerestart，postrestart

自定义的脚本命令也可以加上pre和post钩子。比如，myscript这个脚本命令，也有premyscript和postmyscript钩子。不过，双重的pre和post无效，比如prepretest和postposttest是无效的。
npm 提供一个npm_lifecycle_event变量，返回当前正在运行的脚本名称，比如pretest、test、posttest等等。所以，可以利用这个变量，在同一个脚本文件里面，为不同的npm scripts命令编写代码。请看下面的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13

const TARGET = process.env.npm_lifecycle_event;

if (TARGET === 'test') {
  console.log(`Running the test task!`);
}

if (TARGET === 'pretest') {
  console.log(`Running the pretest task!`);
}

if (TARGET === 'posttest') {
  console.log(`Running the posttest task!`);
}

注意，prepublish这个钩子不仅会在npm publish命令之前运行，还会在npm install（不带任何参数）命令之前运行。这种行为很容易让用户感到困惑，所以 npm 4引入了一个新的钩子prepare，行为等同于prepublish，而从 npm 5开始，prepublish将只在npm publish命令之前运行。

简写形式

四个常用的 npm 脚本有简写形式。

1
2
3
4

npm start是npm run start
npm stop是npm run stop的简写
npm test是npm run test的简写
npm restart是npm run stop && npm run restart && npm run start的简写

npm start、npm stop和npm restart都比较好理解，而npm restart是一个复合命令，实际上会执行三个脚本命令：stop、restart、start。具体的执行顺序如下。

1
2
3
4
5
6
7
8
9

prerestart
prestop
stop
poststop
restart
prestart
start
poststart
postrestart

变量

npm 脚本有一个非常强大的功能，就是可以使用 npm 的内部变量。
首先，通过npm_package_前缀，npm 脚本可以拿到package.json里面的字段。比如，下面是一个package.json。

1
2
3
4
5
6
7

{
  "name": "foo", 
  "version": "1.2.5",
  "scripts": {
    "view": "node view.js"
  }
}

那么，变量npm_package_name返回foo，变量npm_package_version返回1.2.5。

1
2
3

// view.js
console.log(process.env.npm_package_name); // foo
console.log(process.env.npm_package_version); // 1.2.5

上面代码中，我们通过环境变量process.env对象，拿到package.json的字段值。如果是 Bash 脚本，可以用$npm_package_name和$npm_package_version取到这两个值。
npm_package_前缀也支持嵌套的package.json字段。

1
2
3
4
5
6
7

"repository": {
   "type": "git",
   "url": "xxx"
 },
 scripts: {
   "view": "echo $npm_package_repository_type"
 }

上面代码中，repository字段的type属性，可以通过npm_package_repository_type取到。
下面是另外一个例子。

1
2
3

"scripts": {
  "install": "foo.js"
}

上面代码中，npm_package_scripts_install变量的值等于foo.js。
然后，npm 脚本还可以通过npm_config_前缀，拿到 npm 的配置变量，即npm config get xxx命令返回的值。比如，当前模块的发行标签，可以通过npm_config_tag取到。

1

"view": "echo $npm_config_tag",

注意，package.json里面的config对象，可以被环境变量覆盖。

1
2
3
4
5

{ 
  "name" : "foo",
  "config" : { "port" : "8080" },
  "scripts" : { "start" : "node server.js" }
}

上面代码中，npm_package_config_port变量返回的是8080。这个值可以用下面的方法覆盖。

1

$ npm config set foo:port 80

最后，env命令可以列出所有环境变量。

1

"env": "env"

常用脚本示例

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

// 删除目录
"clean": "rimraf dist/*",

// 本地搭建一个 HTTP 服务
"serve": "http-server -p 9090 dist/",

// 打开浏览器
"open:dev": "opener http://localhost:9090",

// 实时刷新
 "livereload": "live-reload --port 9091 dist/",

// 构建 HTML 文件
"build:html": "jade index.jade > dist/index.html",

// 只要 CSS 文件有变动，就重新执行构建
"watch:css": "watch 'npm run build:css' assets/styles/",

// 只要 HTML 文件有变动，就重新执行构建
"watch:html": "watch 'npm run build:html' assets/html",

// 部署到 Amazon S3
"deploy:prod": "s3-cli sync ./dist/ s3://example-com/prod-site/",

// 构建 favicon
"build:favicon": "node scripts/favicon.js",

js精度问题一般是对浮点数的加减乘除引起的，主要的解决方案大都是将浮点数*10^n转为整数，计算完再/10^n转为浮点数

JS数字精度丢失的一些典型问题

• 1. 两个简单的浮点数相加
• 2. 大整数运算
• 3. toFixed 不会四舍五入（Chrome）

前言

在前端应用的优化中，对加载资源的大小控制极其的重要，大多数时候我们能做的是在打包编译的过程对资源进行大小控制、拆分与复用。

本片文章中主要是基于 webpack 打包，以 React、vue 等生态开发的单页面应用来举例说明如何从 webpack 打包的层面去处理资源以及缓存，其中主要我们需要做的是对 webpack 进行配置的优化，同时涉及少量的业务代码的更改。

同时对打包资源的分析可以使用 (webpack-contrib/webpack-bundle-analyzer) 插件，当然可选的分析插件还是很多的，在本文中主要以该插件来举例分析。

折腾记：最近一直在写react项目，遇到了不少坑，比如客户端开发使用了antd-mobile库，也使用了推荐的高清方案，但是组件都是使用px为单位的，所以需要集成postcss来进行转换rem

安装postcss相关npm包

1

npm install postcss-loader postcss-pxtorem --save-dev

webpack集成postcss

1
2
3
4
5
6
7
8
9
10
11
12

//webpack.config.js
const pxtorem = require('postcss-pxtorem');
// ....
{
    postcss: [
        pxtorem({
            rootValue: 100,
            propWhiteList: []
        }),
        require('autoprefixer')
    ]
}

设定post-loader

改写loaders，比如要对.css文件进行过滤:

1
2
3
4
5
6

loaders: [
    {
        test: /\.css$/,
        loader: 'style-loader!css-loader!postcss-loader'
    },
]

Lodash 是这样的一套工具库，它内部封装了诸多对字符串、数组、对象等常见数据类型的处理函数，其中部分是目前 ECMAScript 尚未制定的规范，但同时被业界所认可的辅助函数。目前每天使用 npm 安装 Lodash 的数量在百万级以上，这在一定程度上证明了其代码的健壮性，值得我们在项目中一试。

模块组成

Lodash提供的辅助函数主要分为以下几类:

• Array，适用于数组类型，比如填充数据，部分适用于字符串，比如分组、查找、过滤等操作。
• Collection，适用于数组和对象类型，部分适用于字符串，比如分组、查找、过滤等操作。
• Function，适用于函数类型，比如节流、延迟、缓存、设置钩子等操作。
• Lang，普遍适用于各种类型，常用于执行类型判断和类型转换。
• Math，适用于数组类型，常用于执行数学运算。
• Number，适用于生成随机数，比较数值与数值区间的关系。
• Object，适用于对象类型，常用于对象的创建、扩展、类型转换、检索、集合等操作。
• Seq，常用于创建链式调用，提高执行性能（惰性计算）。
• String，适用于字符串类型。

在计算机科学中，柯里化（英语：Currying），又译为卡瑞化或加里化，是把接受多个参数的函数变换成接受一个单一参数（最初函数的第一个参数）的函数，并且返回接受余下的参数而且返回结果的新函数的技术。这个技术由 Christopher Strachey 以逻辑学家哈斯凯尔·加里命名的，尽管它是 Moses Schönfinkel 和 Gottlob Frege 发明的。

这是来自维基百科的名词解释。顾名思义，柯里化其实本身是固定一个可以预期的参数，并返回一个特定的函数，处理批特定的需求。这增加了函数的适用性，但同时也降低了函数的适用范围。

git config –global user.name “username”
git config –global user.email “email”

提交流程：
git add .
git commit -m “代码提交信息”
git pull “代码提交信息”
git push origin <local_branch> # 创建远程分支， origin是远程仓库名

git branch branchName 创建新分支
git checkout branchName 切换到新分支

查看、添加、提交、删除、找回，重置修改文件
git help # 显示command的help
git show # 显示某次提交的内容 git show $id
git co – # 抛弃工作区修改
git co . # 抛弃工作区修改
git add # 将工作文件修改提交到本地暂存区
git add . # 将所有修改过的工作文件提交暂存区
git rm # 从版本库中删除文件
git rm –cached # 从版本库中删除文件，但不删除文件
git reset # 从暂存区恢复到工作文件
git reset – . # 从暂存区恢复到工作文件
git reset –hard # 恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改
git ci git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做　　　　　　　　　　　　　　　　git ci -am “some comments”
git ci –amend # 修改最后一次提交记录
git revert <$id> # 恢复某次提交的状态，恢复动作本身也创建次提交对象
git revert HEAD # 恢复最后一次提交的状态

git commit -m “代码提交信息”

查看文件diff
git diff # 比较当前文件和暂存区文件差异 git diff
git diff # 比较两次提交之间的差异
git diff .. # 在两个分支之间比较
git diff –staged # 比较暂存区和版本库差异
git diff –cached # 比较暂存区和版本库差异
git diff –stat # 仅仅比较统计信息

查看提交记录
git log git log # 查看该文件每次提交记录
git log -p # 查看每次详细修改内容的diff
git log -p -2 # 查看最近两次详细修改内容的diff
git log –stat #查看提交统计信息
tig Mac上可以使用tig代替diff和log，brew install tig
Git 本地分支管理

查看、切换、创建和删除分支
git br -r # 查看远程分支
git br <new_branch> # 创建新的分支
git br -v # 查看各个分支最后提交信息
git br –merged # 查看已经被合并到当前分支的分支
git br –no-merged # 查看尚未被合并到当前分支的分支
git co # 切换到某个分支
git co -b <new_branch> # 创建新的分支，并且切换过去
git co -b <new_branch> # 基于branch创建新的new_branch
git co $id # 把某次历史提交记录checkout出来，但无分支信息，切换到其他分支会自动删除
git co $id -b <new_branch> # 把某次历史提交记录checkout出来，创建成一个分支
git br -d # 删除某个分支
git br -D # 强制删除某个分支 (未被合并的分支被删除的时候需要强制)

分支合并和rebase
git merge # 将branch分支合并到当前分支
git merge origin/master –no-ff # 不要Fast-Foward合并，这样可以生成merge提交
git rebase master # 将master rebase到branch，相当于： git co && git rebase master && git co master && git merge
Git补丁管理(方便在多台机器上开发同步时用)
git diff > ../sync.patch # 生成补丁
git apply ../sync.patch # 打补丁
git apply –check ../sync.patch #测试补丁能否成功

Git暂存管理
git stash # 暂存
git stash list # 列所有stash
git stash apply # 恢复暂存的内容
git stash drop # 删除暂存区

Git远程分支管理
git pull # 抓取远程仓库所有分支更新并合并到本地
git pull –no-ff # 抓取远程仓库所有分支更新并合并到本地，不要快进合并
git fetch origin # 抓取远程仓库更新
git merge origin/master # 将远程主分支合并到本地当前分支
git co –track origin/branch # 跟踪某个远程分支创建相应的本地分支
git co -b <local_branch> origin/<remote_branch> # 基于远程分支创建本地分支，功能同上
git push # push所有分支
git push origin master # 将本地主分支推到远程主分支
git push -u origin master # 将本地主分支推到远程(如无远程主分支则创建，用于初始化远程仓库)
git push origin <local_branch> # 创建远程分支， origin是远程仓库名
git push origin <local_branch>:<remote_branch> # 创建远程分支
git push origin :<remote_branch> #先删除本地分支(git br -d )，然后再push删除远程分支
删除远程分支
git branch -a
git branch -r -d origin/branch-name
git push origin :branch-name

Git远程仓库管理
GitHub
git remote -v # 查看远程服务器地址和仓库名称
git remote show origin # 查看远程服务器仓库状态
git remote add origin git@ github:robbin/robbin_site.git # 添加远程仓库地址
git remote set-url origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址(用于修改远程仓库地址) git remote rm # 删除远程仓库

创建远程仓库
git clone –bare robbin_site robbin_site.git # 用带版本的项目创建纯版本仓库
scp -r my_project.git git@ git.csdn.net:~ # 将纯仓库上传到服务器上
mkdir robbin_site.git && cd robbin_site.git && git –bare init # 在服务器创建纯仓库
git remote add origin git@ github.com:robbin/robbin_site.git # 设置远程仓库地址
git push -u origin master # 客户端首次提交
git push -u origin develop # 首次将本地develop分支提交到远程develop分支，并且track
git remote set-head origin master # 设置远程仓库的HEAD指向master分支

也可以命令设置跟踪远程库和本地库
git branch –set-upstream master origin/master
git branch –set-upstream develop origin/develop

函数是js世界的一等公民，js的动态性、易变性在函数的应用上，体现的淋漓尽致。做为参数，做为返回值等，正是函数这些特性，使得js开发变的有趣。

下面就阐述一下，js一个有趣的应用–惰性函数定义（Lazy Function Definition）。

惰性载入表示函数执行的分支只会在函数第一次掉用的时候执行，在第一次调用过程中，该函数会被覆盖为另一个按照合适方式执行的函数，这样任何对原函数的调用就不用再经过执行的分支了。

下面我们看几个典型的例子：

1
2
3
4
5
6
7
8
9
10
11

function addEvent (type, element, fun) {
    if (element.addEventListener) {
        element.addEventListener(type, fun, false);
    }
    else if(element.attachEvent){
        element.attachEvent('on' + type, fun);
    }
    else{
        element['on' + type] = fun;
    }
}

上面是注册函数监听的各浏览器兼容函数。由于，各浏览之间的差异，不得不在用的时候做能力检测。显然，单从功能上讲，已经做到了兼容浏览器。美中不足，每次绑定监听，都会对能力做一次检测。然而，真正的应用中，这显然是多余的，同一个应用环境中，其实只需要检测一次即可。

下面我们重写上面的addEvent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

function addEvent (type, element, fun) {
    if (element.addEventListener) {
        addEvent = function (type, element, fun) {
            element.addEventListener(type, fun, false);
        }
    }
    else if(element.attachEvent){
        addEvent = function (type, element, fun) {
            element.attachEvent('on' + type, fun);
        }
    }
    else{
        addEvent = function (type, element, fun) {
            element['on' + type] = fun;
        }
    }
    addEvent(type, element, fun);
}

由上，第一次调用addEvent会对浏览器做能力检测，然后，重写了addEvent。下次再调用的时候，由于函数被重写，不会再做能力检测。

同样的应用，javascript高级程序设计里的一例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function createXHR(){
    if (typeof XMLHttpRequest != "undefined"){
        return new XMLHttpRequest();
    } else if (typeof ActiveXObject != "undefined"){
        if (typeof arguments.callee.activeXString != "string"){
            var versions = ["MSXML2.XMLHttp.6.0", "MSXML2.XMLHttp.3.0",
                            "MSXML2.XMLHttp"];
    
            for (var i=0,len=versions.length; i < len; i++){
                try {
                    var xhr = new ActiveXObject(versions[i]);
                    arguments.callee.activeXString = versions[i];
                    return xhr;
                } catch (ex){
                    //skip
                }
            }
        }
    
        return new ActiveXObject(arguments.callee.activeXString);
    } else {
        throw new Error("No XHR object available.");
    }
}

很显然，惰性函数在这里优势更加明显，因为这里有更多的分支。下面我们看一下重写后台的函数：

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

function createXHR() {
    if (typeof XMLHttpRequest != "undefined") {
        createXHR = function () {
            return new XMLHttpRequest();
        }
        return new XMLHttpRequest();
    } else if (typeof ActiveXObject != "undefined") {
        var curxhr;
        var versions = ["MSXML2.XMLHttp.6.0", "MSXML2.XMLHttp.3.0",
            "MSXML2.XMLHttp"];

        for (var i = 0, len = versions.length; i < len; i++) {
            try {
                var xhr = new ActiveXObject(versions[i]);
                curxhr = versions[i];
                createXHR = function () {
                    return new ActiveXObject(curxhr);
                }
                return xhr;
            } catch (ex) {
                //skip
            }
        }
    } else {
        throw new Error("No XHR object available.");
    }
}

浏览器之间最大的差异，莫过于Dom操作，Dom操作也是前端应用 中最频繁的操作，前端的大多性能提升，均体现在Dom操作方面。下面看一个Dom操作方面的惰性函数定义例子：

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

var getScrollY = function() {

    if (typeof window.pageYOffset == 'number') {

        getScrollY = function() {
            return window.pageYOffset;
        };

    } else if ((typeof document.compatMode == 'string') &&
               (document.compatMode.indexOf('CSS') >= 0) &&
               (document.documentElement) &&
               (typeof document.documentElement.scrollTop == 'number')) {

        getScrollY = function() {
            return document.documentElement.scrollTop;
        };

    } else if ((document.body) &&
               (typeof document.body.scrollTop == 'number')) {

      getScrollY = function() {
          return document.body.scrollTop;
      }

    } else {

      getScrollY = function() {
          return NaN;
      };

    }

    return getScrollY();
}

惰性函数定义应用还体现在创建单例上：(目前还不清楚创建单例的话有什么好处)

1
2
3
4
5
6
7
8
9
10
11
12
13
14

unction Universe() {

    // 缓存的实例
    var instance = this;

    // 其它内容
    this.start_time = 0;
    this.bang = "Big";

    // 重写构造函数
    Universe = function () {
        return instance;
    };
}

当然，像上面这种例子有很多。惰性函数定义，应用场景我们可以总结一下：

1 应用频繁，如果只用一次，是体现不出它的优点出来的，用的次数越多，越能体现这种模式的优势所在；

2 固定不变，一次判定，在固定的应用环境中不会发生改变；

3 复杂的分支判断，没有差异性，不需要应用这种模式；

注：本文使用的 react-router 版本为 2.8.1

React Router 是一个非常出色的路由解决方案，同时也非常容易上手。但是当网站规模越来越大的时候，首先出现的问题是 Javascript 文件变得巨大，这导致首页渲染的时间让人难以忍受。实际上程序应当只加载当前渲染页所需的 JavaScript，也就是大家说的“代码分拆” — 将所有的代码分拆成多个小包，在用户浏览过程中按需加载。

效果：
以前是这样：

现在是这样：

实际上就是将一个大 javascript 文件拆分成了若干个 chunk file。

下面是改造过程

Webpack 配置

首先在 webpack.config.js 的 output 内加上 chunkFilename

1
2
3
4
5
6
7

output: {
    path: path.join(__dirname, '/../dist/assets'),
    filename: 'app.js',
    publicPath: defaultSettings.publicPath,
    // 添加 chunkFilename
    chunkFilename: '[name].[chunkhash:5].chunk.js',
},

name 是在代码里为创建的 chunk 指定的名字，如果代码中没指定则 webpack 默认分配 id 作为 name。

chunkhash 是文件的 hash 码，这里只使用前五位。

添加首页

以前你的路由大概应该是这样的：（作为需要按需加载的大型应用，路由肯定是相当复杂，这里只列举部分路由举例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

ReactDOM.render(
  (
    <Router history={browserHistory}>
      {/* 主页 */}
      <Route path="/" component={App}>
        {/* 默认 */}
        <IndexRoute component={HomePage} />

        {/* baidu */}
        <Route path="/baidu" component={BaiduPage}>
          <Route path="result" component={BaiduResultPage} />
          <Route path="frequency" component={BaiduFrequencyPage} />
        </Route>

        {/* 404 */}
        <Route path='/404' component={NotFoundPage} />
        
        {/* 其他重定向到 404 */}
        <Redirect from='*' to='/404' />
      </Route>
    </Router>
  ), document.getElementById('app')
);

按需加载之后，我们需要让路由动态加载组件，需要将 component 换成 getComponent。首先将路由拆出来（因为路由庞大之后全部写在一起会很难看），创建一个根路由 rootRoute：

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

const rootRoute = {
  path: '/',
  indexRoute: {
    getComponent(nextState, cb) {
      require.ensure([], (require) => {
        cb(null, require('components/layer/HomePage'))
      }, 'HomePage')
    },
  },
  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/Main'))
    }, 'Main')
  },
  childRoutes: [
    require('./routes/baidu'),
    require('./routes/404'),
    require('./routes/redirect')
  ]
}

ReactDOM.render(
  (
    <Router
      history={browserHistory}
      routes={rootRoute}
      />
  ), document.getElementById('app')
);

history 不变，在 Router 中添加 routes 属性，将创建的路由传递进去。

这里有四个属性：

path

将匹配的路由，也就是以前的 path。

getComponent

对应于以前的 component 属性，但是这个方法是异步的，也就是当路由匹配时，才会调用这个方法。

这里面有个 require.ensure 方法

1

require.ensure(dependencies, callback, chunkName)

这是 webpack 提供的方法，这也是按需加载的核心方法。第一个参数是依赖，第二个是回调函数，第三个就是上面提到的 chunkName，用来指定这个 chunk file 的 name。

如果需要返回多个子组件，则使用 getComponents 方法，将多个组件作为一个对象的属性通过 cb 返回出去即可。这个在官方示例也有，但是我们这里并不需要，而且根组件是不能返回多个子组件的，所以使用 getComponent。

indexRoute

用来设置主页，对应于以前的 <IndexRoute>。

注意这里的 indexRoute 写法， 这是个对象，在对象里面使用 getComponent。

childRoutes

这里面放置的就是子路由的配置，对应于以前的子路由们。我们将以前的 /baidu、/404 和 * 都拆了出来，接下来将分别为他们创建路由配置。

路由控制

上面的 childRoutes 里面，我们 require 了三个子路由，在目录下创建 routes 目录，将这三个路由放置进去。

1
2
3
4
5
6
7
8
9
10
11
12

routes/
├── 404
│   └── index.js
├── baidu
│   ├── index.js
│   └── routes
│       ├── frequency
│       │   └── index.js
│       └── result
│           └── index.js
└── redirect
    └── index.js

和 rootRoute 类似，里面的每个 index.js 都是一个路由对象：

/404/index.js

1
2
3
4
5
6
7
8
9

module.exports = {
  path: '404',

  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/layer/NotFoundPage'))
    }, 'NotFoundPage')
  }
}

/baidu/index.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

module.exports = {
  path: 'baidu',

  getChildRoutes(partialNextState, cb) {
    require.ensure([], (require) => {
      cb(null, [
        require('./routes/result'),
        require('./routes/frequency')
      ])
    })
  },

  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/layer/BaiduPage'))
    }, 'BaiduPage')
  }
}

/baidu/routes/frequency/index.js

1
2
3
4
5
6
7
8
9

module.exports = {
  path: 'frequency',

  getComponent(nextState, cb) {
    require.ensure([], (require) => {
      cb(null, require('components/layer/BaiduFrequencyPage'))
    }, 'BaiduFrequencyPage')
  }
}

举这几个例子应该就差不多了，其他都是一样的，稍微有点特别的是 redirect。

设置 Redirect

之前我们在根路由下是这么设置重定向的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<Router history={browserHistory}>
    <Route path="/" component={App}>
    {/* home */}
    <IndexRoute component={HomePage} />

    <Route path="/baidu" component={BaiduPage}>
        <Route path="result" component={BaiduResultPage} />
        <Route path="frequency" component={BaiduFrequencyPage} />
    </Route>

    <Route path='/404' component={NotFoundPage} />
    {/* 如果都不匹配，重定向到 404 */}
    <Redirect from='*' to='/404' />
    </Route>
</Router>

当改写之后，我们需要把这个重定向的路由单独拆出来，也就是 * 这个路由，我们上面已经为他创建了一个 redirect 目录。这里使用到 onEnter 方法，然后在这个方法里改变路由状态，调到另外的路由，实现 redirect ：

/redirect/index.js

1
2
3
4

module.exports = {
  path: '*',
  onEnter: (_, replaceState) => replaceState(null, "/404")
}

The root route must render a single element

跟着官方示例和上面码出来之后，可能页面并没有渲染出来，而是报 The root route must render a single element 这个异常，这是因为 module.exports 和 ES6 里的 export default 有区别。

如果你是使用 es6 的写法，也就是你的组件都是通过 export default 导出的，那么在 getComponent 方法里面需要加入 .default。

1
2
3
4
5
6

getComponent(nextState, cb) {
    require.ensure([], (require) => {
      // 在后面加 .default
      cb(null, require('components/layer/ReportPage')).default
    }, 'ReportPage')
}

如果你是使用 CommonJS 的写法，也就是通过 module.exports 导出的，那就无须加 .default 了。

原文地址：http://leozdgao.me/reacthe-reduxde-qiao-jie-react-redux/

Redux本身和React并没有之间的关联，它是一个通用Javscript App模块，用做App State的管理。要在React的项目中使用Redux，比较好的方式是借助react-redux这个库来做连接，这里的意思是，并不是没有react-redux，这两个库就不弄一起用了，而是说react-redux提供了一些封装，一种更科学的代码组织方式，让我们更舒服地在React的代码中使用Redux。

之前仅通过Redux文档来了解react-redux，在一段时间的实践后准备翻一翻源代码，顺便做些相关的总结。我看的代码的npm版本为v4.0.0，也就是说使用的React版本是v0.14.x。

react-redux提供两个关键模块：Provider和connect。

Provider

Provider这个模块是作为整个App的容器，在你原有的App Container的基础上再包上一层，它的工作很简单，就是接受Redux的store作为props，并将其声明为context的属性之一，子组件可以在声明了contextTypes之后可以方便的通过this.context.store访问到store。不过我们的组件通常不需要这么做，将store放在context里，是为了给下面的connect用的。

这个是Provider的使用示例：

1
2
3
4
5
6
7
8
9
10
11
12
13

// config app root
const history = createHistory()  
const root = (  
  <Provider store={store} key="provider">
    <Router history={history} routes={routes} />
  </Provider>
)

// render
ReactDOM.render(  
  root,
  document.getElementById('root')
)

connect

这个模块是算是真正意义上连接了Redux和React，正好它的名字也叫connect。

先考虑Redux是怎么运作的：首先store中维护了一个state，我们dispatch一个action，接下来reducer根据这个action更新state。

映射到我们的React应用中，store中维护的state就是我们的app state，一个React组件作为View层，做两件事：render和响应用户操作。于是connect就是将store中的必要数据作为props传递给React组件来render，并包装action creator用于在响应用户操作时dispatch一个action。

好了，详细看看connect这个模块做了什么。先从它的使用来说，它的API如下：

1

connect([mapStateToProps], [mapDispatchToProps], [mergeProps], [options])

mapStateToProps是一个函数，返回值表示的是需要merge进props的state。默认值为() => ({})，即什么都不传。

1

(state, props) => ({  }) // 通常会省略第二个参数

mapDispatchToProps是可以是一个函数，返回值表示的是需要merge仅props的actionCreators，这里的actionCreator应该是已经被包装了dispatch了的，推荐使用redux的bindActionCreators函数。

1
2
3
4
5

(dispatch, props) => ({ // 通常会省略第二个参数
 ...bindActionCreators({
   ...ResourceActions
 }, dispatch)
})

更方便的是可以直接接受一个对象，此时connect函数内部会将其转变为函数，这个函数和上面那个例子是一模一样的。

mergeProps用于自定义merge流程，下面这个是默认流程，parentProps值的就是组件自身的props，可以发现如果组件的props上出现同名，会被覆盖。

1
2
3
4
5

(stateProps, dispatchProps, parentProps) => ({
  ...parentProps,
  ...stateProps,
  ...dispatchProps
})

options共有两个开关：pure代表是否打开优化，详细内容下面会提，默认为true，withRef用来给包装在里面的组件一个ref，可以通过getWrappedInstance方法来获取这个ref，默认为false。

connect返回一个函数，它接受一个React组件的构造函数作为连接对象，最终返回连接好的组件构造函数。

然后几个问题：

• React组件如何响应store的变化？
• 为什么connect选择性的merge一些props，而不是直接将整个state传入？
• pure优化的是什么？

我们把connect返回的函数叫做Connector，它返回的是内部的一个叫Connect的组件，它在包装原有组件的基础上，还在内部监听了Redux的store的变化，为了让被它包装的组件可以响应store的变化:

1
2
3
4
5
6
7
8
9
10
11
12

trySubscribe() {  
  if (shouldSubscribe && !this.unsubscribe) {
    this.unsubscribe = this.store.subscribe(::this.handleChange)
    this.handleChange()
  }
}

handleChange () {  
  this.setState({
    storeState: this.store.getState()
  })
}

但是通常，我们connect的是某个Container组件，它并不承载所有App state，然而我们的handler是响应所有state变化的，于是我们需要优化的是：当storeState变化的时候，仅在我们真正依赖那部分state变化时，才重新render相应的React组件，那么什么是我们真正依赖的部分？就是通过mapStateToProps和mapDispatchToProps得到的。

具体优化的方式就是在shouldComponentUpdate中做检查，如果只有在组件自身的props改变，或者mapStateToProps的结果改变，或者是mapDispatchToProps的结果改变时shouldComponentUpdate才会返回true，检查的方式是进行shallowEqual的比较。

所以对于某个reducer来说：

1
2
3
4

export default (state = {}, action) => {  
  return { ...state } // 返回的是一个新的对象，可能会使组件reRender
  // return state // 可能不会使得组件reRender
}

另外在connect的时候，要谨慎map真正需要的state或者actionCreators到props中，以避免不必要的性能损失。

最后，根据connect的API我们发现可以使用ES7 decorator功能来配合React ES6的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@connect(
  state => ({
    user: state.user,
    resource: state.resource
  }),
  dispatch => ({
    ...bindActionCreators({
      loadResource: ResourceActions.load
    }, dispatch)
  })
)
export default class Main extends Component {

}

OK，结束了。