前言

我们在使用 webpack 打包构建 moment 库的时候，moment 默认会将所有语言包全部引入，这样就会导致打包后的 JS 体积增大，通过 webpack-bundle-analyzer 分析工具可以看到，如果将所有的 moment 语言包引入的话，所占 JS 体积是相当庞大的。gzip 之后也要占据 65kb 的文件大小。

所以如果应用没有国际化背景的需求下，我们一般都会通过 webpack.IgnorePlugin(/^\.\/locale$/, /moment$/) 将所有语言包进行剔除，不进行打包，这样打包后的 moment 体积就只有 16kb。

正常的业务诉求到这里结束了，但是我们阿里巴巴国际站需要支持 14 种语言的切换(即在站点内支持语种的切换)，如果像下面这这样 14 语言包一起引入的话也会造成体积上的浪费。

import moment from 'moment';
import 'moment/locale/zh-cn';
// ...other language file
import 'moment/locale/zh-tw';
moment.locale(window.currentLocale);

所以本节的重点在于讲讲如何在像 React/Vue 这样单页应用或者其它多页面应用中实现对 moment 语言包的动态引入，其它库引入语言包的**也可以借鉴。

动态引入 moment 语言包

首先需要编写不同语种的脚本文件入口，比如：

// ./locale-zh_cn.js
import moment from 'moment';
import 'moment/locale/zh-cn';
moment.locale('zh-cn');

// ./locale-zh_tw.js
import moment from 'moment';
import 'moment/locale/zh-tw';
moment.locale('zh-tw');

在页面打开的时候通过服务端渲染在 html 中注入变量来告诉页面当前的语种脚本。

<script src="/js/locale-${currentLocale}.js"></script>
<script src="/js/main.js"></script>

这样做就可以让用户在站点中切换语种是可以保证引入当前语种所需语种包的最小集。

当时这里就产生新的问题，熟悉 webpack 打包机制的同学应该知道 (如果不熟悉可以看我之前写的 深入理解 webpack 文件打包机制 )

在多入口文件的时候，会有不同的 __wepback_require__ 和 installModules，这就导致了你在不同入口文件中使用 moment 库时，其实实例了两个不同的 moment 对象(即 main.js 和 locale-xxx.js 中使用的 moment 其实不是同一个实例，main 入口就无法使用 locale.js 中注入的语种包)，针对这样的问题，那么有什么办法能让不同的入口使用同一个 moment 实例？

巧用 externals 属性

通过在 webpack 配置文件 externals 属性，让 moment 指向 window.moment 并且在页面中额外引入不带语种包的 moment CDN 库。

{
    // ...
    externals: {
      "moment": "moment",
      "../moment": "moment"
    },
}

不难理解，通过这种方式打包后 webpack 在遇到 import moment from 'moment'时候会直接使用 window.moment，值得一提的是，因为在 moment 内置语种包中通过 .../moment 来调用 moment 的方法，所以我们也将这个设置为外置引用 window.moment。

// node_modules/moment/locale/zh-cn.js
;(function (global, factory) {
   typeof exports === 'object' && typeof module !== 'undefined'
       && typeof require === 'function' ? factory(require('../moment')) :
   typeof define === 'function' && define.amd ? define(['../moment'], factory) :
   factory(global.moment)
}(this, (function (moment) { 'use strict';
    var zhCn = moment.defineLocale('zh-cn', {
        // ...
    }
}

这样做有三个好处：

1. 保证了不同入口的业务代码引用到的都是同一个 moment 实例
2. 不需要对已有的代码进行改造，在 import moment 的时候 webpack 都会默认指向 window.moment 变量。
3. 引入 moment 语言包最小集

这样做解决了多页应用或单页面应用在第一次打开时的语种问题，如果用户在单页应用切换语种的话就比较简单，直接使用动态 import 即可。

import moment from 'moment';
// 此时已经引入 locale-zh_cn;
console.log(moment(new Date()).format('ALT'));
console.log(moment(new Date()).format('A'));

setTimeout(() => {
  import('./locale-zh_tw').then(() => {
    console.log(moment(new Date()).format('A'));
  })
}, 200);

原文地址

webpack 大型应用优化实践

前言

最近在团队分享一些 webpack 技巧，于是便准备梳理出一篇博文总结一下，不过由于讲的内容太多了，无法描述的很详细，更多地是提供一个思路，希望读者感兴趣可以动手去实践实践。

我认为理想的 webpack 配置：

配置多份 webpack 配置，通过 webpack-merge 进行合并，

├── common.js
├── dll.config.js
├── webpack.base.config.js
├── webpack.dev.config.js
├── webpack.prod.config.js
// etc 同构配置，node middleware 等等

然后通过 npm scripts 执行 webpack 命令:

{  
  "scripts": {
    "dev": "webpack-dev-server --config ./webpack.dev.config.js",
    "build": "webpack --config ./webpack.prod.config.js",
    "start": "npm run dev",
    "pre": "webpack --config ./dll.config.js"
  },
}

1. 公共变量，公共配置抽离，方便以后的人进行修改配置。
2. 方便开发人员查看配置，不用手动输入 node_modules/.bin/webpack-dev-server，npm scripts 会自动把 node_modules/.bin/ 下的指令添加到环境中。
3. 易扩展，如果需要新增配置文件，如同构配置，node middleware 配置，只需添加新配置文件，合并公有部分。

区分好开发环境和生产环境：

1. 开发环境：
   • 值得去配置的：
     • 优化开发体验
     • 尽可能减少构建时间
   • 不值得去配置的：
     • 代码丑化
     • 模块拆包，持久化缓存
     • 减少打包文件大小
2. 生产环境：
   • 值得去配置的：
     • 模块拆包，持久化缓存
     • 尽可能减少打包文件大小
     • 代码丑化压缩
     • 尽可能减少构建时间
   • 不值得去配置的：
     • 优化开发体验
     • 开发环境才需要的配置

开发过程：

优化开发体验

自动刷新 -> 模块热更新：

1. 实时预览反应更快，等待时间更短
2. 不刷新浏览器能保留当前网页的运行状态

想开启热更新，首先需要在入口文件进行配置：

// 入口文件 
if(module.hot) {
  module.hot.accept(['./App'], () => {
    render(<App />, document.getElementById('app'))
  })
}

模块热更新机制：

1. 当子模块发生更新时，更新事件会一层层往上传递，也就是从 App.js 文件传递到 main.js 文件， 直到有某层的文件接受了当前变化的模块，也就是 main.js 文件中定义的 module.hot.accept(['./App'], callback)， 这时就会调用 callback 函数去执行自定义逻辑。
2. 如果事件一直往上抛到最外层都没有文件接受它，就会直接刷新网页。

最简单的方式：

直接在命令里面加上 webpack-dev-server --hot 即可开启热更新。

该参数相当于是做了：

const HotModuleReplacementPlugin = require('webpack/lib/HotModuleReplacementPlugin');
module.exports = {
  plugins: [
    new HotModuleReplacementPlugin(),
  ],
  devServer:{
    hot: true,      
  }  
};

当然如果你想要更加定制化的控制，你需要在 webpack 配置进行额外配置：

const HotModuleReplacementPlugin = require('webpack/lib/HotModuleReplacementPlugin');
module.exports = webpackMerge(baseConfig, {
  plugins: [
    new HotModuleReplacementPlugin(),
  ],
  devServer: {
    // 每次构建时候自动打开浏览器并访问网址
    open: true,
    // 开启热更新
    hot: true,
    // 设置静态资源地址如：/public，从这获取你想要的一些外链资源，图片。
    contentBase: DIST_PATH,
    // 设置端口号
    port: 9000,
    // 将热更新代码注入到模块中
    inline: true,
    // 如果你希望服务器外部可访问
    host: "0.0.0.0",
    // 设置 proxy 代理
    proxy: {
      context: ['/api'],
      target: "//www.proxy.com",
      pathRewrite: {"^/api" : ""}
    },
    // 设置 https
    https: true
  }
});

关于 webpack 热更新原理我就不说了，感兴趣可以看下面两篇文章：

1. Webpack 热更新实现原理分析
2. Webpack HMR 原理解析

配置 sourcemap

module.exports = {
  devtool: 'source-map',
}

方便调试源代码

减少构建时间

在大型应用减少每次构建的时间十分重要，动不动几十秒的编译时间令人发指，我在经过一些实践，总结下面一些方式，至少可以让你的编译速度快 1-2 倍。

1. 减小模块查找范围，缩小 Babel 的编译范围，并使用 webpack cache 缓存模块。
2. 使用 DLLPlugin 预先打包好第三方库。
3. 使用 Happypack 加速构建
4. 不用使用 webpack css 模块化方案

首先第一点：缩小 Babel 的编译范围，并使用 webpack cache 缓存模块。

module.exports = {
  // 减小模块的查找范围
  resolve: {
    modules: [path.resolve(__dirname, 'node_modules')],
  },
  module: {
    rules: [
      {
        test: /\.js?$/,
        use: [{
          loader: 'babel-loader',
          query: {
            // 将 babel 编译过的模块缓存在 webpack_cache 目录下，下次优先复用
            cacheDirectory: './webpack_cache/',
          },
        }],
        // 减少 babel 编译范围，忘记设置会让 webpack 编译慢上好几倍
        include: path.resolve(__dirname, 'src'),
      },
    ]
  },
}

通过这步可以快上好几秒，另外你可以使用 DLLPlugin 预先打包好第三方库，避免每次都要去编译。开启 DLLPlugin 需要你额外配置一份 webpack 配置。

// dll.config.js
const webpack = require('webpack');
const path = require('path');
const DllPlugin = require('webpack/lib/DllPlugin')
const vendors = [
  'react',
  'react-dom',
  'react-router',
  'redux',
  'react-redux',
  'jquery',
  'antd',
  'lodash',
]
module.exports = {
  entry: {
    'dll': vendors,
  },
  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, 'public'),
    library: '__[name]__lib',
  },
  plugins: [
    new DllPlugin({
      name: '__[name]__lib',
      path: path.join(__dirname, 'build', '[name].manifest.json'),
    }),
  ]
}

运行则会在 public 目录下得到 dll.js 和 dll.manifest.json 文件，然后需要在开发配置文件中关联。

const webpack = require('webpack');

module.exports = webpackMerge(baseConfig, {
  plugins: [
    new DllReferencePlugin({
      manifest: require('./public/dll.manifest.json'),
    }),
  ]
});

另外需要在你的 html 模板里面引入 dll.js，webpack 不会自动帮你引入，用好这一步编译速度应该能快一倍左右的时间。

第三点就是使用 happypack 开启多核构建，webpack 之所以慢，是因为由于有大量文件需要解析和处理，构建是文件读写和计算密集型的操作，特别是当文件数量变多后，webpack 构建慢的问题会显得严重。 也就是说 Webpack 需要处理的任务需要一件件挨着做，不能多个事情一起做。

在整个 webpack 构建流程中，最耗时的流程可能就是 loader 对文件的转换操作了，因为要转换的文件数据巨多，而且这些转换操作都只能一个个挨着处理。 Happypack 的核心原理就是把这部分任务分解到多个进程去并行处理，从而减少了总的构建时间。

需要配置哪些 loader 使用 Happypack 就要改写那些配置，比如你想要修改 babel 为多核编译:

module.exports = {
  module: {
    rules: [
      {
        test: /\.js?$/,
        use: ['happypack/loader?id=babel'],
        include: path.resolve(__dirname, 'src'),
      },
    ]
  },
  plugins: [
    new HappyPack({
      id: 'babel',
      loaders: [{
        loader: 'babel-loader',
        query: {  
          cacheDirectory: './webpack_cache/',
        },
      }],
    })
  ],
};

设置 id=babel，webpack 会去找 plugins 中的 id 为 babel 的插件进行处理。配置其它的 loader 的方式也是类似，不过需要注意的是有的 loader 不支持多核编译。通过这一步应该至少能让你的编译速度快 1/3。

最后一点是不要使用 webpack 里 css 模块化方案，我这里指的模块化指的是 css-loader 提供的模块化方式，我们先来看下它是怎么做的，首先它需要在你的 loader 中进行额外配置。

module.exports = webpackMerge(baseConfig, {
  module: {
    rules: [
      {
        test: /\.css/,
        use:       [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              // 开启 css 模块
              modules: true,
              // 设置命名格式
              localIdentName: '[name]__[hash:base64:5]'
            }
          }
        ]
      },
    ]
  },
} 

如果通过这种 css 模块化的方式，意味着你在写 React 组件的时候，需要这样去设置：

import styles from './index.css';

class Index extends React.Component {
  render() {
    return (
      <div className={ styles.recursive }>
        xxxx
        <h1 className={ styles.header }></h1>
      </div>
    );
  }
}
export default Index;

它相当于是在输出 css 文件的时候做了一层原名称到新名称的一次转化来保证 css 模块化的特性，输出的值就像这样：

Object {
  recursive: 'recursive__abc53xxxx',
  xxxxx: 'xxxxx__def884xxx',
}

这样做不好的点在哪：

1. 类名只能以驼峰式的形式出现，且每个类名需要额外添加到 React 组件当中
2. 编译速度慢的坑爹，如果你的应用中有大量的样式(数以万计)需要去解析，编译的时间至少增加一倍以上。

所以如果想要使用 css 模块化的可以尽量选择其它方案，比如 styledComponents 或者自己添加命名空间等等。

发布上线：

在发布上线的时候就需要考虑到很多性能优化的因素，比如如何有效地去利用浏览器的缓存，如何减少打包文件的体积等等这些因素都值得去优化。

高效利用浏览器缓存

关于如何高效地利用浏览器缓存，之前写过一篇文章详细描述了 webpack 持久化缓存实践，感兴趣可以看看。

我这里做个总结，我认为 webpack 在浏览器缓存需要做到以下几点：

1. 在多页面应用中，我们需要将公共模块进行拆包，比如 header，footer，以及一些公共区域等等，这样页面在我们的网站中进行跳转的时候由于这些公共模块存在于缓存当中，就可以直接进行加载，而不是再通过网络请求。
2. 分离业务代码和第三方的代码：之所以将业务代码和第三方代码分离出来，是因为业务代码更新频率高，而第三方代码更新迭代速度慢，所以我们将第三方代码(库，框架)进行抽离，这样可以充分利用浏览器的缓存来加载第三方库。
3. 从 js 中抽离 css，使得 css 样式和 js 逻辑相对独立，这样我们在修改样式或者页面的逻辑的时候它们将互不影响到各自的缓存。
4. 抽离异步加载的内容，比如路由切割，与首屏渲染无关的内容等等。
5. 生成稳定的 hash 值，代码修改实现 hash 值变化最小，即代码修改只影响到其对应的文件 hash 值，而不要去影响到其它文件的 hash 值。

那么我们要怎样通过 webpack 来完成上面的步骤呢？

首先不建议线上发布直接全部使用 DLLPlugin 插件来开启浏览器缓存，DLLPlugin 本身有几个缺点：

1. 首先你需要额外多配置一份 webpack 配置，增加工作量。
2. 其中一个页面用到了一个体积很大的第三方依赖库而其它页面根本不需要用到，但若直接将它打包在 dll.js 里很不值得，每次页面打开都要去加载这段无用的代码，无法使用到 webpack2 的 Code Splitting 功能。
3. 有些库你并不需要使用到全部功能，比如组件库，函数库，你可以只是需要其它一小部分内容，而 DLLPlugin 插件才不管你这些，它会通通地全部打包进去，这样你就无法去使用打包体积减小的策略了(如：tree shaking)。

我认为的正确的姿势是：

• 像 React、Vue 这样整体性偏强的库，可以生成 vendor 第三方库来去做缓存，因为你一般技术体系是固定的，一个站点里面基本上都会用到统一技术体系，所以生成 vendor 库用于缓存，这部分可以通过 DLLPlugin 去做。
• 像 antd、lodash 这种功能性组件库，可以通过 tree shaking 来进行消除，只保留有用的代码，千万不要直接打到 vendor 第三方库里，不然你将大量加载执行无用的代码。

具体如何拆分模块，我在 webpack 持久化缓存实践 已经说明，这里不再赘述。

减少打包文件的体积

想要减少打包后的体积，就需要使用到 webpack2 提供的 tree shaking 功能和 webpack3 提供的 scope hoisting 功能。

想要 tree shaking 生效，下面四点值得注意：

首先，模块引入要基于 ES6 模块机制，不再使用 commonjs 规范，因为 es6 模块的依赖关系是确定的，和运行时的状态无关，可以进行可靠的静态分析，然后清除没用的代码。而 commonjs 的依赖关系是要到运行时候才能确定下来的。

另外对于引用第三方模块使用 tree shaking 功能，可以设置 mainFields 用于配置采用哪个字段作为模块的入口描述。 为了让 tree shaking 对 es6 生效，需要配置 webpack 的文件寻找规则为如下：

module.exports = {
  resolve: {
    // 针对 npm 中的第三方模块优先采用 jsnext:main 中指向的 ES6 模块化语法的文件
    mainFields: ['jsnext:main', 'browser', 'main']
  },
};

对于一些死代码，就像下面这样：其大致原理是借助环境变量去判断执行哪个分支。

if (process.env.NODE_ENV === 'production') {
  console.log('你正在线上环境');
} else {
  console.log('你正在使用开发环境');
}

通过 shell 脚本的方式去定义的环境变量，例如 NODE_ENV=production webpack，webpack 是不认识的，对 webpack 需要处理的代码中的环境区分语句是没有作用的。

在构建线上环境代码时，需要给当前运行环境设置环境变量 NODE_ENV = 'production'，webpack 相关配置如下：

const DefinePlugin = require('webpack/lib/DefinePlugin');
module.exports = {
  plugins: [
    new DefinePlugin({
      'process.env': {
        NODE_ENV: JSON.stringify('production')
      }
    }),
  ],
};

这样设置后 tree shaking 能有效清除跟生产环境无关的代码。

最后需要强调，webpack 只是指出了哪些函数用上了哪些没用上，要剔除用不上的代码还得经过 UglifyJS 去处理一遍。 需要开启代码压缩， tree shaking 才能真正将无用的代码消除。

如果想要开启 Scope hoisting，需要在额外配置 ModuleConcatenationPlugin 插件，并且 Scope hoisting 对下面的情况不生效：

1. 按需加载的模块
2. 使用 commonjs 规范的模块
3. 被多 entry 共享的模块

这些我在 深入理解 webpack 文件打包机制 都有详细阐述，这里不多说了。

压缩代码

压缩代码可以使用 UglifyJsPlugin 这个插件对代码进行压缩，不过用过 UglifyJsPlugin 的你一定会发现在构建用于开发环境的代码时很快就能完成，但在构建用于线上的代码时构建一直卡在一个时间点迟迟没有反应，其实卡住的这个时候就是在进行代码压缩。

由于压缩 JavaScript 代码需要先把代码解析成用 Object 抽象表示的 AST 语法树，再去应用各种规则分析和处理 AST，导致这个过程计算量巨大，耗时非常多。

遇到这种情况可以改用 ParallelUglifyPlugin 插件，当 webpack 有多个 JS 文件需要输出和压缩时，原本会使用 UglifyJsPlugin 去一个个挨着压缩再输出， 但是 ParallelUglifyPlugin 则会开启多个子进程，把对多个文件的压缩工作分配给多个子进程去完成，每个子进程其实还是通过 UglifyJsPlugin 去压缩代码，但是变成了并行执行。 所以 ParallelUglifyPlugin 能更快的完成对多个文件的压缩工作。

压缩 CSS 代码的话，因为使用到 extract-text-webpack-plugin 插件将代码从 js 中分离出来，可以通过 optimize-css-assets-webpack-plugin 插件进行压缩，详细的配置项可以看：optimize-css-assets-webpack-plugin

输入分析：

上面讲了很多优化方式，但是无法面面俱到，对此你需要对打包输出结果做分析，以确认下一步的优化思路。这里推荐两个打包分析工具：

1. 官方的可视化分析工具 Webpack Analyse
2. webpack-bundle-analyzer 插件

简单地介绍下第二种方式，接入方式很简单：

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
 
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}

当你启动 webpack 时候，会唤起浏览器弹出 treemap，通过分析图可以清楚地看到：

• 打包出的文件中都包含了什么
• 每个文件的尺寸在总体中的占比，一眼看出哪些文件尺寸大
• 模块之间的包含关系

结语

本文更多地介绍一些思路，详细的优化步骤可以自己去尝试，你肯定会有更多的收获的！

参考链接：

• 深入浅出 webpack

原文地址

深入理解 CSS 属性 z-index

前言

最近在使用 CSS3 动画的时候遇到一个 DOM 层叠的问题，故此重新学习了一下 z-index，感觉这个 CSS 属性还是挺复杂的，希望本文可以帮助你重新认识 z-index 的魅力。

事情的经过是这样的(背景有点长)，最近在写下面这样的列表页：

然后给每个产品项添加一个 CSS3 动画，动画效果大概像这样: demo 地址

实现后的效果大概是这样的(截图有点糊，建议点 demo 地址查看)：

在 Chrome 上显示正常，但是从 Safari 打开，就发现不得了了，动画十分卡顿：

在切换不同的产品项的时候会发现页面动画明显卡顿，想到这，其实这难不倒我，于是我就给每个产品项添加 3D 动画硬件加速，方法也十分简单，就像下面这样。

.item {
  transform: translateZ(0);      /* 或者 will-change: transform; */
}

这是一种常见的硬件加速的优化方式， 如果不懂的话可以看这个：用CSS开启硬件加速来提高网站性能

之后打开 Safari 后发现页面动画十分流畅，硬件加速的优化成功，但是随之而来又出现新的问题，也就是本文所说的 DOM 元素层叠问题。

虽然动画效果卡顿修复了，但是页面 DOM 元素层叠却出现问题：也就是下面的产品项会覆盖上面产品项右下角的入口弹框，而我们希望的正常的效果应该是这样：

遇到这样的问题，第一反应：那我将弹框的 z-index 调大不就好了，小菜一碟，但是无论我怎么调整 z-index 的值，弹框始终被下方的产品项所覆盖，一开始我也百思不得其解。

最后通过看了一些资料学习梳理，最终找到解决的办法，废话不多说，下面我就开始梳理整个 z-index 相关知识，并在最后提交上述问题的解决方案。(下文讲解会附带很多的用例，我将代码全部贴在 jsfiddle 方便查阅，读者可以点击 demo 地址查看例子)

z-index 基础

首先介绍一下 z-index，z-index 属性是用来调整元素及子元素在 z 轴上的顺序，当元素发生覆盖的时候，哪个元素在上面，哪个元素在下面。通常来说，z-index 值较大的元素会覆盖较低的元素。

z-index 的默认值为 auto，可以设置正整数，也可以设置为负整数，如果不考虑 CSS3，只有定位元素(position:relative/absolute/fixed)的 z-index 才有作用，如果你的 z-index 作用于一个非定位元素(一些 CSS3 也会生效)，是不起任何作用的。比如: demo 地址

当你为 DOM 元素设置了定位后，该元素的 z-index 就会生效，默认为 auto，你可以简单将它等同于 z-index: 0，比如：demo 地址，也就是说，z-index 生效的前提条件是必须要设置定位属性(或者一些 CSS3 属性)，才能够生效

看完 demo 你可能会觉得纳闷，为啥我单单只设置了一个 position 属性，没设置 z-index 值，为啥红色方格会覆盖蓝色方格，这里就涉及到了 z-index 层叠水平的知识。

层叠水平(stacking level)

一个 DOM 元素，在不考虑层叠上下文的情况下，会按照层叠水平决定元素在 z 轴上的显示顺序，通俗易懂地讲，不同的 DOM 元素组合在一起发生重叠的时候，它们的的显示顺序会遵循层叠水平的规则，而 z-index 是用来调整某个元素显示顺序，使该元素能够上浮下沉。

那么层叠水平是什么样的呢？下面就是著名的 7 阶层叠水平(stacking level)

可以看出，层叠水平规范了元素重叠时候的呈现规则，有了这个规则，我们也就不难解释为何之前例子中红色方格会覆盖蓝色方格。因为当你设置了 position: relative 属性后，元素 z-index:auto 生效导致层叠水平提升，比普通内联元素来的高，所以红色方格会显示在上方。

知道了层叠水平的规则后，下面我就举几个例子来说明：

inline/inline-block 元素高于浮动元素

首先是 inline/inline-block 元素高于浮动元素，demo 地址

可以很清晰的看出文字(inline元素)覆盖了图片(浮动元素).

inline/inline-block 元素高于 block 元素

demo 地址

红色方格(inline-block)覆盖绿色方格(block)，但是由于文字(display:block)属于 inline 水平，与红色方格(inline-block) 同级，遵循后来居上(接下来会解释)原则，没有被 inline-block 元素覆盖。

元素层叠水平相当

那么当两个元素层叠水平相同的时候，这时候就要遵循下面两个准则：

1. 后来居上原则
2. 谁 z-index 大，谁在上的准则

后来居上的原则

后来居上准则就是说，当元素层叠水平相同的时候后面的 DOM 会覆盖前面的 DOM 元素。这个很好理解，不过多解释了。这也就是我们经常会看到为什么后面的元素会覆盖前面的元素。正如前面看到的那个例子，由于文字(display:block)属于 inline 水平，与红色方格(inline-block) 同级，遵循后来居上(接下来会解释)原则，没有被 inline-block 元素覆盖，这里我就不另外贴例子来说明了。

谁 z-index 大，谁在上

因为 z-index 的存在，导致元素在相同的层叠上下文中的顺序是可以调整的，那么在 z-index 负值和正值的范围内，在这两个区间内的话 DOM 元素的 z-index 值越大，显示顺序就会越靠前。

知道了层叠水平之后，基本上只要元素在同一个层叠上下文中的显示顺序就确定了，但是如果是在不同的层叠上下文中呢，又是如何显示的呢？这个层叠上下文又是什么意思？别急，接着往下看。

层叠上下文

层叠上下文，你可以理解为 JS 中的作用域，一个页面中往往不仅仅只有一个层叠上下文(因为有很多种方式可以生成层叠上下文，只是你没有意识到而已)，在一个层叠上下文内，我们按照层叠水平的规则来堆叠元素。

介绍完层叠上下文的概念，我们先来看看哪些方式可以创建层叠上下文？

正常情况下，一共有三种大的类型创建层叠上下文：

1. 默认创建层叠上下文
2. 需要配合 z-index 触发创建层叠上下文
3. 不需要配合 z-index 触发创建层叠上下文

默认创建层叠上下文

默认创建层叠上下文，只有 HTML 根元素，这里你可以理解为 body 标签。它属于根层叠上下文元素，不需要任何 CSS 属性来触发。

需要配合 z-index 触发创建层叠上下文

依赖 z-index 值创建层叠上下文的情况：

1. position 值为 relative/absolute/fixed(部分浏览器)
2. flex 项(父元素 display 为 flex|inline-flex)，注意是子元素，不是父元素创建层叠上下文

这两种情况下，需要设置具体的 z-index 值，不能设置 z-index 为 auto，这也就是 z-index: auto 和 z-index: 0 的一点细微差别。

前面我们提到，设置 position: relative 的时候 z-index 的值为 auto 会生效，但是这时候并没有创建层叠上下文，当设置 z-index 不为 auto，哪怕设置 z-index: 0 也会触发元素创建层叠上下文。

不需要配合 z-index 触发创建层叠上下文

这种情况下，基本上都是由 CSS3 中新增的属性来触发的，常见的有：

1. 元素的透明度 opacity 小于1
2. 元素的 mix-blend-mode 值不是 normal
3. 元素的以下属性的值不是 none：
   • transform
   • filter
   • perspective
   • clip-path
   • mask / mask-image / mask-border
4. 元素的 isolution 属性值为 isolate
5. 元素的 -webkit-overflow-scrolling 属性为 touch
6. 元素的 will-change 属性具备会创建层叠上下文的值

介绍完如何创建层叠上下文概念以及创建方式后，需要说明的是，创建了层叠上下文的元素可以理解局部层叠上下文，它只影响其子孙代元素，它自身的层叠水平是由它的父层叠上下文所决定的。

比较两个 DOM 元素显示顺序

接下来就来总结一下如何比较两个 DOM 元素的显示顺序呢？

1. 如果是在相同的层叠上下文，按照层叠水平的规则来显示元素
2. 如果是在不同的层叠上下文中，先找到共同的祖先层叠上下文，然后比较共同层叠上下文下这个两个元素所在的局部层叠上下文的层叠水平，

千言万语浓缩于这两句话中，但是里面注意的点有很多，我们先来看第一点：

共同层叠上下文

如果是在相同的层叠上下文，按照层叠水平的规则来显示元素，这个之前在介绍层叠水平的时候就已经介绍了，值得注意的是，父子关系的元素很可能在相同的层叠上下文，这种情况下元素的层级比较也是按照层叠水平的规则来显示。

举个例子：demo 地址

.box 元素和其子元素 img 的比较：因为 img 和 .box 属于相同的层叠上下文中，因为 img z-index 为 -1，所以下沉到父元素的下面，父元素覆盖了图片，但是 img 还是在 body 的背景色之上，因为遵循 7 阶层叠水平，最底下一定会是层叠上下文(body 元素)的 background 或者 border。

但是如果我们让 .box 元素创建局部层叠上下文的时候就不一样了，.box 元素和 img 元素的也是同处于相同层叠上下文，只不过上下文切换为 .box 创建的局部层叠上下文。

demo 地址

你会发现：img 元素覆盖了 .box 的背景色，因为层叠上下文的背景色永远是在最低下，层叠上下文由 body 元素变为了 .box 元素，但是如果是 .box 下的 span 元素和 img 元素的比较，inline 元素高于 z-index 为负值的元素，所以 2222 显示在图片之上。

通过这个例子是想说明，父子元素的层叠比较有可能父元素是局部层叠上下文，也可能不是局部层叠上下文，那么就需要去寻找共同的层叠上下文。

不同的层叠上下文

这个就比较复杂了，可以总结成一句话：打狗还得看主人，下面让我先画了草图来说明一下：

页面中常见的 DOM 树大概是长这样：这里 Root、ParentX、ChildX 均为层叠上下文元素，并非一定是 ABCD 的父元素

1. A 元素想跟 B 或者 ChildB 元素比较，很高兴，它们属于相同层叠上下文(ChildB)下，根据层叠水平去判断就可以了
2. 如果 A 元素想跟 C 或者 ChildA 比较，那就去找它们共同的祖先层叠上下文(ParentB)，找到之后，就根据祖先层叠上下文下两个元素所在的局部层叠上下文比较层叠水平(这里就是 ChildA 和 ChildB 去比较)
3. 同理，如果 A 想跟 D 一决雌雄，那么就去找祖先层叠上下文(Root)，然后去比较 ParentA 和 ParentB 的层叠水平即可

是不是很简单，下面再通过两个简单的小示例来说明一下：

示例一：demo 地址

虽然 childA 的 z-index: 9999 非常大，但是在跟 parentB 或者 childB 比较的时候，它没资格去比，只能让它的老大 parentA 去比较，parentA 跟 parentB 一比较，才发现：妈呀，原来你的 z-index 为 2 比我还大，失敬失敬，所以 childA 和 parentA 只好乖乖呆在 parentB 底下。

如果我们将例子稍微改下，让 parentA 不再创建新的层叠上下文元素：demo 地址

当 parentA 不再创建层叠上下文之后，childA 想跟 childB 比较，就不再受限于 parentA，而是直接跟 parentB 直接比较(因为 childA 和 parentB 在同一个层叠上下文)，显然 childA 在最上方，这也就是 childA 覆盖 parentB 的原因。

问题的解决方案

理论知识已经介绍完了，如果你理解了上面的理论，这个问题应该是小菜一碟，下面就来说说一开始问题的解决方案：

因为在每个产品项上添加了 transform: translateZ(0) 导致每一个产品项都创建了一个层叠上下文，根据前面提到规则，每个产品项里面的 DOM 元素的都是相互独立的，取决于每个产品项(每个局部层叠上下文)，又由于这些产品项的层叠水平一致(与 z-index: auto 相同)，遵循后来居上原则，这才导致了后面的元素会去覆盖前面的元素。举个简单的例子: demo 地址

就像这样，即使你在 child 上添加多大的 z-index 属性都不会改变它的层叠水平，唯一的办法就是改变 item 的 z-index 数值，由于我们覆盖的部分比较特殊，仅仅只是弹框部分，而弹框部分默认是不显示的，只有当鼠标悬浮到入口的时候才会显示，最简单的方式就是，当鼠标 hover 到 item 上的时候，将其 z-index 值变大即可，破坏后来居上的特性: demo 地址

最终简化效果：

最佳实践

说到这其实可以结束了，我在学习的过程中，看了张鑫旭大佬之前录的视频，他提出了一些最佳实践，我觉得挺不错的，这里也简单地介绍一下：

1. 不犯二准则：对于非浮层元素，避免设置 z-index 值，z-index 值没有任何道理需要超过 2
2. 对于浮层元素，可以通过 JS 获取 body 下子元素的最大 z-index 值，然后在此基础上加 1 作为浮层元素的 z-index 值

对于非浮层元素，不要过多地去运用 z-index 去调整显示顺序，要灵活地去运用层叠水平和后来居上的准则去让元素获得正确的显示，如果是在要设置 z-index 去调整，不建议非浮层元素 z-index 数值超过 2，对于 DOM 元素，-1, 0, 1, 2 足够让元素有正确的显示顺序。

对于浮层元素，往往是第三方组件开发，当你无法确认你的浮层是否会百分百覆盖在 DOM 树上的时候，你可以去动态获取页面 body 元素下所有子元素 z-index 的最大值，在此基础加一作为浮层元素 z-index 值，用于保证该浮层元素能够显示在最上方。

结尾

最后的最后，本篇深入 z-index 属性已经就完结了，感觉 CSS 属性有许许多多的彩蛋，接下来有时间多接触，多总结，有时间会继续分享出来。

参考链接

• CSS深入理解之z-index

原文地址

React 同构应用 PWA 升级指南

前言

最近在给我的博客网站 PWA 升级，顺便就记录下 React 同构应用在使用 PWA 时遇到的问题，这里不会从头开始介绍什么是 PWA，如果你想学习 PWA 相关知识，可以看下下面我收藏的一些文章：

• 您的第一个 Progressive Web App
• 【Service Worker】生命周期那些事儿
• 【PWA学习与实践】(1) 2018，开始你的PWA学习之旅
• Progressive Web Apps (PWA) 中文版

PWA 特性

PWA 不是单纯的某项技术，而是一堆技术的集合，比如：Service Worker，manifest 添加到桌面，push、notification api 等。

而就在前不久时间，IOS 11.3 刚刚支持 Service worker 和类似 manifest 添加到桌面的特性，所以这次 PWA 改造主要还是实现这两部分功能，至于其它的特性，等 iphone 支持了再升级吧。

Service Worker

service worker 在我看来，类似于一个跑在浏览器后台的线程，页面第一次加载的时候会加载这个线程，在线程激活之后，通过对 fetch 事件，可以对每个获取的资源进行控制缓存等。

明确哪些资源需要被缓存？

那么在开始使用 service worker 之前，首先需要清楚哪些资源需要被缓存?

缓存静态资源

首先是像 CSS、JS 这些静态资源，因为我的博客里引用的脚本样式都是通过 hash 做持久化缓存，类似于：main.ac62dexx.js 这样，然后开启强缓存，这样下次用户下次再访问我的网站的时候就不用重新请求资源。直接从浏览器缓存中读取。对于这部分资源，service worker 没必要再去处理，直接放行让它去读取浏览器缓存即可。

我认为如果你的站点加载静态资源的时候本身没有开启强缓存，并且你只想通过前端去实现缓存，而不需要后端在介入进行调整，那可以使用 service worker 来缓存静态资源，否则就有点画蛇添足了。

缓存页面

缓存页面显然是必要的，这是最核心的部分，当你在离线的状态下加载页面会之后出现：

究其原因就是因为你在离线状态下没办法加载页面，现在有了 service worker，即使你在没网络的情况下，也可以加载之前缓存好的页面了。

缓存后端接口数据

缓存接口数据是需要的，但也不是必须通过 service worker 来实现，前端存放数据的地方有很多，比如通过 localstorage，indexeddb 来进行存储。这里我也是通过 service worker 来实现缓存接口数据的，如果想通过其它方式来实现，只需要注意好 url 路径与数据对应的映射关系即可。

缓存策略

明确了哪些资源需要被缓存后，接下来就要谈谈缓存策略了。

页面缓存策略

因为是 React 单页同构应用，每次加载页面的时候数据都是动态的，所以我采取的是：

1. 网络优先的方式，即优先获取网络上最新的资源。当网络请求失败的时候，再去获取 service worker 里之前缓存的资源
2. 当网络加载成功之后，就更新 cache 中对应的缓存资源，保证下次每次加载页面，都是上次访问的最新资源
3. 如果找不到 service worker 中 url 对应的资源的时候，则去获取 service worker 对应的 /index.html 默认首页

// sw.js
self.addEventListener('fetch', (e) => {
  console.log('现在正在请求：' + e.request.url);
  const currentUrl = e.request.url;
  // 匹配上页面路径
  if (matchHtml(currentUrl)) {
    const requestToCache = e.request.clone();
    e.respondWith(
      // 加载网络上的资源
      fetch(requestToCache).then((response) => {
        // 加载失败
        if (!response || response.status !== 200) {
          throw Error('response error');
        }
        // 加载成功，更新缓存
        const responseToCache = response.clone();
        caches.open(cacheName).then((cache) => {
          cache.put(requestToCache, responseToCache);
        });
        console.log(response);
        return response;
      }).catch(function() {
        // 获取对应缓存中的数据，获取不到则退化到获取默认首页
        return caches.match(e.request).then((response) => {
           return response || caches.match('/index.html');
        });
      })
    );
  } 
});

为什么存在命中不了缓存页面的情况？

1. 首先需要明确的是，用户在第一次加载你的站点的时候，加载页面后才会去启动 sw，所以第一次加载不可能通过 fetch 事件去缓存页面
2. 我的博客是单页应用，但是用户并不一定会通过首页进入，有可能会通过其它页面路径进入到我的网站，这就导致我在 install 事件中根本没办法指定需要缓存那些页面
3. 最终实现的效果是：用户第一次打开页面，马上断掉网络，依然可以离线访问我的站点

结合上面三点，我的方法是：第一次加载的时候会缓存 /index.html 这个资源，并且缓存页面上的数据，如果用户立刻离线加载的话，这时候并没有缓存对应的路径，比如 /archives 资源访问不到，这返回 /index.html 走异步加载页面的逻辑。

在 install 事件缓存 /index.html，保证了 service worker 第一次加载的时候缓存默认页面，留下退路。

import constants from './constants';
const cacheName = constants.cacheName;
const apiCacheName = constants.apiCacheName;
const cacheFileList = ['/index.html'];

self.addEventListener('install', (e) => {
  console.log('Service Worker 状态： install');
  const cacheOpenPromise = caches.open(cacheName).then((cache) => {
    return cache.addAll(cacheFileList);
  });
  e.waitUntil(cacheOpenPromise);
});

在页面加载完后，在 React 组件中立刻缓存数据：

// cache.js
import constants from '../constants';
const apiCacheName = constants.apiCacheName;

export const saveAPIData = (url, data) => {
  if ('caches' in window) {
    // 伪造 request/response 数据
    caches.open(apiCacheName).then((cache) => {
      cache.put(url, new Response(JSON.stringify(data), { status: 200 }));
    });
  }
};

// React 组件
import constants from '../constants';
export default class extends PureComponent {
  componentDidMount() {
    const { state, data } = this.props;
    // 异步加载数据
    if (state === constants.INITIAL_STATE || state === constants.FAILURE_STATE) {
      this.props.fetchData();
    } else {
    	// 服务端渲染成功，保存页面数据
      saveAPIData(url, data);
    }
  }
}

这样就保证了用户第一次加载页面，立刻离线访问站点后，虽然无法像第一次一样能够服务端渲染数据，但是之后能通过获取页面，异步加载数据的方式构建离线应用。

用户第一次访问站点，如果在不刷新页面的情况切换路由到其他页面，则会异步获取到的数据，当下次访问对应的路由的时候，则退化到异步获取数据。

当用户第二次加载页面的时候，因为 service worker 已经控制了站点，已经具备了缓存页面的能力，之后在访问的页面都将会被缓存或者更新缓存，当用户离线访问的的时候，也能访问到服务端渲染的页面了。

接口缓存策略

谈完页面缓存，再来讲讲接口缓存，接口缓存就跟页面缓存很类似了，唯一的不同在于：页面第一次加载的时候不一定有缓存，但是会有接口缓存的存在(因为伪造了 cache 中的数据)，所以缓存策略跟页面缓存类似：

1. 网络优先的方式，即优先获取网络上接口数据。当网络请求失败的时候，再去获取 service worker 里之前缓存的接口数据
2. 当网络加载成功之后，就更新 cache 中对应的缓存接口数据，保证下次每次加载页面，都是上次访问的最新接口数据

所以代码就像这样(代码类似，不再赘述):

self.addEventListener('fetch', (e) => {
  console.log('现在正在请求：' + e.request.url);
  const currentUrl = e.request.url;
  if (matchHtml(currentUrl)) {
    // ...
  } else if (matchApi(currentUrl)) {
    const requestToCache = e.request.clone();
    e.respondWith(
      fetch(requestToCache).then((response) => {
        if (!response || response.status !== 200) {
          return response;
        }
        const responseToCache = response.clone();
        caches.open(apiCacheName).then((cache) => {
          cache.put(requestToCache, responseToCache);
        });
        return response;
      }).catch(function() {
        return caches.match(e.request);
      })
    );
  }
});

这里其实可以再进行优化的，比如在获取数据接口的时候，可以先读取缓存中的接口数据进行渲染，当真正的网络接口数据返回之后再进行替换，这样也能有效减少用户的首屏渲染时间。当然这可能会发生页面闪烁的效果，可以添加一些动画来进行过渡。

其它问题

到现在为止，已经基本上可以实现 service worker 离线缓存应用的效果了，但是还有仍然存在一些问题：

快速激活 service worker

默认情况下，页面的请求（fetch）不会通过 sw，除非它本身是通过 sw 获取的，也就是说，在安装 sw 之后，需要刷新页面才能有效果。sw 在安装成功并激活之前，不会响应 fetch或push等事件。

因为站点是单页面应用，这就导致了你在切换路由(没有刷新页面)的时候没有缓存接口数据，因为这时候 service worker 还没有开始工作，所以在加载 service worker 的时候需要快速地激活它。代码如下：

self.addEventListener('activate', (e) => {
  console.log('Service Worker 状态： activate');
  const cachePromise = caches.keys().then((keys) => {
    return Promise.all(keys.map((key) => {
      if (key !== cacheName && key !== apiCacheName) {
        return caches.delete(key);
      }
      return null;
    }));
  });
  e.waitUntil(cachePromise);
  // 快速激活 sw，使其能够响应 fetch 事件
  return self.clients.claim();
});

有的文章说还需要在 install 事件中添加 self.skipWaiting(); 来跳过等待时间，但是我在实践中发现即使不添加也可以正常激活 service worker，原因不详，有读者知道的话可以交流下。

现在当你第一次加载页面，跳转路由，立刻离线访问的页面，也可以顺利地加载页面了。

不要强缓存 sw.js

用户每次访问页面的时候都会去重新获取 sw.js，根据文件内容跟之前的版本是否一致来判断 service worker 是否有更新。所以如果你对 sw.js 开启强缓存的话，就将陷入死循环，因为每次页面获取到的 sw.js 都是一样，这样就无法升级你的 service worker。

另外对 sw.js 开启强缓存也是没有必要的：

1. 本身 sw.js 文件本身就很小，浪费不了多少带宽，觉得浪费可以使用协商缓存，但额外增加开发负担
2. sw.js 是在页面空闲的时候才去加载的，并不会影响用户首屏渲染速度

避免改变 sw 的 URL

在 sw 中这么做是“最差实践”，要在原地址上修改 sw。

举个例子来说明为什么：

1. index.html 注册了 sw-v1.js 作为 sw
2. sw-v1.js 对 index.html 做了缓存，也就是缓存优先（offline-first）
3. 你更新了 index.html 重新注册了在新地址的 sw sw-v2.js

如果你像上面那么做，用户永远也拿不到 sw-v2.js，因为 index.html 在 sw-v1.js 缓存中，这样的话，如果你想更新为 sw-v2.js，还需要更改原来的 sw-v1.js。

测试

自此，我们已经完成了使用 service worker 对页面进行离线缓存的功能，如果想体验功能的话，访问我的博客：https://lindongzhou.com

随意浏览任意的页面，然后关掉网络，再次访问，之前你浏览过的页面都可以在离线的状态下进行访问了。

IOS 需要 11.3 的版本才支持，使用 Safari 进行访问，Android 请选择支持 service worker 的浏览器

manifest 桌面应用

前面讲完了如何使用 service worker 来离线缓存你的同构应用，但是 PWA 不仅限于此，你还可以使用设置 manifest 文件来将你的站点添加到移动端的桌面上，从而达到趋近于原生应用的体验。

使用 webpack-pwa-manifest 插件

我的博客站点是通过 webpack 来构建前端代码的，所以我在社区里找到 webpack-pwa-manifest 插件用来生成 manifest.json。

首先安装好 webpack-pwa-manifest 插件，然后在你的 webpack 配置文件中添加：

// webpack.config.prod.js
const WebpackPwaManifest = require('webpack-pwa-manifest');
module.exports = webpackMerge(baseConfig, {
  plugins: [
    new WebpackPwaManifest({
      name: 'Lindz\'s Blog',
      short_name: 'Blog',
      description: 'An isomorphic progressive web blog built by React & Node',
      background_color: '#333',
      theme_color: '#333',
      filename: 'manifest.[hash:8].json',
      publicPath: '/',
      icons: [
        {
          src: path.resolve(constants.publicPath, 'icon.png'),
          sizes: [96, 128, 192, 256, 384, 512], // multiple sizes
          destination: path.join('icons')
        }
      ],
      ios: {
        'apple-mobile-web-app-title': 'Lindz\'s Blog',
        'apple-mobile-web-app-status-bar-style': '#000',
        'apple-mobile-web-app-capable': 'yes',
        'apple-touch-icon': '//xxx.com/icon.png',
      },
    })
  ]
})

简单地阐述下配置信息：

1. name: 应用名称，就是图标下面的显示名称
2. short_name: 应用名称，但 name 无法显示完全时候则显示这个
3. background_color、theme_color：顾名思义，相应的颜色
4. publicPath: 设置 cdn 路径，跟 webpack 里的 publicPath 一样
5. icons: 设置图标，插件会自动帮你生成不同 size 的图片，但是图片大小必须大于最大 sizes
6. ios： 设置在 safari 中如何去添加桌面应用

设置完之后，webpack 会在构建过程中生成相应的 manifest 文件，并在 html 文件中引用，下面就是生成 manifest 文件：

{
  "icons": [
    {
      "src": "/icons/icon_512x512.79ddc5874efb8b481d9a3d06133b6213.png",
      "sizes": "512x512",
      "type": "image/png"
    },
    {
      "src": "/icons/icon_384x384.09826bd1a5d143e05062571f0e0e86e7.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "/icons/icon_256x256.d641a3644ce20c06855db39cfb2f7b40.png",
      "sizes": "256x256",
      "type": "image/png"
    },
    {
      "src": "/icons/icon_192x192.8f11e077242cccd9c42c0cbbecd5149c.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon_128x128.cc0714ab18fa6ee6de42ef3d5ca8fd09.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "/icons/icon_96x96.dbfccb1a5cef8093a77c079f761b2d63.png",
      "sizes": "96x96",
      "type": "image/png"
    }
  ],
  "name": "Lindz's Blog",
  "short_name": "Blog",
  "orientation": "portrait",
  "display": "standalone",
  "start_url": ".",
  "description": "An isomorphic progressive web blog built by React & Node",
  "background_color": "#333",
  "theme_color": "#333"
}

html 中会引用这个文件，并且加上对 ios 添加桌面应用的支持，就像这样。

<!DOCTYPE html>
<html lang=en>
<head>
  <meta name=apple-mobile-web-app-title content="Lindz's Blog">
  <meta name=apple-mobile-web-app-capable content=yes>
  <meta name=apple-mobile-web-app-status-bar-style content=#838a88>
  <link rel=apple-touch-icon href=xxxxx>
  <link rel=manifest href=/manifest.21d63735.json>
</head>
</html>

就这么简单，你就可以使用 webpack 来添加你的桌面应用了。

测试

添加完之后你可以通过 chrome 开发者工具 Application - Manifest 来查看你的 mainfest 文件是否生效：

这样说明你的配置生效了，安卓机会自动识别你的配置文件，并询问用户是否添加。

结尾

讲到这差不多就完了，等以后 IOS 支持 PWA 的其它功能的时候，到时候我也会相应地去实践其它 PWA 的特性的。现在 IOS 11.3 也仅仅支持 PWA 中的 service worker 和 app manifest 的功能，但是相信在不久的将来，其它的功能也会相应得到支持，到时候相信 PWA 将会在移动端绽放异彩的。

原文地址

让 BAT Offer 不再难拿

最近有幸受老师邀请，总结一篇关于应届生校招求职的文章，我将它分享出来，希望可以帮助到跟我曾经一样找工作迷茫的同学。

个人介绍

首先介绍一下个人情况，我是某双一流大学的学生，专业是软件工程，在大学期间一直学习从事 Web 前端相关的工作，大三暑期曾在深圳腾讯实习三个月，秋招非常荣幸先后收获阿里、腾讯、头条、美团等企业 offer，最终选择到阿里工作，接下来我就从一名前端工程师的角度来谈谈一名应届生应该如何去获得大公司的校招 offer。

面试流程

大公司面试无论是实习还是校招，普遍存在面试轮次多，面试周期长的特点，就拿腾讯来说，如果你想成为暑期实习生，大概需要四到五轮面试，3-4 轮技术面+一轮 HR 面试，每次面试时间大概在 0.5-1 小时之间，推荐对自己能力没有把握或者缺少工作经验的同学尽可能在大三下学期找找实习，去自己想去的公司实习，因为大三的暑期实习既可以丰富你的履历，并且实习期间好好表现都是可以相对容易地通过转正，拿到校招 offer。

在申请实习或者校招 offer 的时候，尽可能多找人帮忙内推(ps: 实在找不到人的话可以找我)，因为大公司部门比较多，你如果直接从官网上网申的话，简历不容易被人查看，找认识的师兄师姐帮忙内推的优势在于：

1. 能够更有效增加你的简历的曝光，让部门主管能够直接查阅到你的简历
2. 加快面试进度，联系师兄师姐提前知道面试结果

内推或者网申(可能有笔试)完之后，就等待面试官打电话给你，一般他们会跟你通过电话或者短信确认现在是否方便或者约个时间进行面试，面试的方式也分为电话面试，视频面试，现场面试等等。

无论是哪种类型的面试，内容大致上都是一致的(除了现场面试可能要求你手写代码外)，我将专业技能面试分为以下几个部分：

1. 自我介绍
2. 计算机基础知识
3. 前端知识
4. 面试者提问环节

自我介绍

首先是自我介绍，面试前最好能够准备一段不少于 30 秒的自我介绍并对着镜子反复练习，可以介绍介绍你的名字，学校，专业，对你投递岗位的理解等等，在面试过程中尽可能流利地叙述，而不是介绍时磕磕碰碰，给面试官留下不好的印象。

计算机基础知识

第二部分是计算机基础知识，对于应届生来说，面试官无非喜欢考察计算机网络，操作系统，数据结构与算法这三大类。当然根据你应聘的岗位有所不同，如果你是应聘一名前端工程师，考察网络的知识相对较多，对于操作系统、数据结构和算法的考察会相对较少，如果你是应聘一个后端工程师的话，那么涉及到操作系统的知识肯定会相对更多。同理算法工程师就会涉及到更多数据结构和算法的知识。

面试网络知识的话，可以多准备 HTTP/TCP 相关的知识，比如我就常被问到：

1. HTTP 状态码，从浏览器打开一个网址背后都经历了什么
2. TCP 与 UDP 的区别，为什么 TCP 需要三次握手，四次挥手等等

前端知识

第三大块也就是你应聘的岗位相关的知识内容了，比如拿前端来说，一般前端知识可以分为三大块：语言基础，框架以及实践。

语言基础一般会考察你对 JS 语言本身的理解，比如说：闭包，继承，作用域，this 用法，ES6 语法等等，也会问你关于 HTML/CSS 的基础知识。

框架的话不仅仅是局限于考察对框架的用法，一般是结合你的简历内容来进行提问，比如你在简历上写你熟悉 React，面试官可能就会问你 virtual-dom 是怎么实现的，Redux 设计**等等，如果你简历上写熟悉 Vue，那可能就会问你数据双向绑定是怎么实现的等等。

还有就是你的实践部分，这部分面试官会结合你的简历提到的一些经历，比如你有什么实习经历阿，或者在学校做过什么项目来进行提问。可能会像这样问你：

1. 你在这个项目中（或者实习经历）遇到最大的挑战(难题)是什么，你怎么解决的
2. 你在项目开发的过程中运用了什么技术，为什么会使用到这些技术等等

面试者提问环节

一般面试结束后面试官都会问你，还有什么问题想问我，这时候你可以就你感兴趣的内容进行提问，比如我一般就会问下面类型的问题：

1. 如果我有幸被录用了，我会从事什么样的工作内容
2. 团队组织结构是怎么样的，主要负责什么样的产品
3. 工作平时加班多吗，一般几点下班
4. 就刚才的面试来看，你觉得我有什么不足之处

这就是标准的面试过程，面试结束后如果你通过面试的话，一般一周内会给答复或者进行下一轮面试。

最后需要强调的是，公司面试周期一般都会比较长，可能你从二月底开始面试，到了四月份你才会收到 offer，所以你应该多投投几家公司，不要在一棵树上吊死，不要抱着非 xxx 公司不去的心态，因为面试这种东西其实是很玄学的，七分实力，三分运气，可能你觉得良好，但是面试官却把你 pass 掉了，所以放平常心，多试试几家公司，说不定会有意外的收获。

面试准备

前面介绍了面试流程中的一些注意事项，下面就来说说如何去做面试前的准备。我将面试准备分为三个部分：

1. 准备简历
2. 专业知识梳理
3. 面试结束后

准备简历

我看很多人写的简历，发现他们写的都很啰嗦，让人一眼看过去抓不住重点，我建议最好把简历精简一下，控制在 1-2 页，写的经历和项目跟你应聘的岗位有强相关，无关的经历就不要写了，写了反而显得啰嗦。像我百用不烂的的模板就像下图这样：

另外还有三点需要注意：

1. 描述经历或者项目的时候尽可能描述跟自己负责的模块，无关的内容就不要写了，不然被问到了可能会问惨你
2. 写完简历的时候最好以 pdf 的格式进行存储，这样保证面试官打开的时候排版不会乱掉
3. 简历名称最好写成像 姓名-应聘岗位-xx大学-xx专业-手机号，这样方便 HR 保留存储你的简历，不要直接取名为简历就直接发给 HR

简历是你获得面试的第一步，简历的好坏需要自己用心准备，希望同学们提前认真地准备好一份觉得让自己满意的简历，以免到时候太仓促。

专业知识梳理

这部分内容肯定是需要通过自己的不断积累的，不可能说你看了两天 JS 语法就跑来面试，学了两天 Java 就来面试后端工程师。

我们经常会通过网上文章学习内容，我的建议：善于使用浏览器的书签帮助你自己整体知识。

1. 比如说你今天看到一篇文章，但是没时间看完消化，你可以把它放到一个书签(do it later)以免之后找不到，等自己有时间了再回过头来继续看
2. 将自己看过的，觉得不错的文章进行分类整理放在书签中，方便以后面试前可以复习

网路上学习技术的途径也很多：

1. 如果想看别人写的文章，可以多逛逛掘金、知乎专栏等等
2. 如果像通过看视频来学习的话，可以通过慕课网平台，上面有不少高质量视频可以学习
3. 遇到问题善用搜索引擎，基本上你遇到的问题都可以通过谷歌/Stackoverflow 上得到答案

每个岗位都有自己不同的知识体系，在其它领域我也不是专业的，就不班门弄斧了，我就拿前端工程师角度来看，作为一名应届前端工程师，至少要对整体知识体系有自己的理解(如果不是从事前端开发的可以跳过)：

每个岗位都有对应的知识体系，我这里提供一个思路，不管是你在准备面试还是平时技术积累，通过对自己领域的知识梳理，知道自己不足的地方，对自己不熟悉的知识进行查缺补漏。(如果你对整个前端知识体系也不是特别了解，也可以照着我整体的知识体系来进行准备)

面试结束后

面试其实很多情况下都是很类似的，有的时候一面和二面的面试官都会问到相同的问题，所以在面试结束可以总结总结刚才面试中遇到的问题，为什么答不上来，如果是之前没准备的知识，可以去复习复习，这样下次再碰到类似的题目，你就可以对答如流了。

原文地址

webpack 持久化缓存实践

前言

最近在看 webpack 如何做持久化缓存的内容，发现其中还是有一些坑点的，正好有时间就将它们整理总结一下，读完本文你大致能够明白：

1. 什么是持久化缓存，为什么做持久化缓存?
2. webpack 如何做持久化缓存？
3. webpack 做缓存的一些注意点。

持久化缓存

首先我们需要去解释一下，什么是持久化缓存，在现在前后端分离的应用大行其道的背景下，前端 html，css，js 往往是以一种静态资源文件的形式存在于服务器，通过接口来获取数据来展示动态内容。这就涉及到公司如何去部署前端代码的问题，所以就涉及到一个更新部署的问题，是先部署页面，还是先部署资源？

1. 先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本资源当做新版本缓存起来，其结果就是：用户访问到一个样式错乱的页面，除非手动去刷新，否则在资源缓存过期之前，页面会一直处于错乱的状态。
2. 先部署资源，再部署页面：在部署时间间隔内，有旧版本的资源本地缓存的用户访问网站，由于请求的页面是旧版本，资源引用没有改变，浏览器将直接使用本地缓存，这样属于正常情况，但没有本地缓存或者缓存过期的用户在访问网站的时候，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误。

所以我们需要一种部署策略来保证在更新我们线上的代码的时候，线上用户也能平滑地过渡并且正确打开我们的网站。

推荐先看这个回答：大公司里怎样开发和部署前端代码？

当你读完上面的回答，大致就会明白，现在比较成熟的持久化缓存方案就是在静态资源的名字后面加 hash 值，因为每次修改文件生成的 hash 值不一样，这样做的好处在于增量式发布文件，避免覆盖掉之前文件从而导致线上的用户访问失效。

因为只要做到每次发布的静态资源(css, js, img)的名称都是独一无二的，那么我就可以：

• 针对 html 文件：不开启缓存，把 html 放到自己的服务器上，关闭服务器的缓存，自己的服务器只提供 html 文件和数据接口
• 针对静态的 js，css，图片等文件：开启 cdn 和缓存，将静态资源上传到 cdn 服务商，我们可以对资源开启长期缓存，因为每个资源的路径都是独一无二的，所以不会导致资源被覆盖，保证线上用户访问的稳定性。
• 每次发布更新的时候，先将静态资源(js, css, img) 传到 cdn 服务上，然后再上传 html 文件，这样既保证了老用户能否正常访问，又能让新用户看到新的页面。

上面大致介绍了下主流的前端持久化缓存方案，那么我们为什么需要做持久化缓存呢？

1. 用户使用浏览器第一次访问我们的站点时，该页面引入了各式各样的静态资源，如果我们能做到持久化缓存的话，可以在 http 响应头加上 Cache-control 或 Expires 字段来设置缓存，浏览器可以将这些资源一一缓存到本地。
2. 用户在后续访问的时候，如果需要再次请求同样的静态资源，且静态资源没有过期，那么浏览器可以直接走本地缓存而不用再通过网络请求资源。

webpack 如何做持久化缓存

上面简单介绍完持久化缓存，下面这个才是重点，那么我们应该如何在 webpack 中进行持久化缓存的呢，我们需要做到以下两点：

1. 保证 hash 值的唯一性，即为每个打包后的资源生成一个独一无二的 hash 值，只要打包内容不一致，那么 hash 值就不一致。
2. 保证 hash 值的稳定性，我们需要做到修改某个模块的时候，只有受影响的打包后文件 hash 值改变，与该模块无关的打包文件 hash 值不变。

hash 文件名是实现持久化缓存的第一步，目前 webpack 有两种计算 hash 的方式([hash] 和 [chunkhash])

• hash 代表每次 webpack 在编译的过程中会生成唯一的 hash 值，在项目中任何一个文件改动后就会被重新创建，然后 webpack 计算新的 hash 值。
• chunkhash 是根据模块计算出来的 hash 值，所以某个文件的改动只会影响它本身的 hash 值，不会影响其他文件。

所以如果你只是单纯地将所有内容打包成同一个文件，那么 hash 就能够满足你了，如果你的项目涉及到拆包，分模块进行加载等等，那么你需要用 chunkhash，来保证每次更新之后只有相关的文件 hash 值发生改变。

所以我们在一份具有持久化缓存的 webpack 配置应该长这样：

module.exports = {
  entry: __dirname + '/src/index.js',
  output: {
    path: __dirname + '/dist',
    filename: '[name].[chunkhash:8].js',
  }
}

上面代码的含义就是：以 index.js 为入口，将所有的代码全部打包成一个文件取名为 index.xxxx.js 并放到 dist 目录下，现在我们可以在每次更新项目的时候做到生成新命名的文件了。

如果是应付简单的场景，这样做就够了，但是在大型多页面应用中，我们往往需要对页面进行性能优化：

1. 分离业务代码和第三方的代码：之所以将业务代码和第三方代码分离出来，是因为业务代码更新频率高，而第三方代码更新迭代速度慢，所以我们将第三方代码(库，框架)进行抽离，这样可以充分利用浏览器的缓存来加载第三方库。
2. 按需加载：比如在使用 React-Router 的时候，当用户需要访问到某个路由的时候再去加载对应的组件，那么用户没有必要在一开始的时候就将所有的路由组件下载到本地。
3. 在多页面应用中，我们往往可以将公共模块进行抽离，比如 header, footer 等等，这样页面在进行跳转的时候这些公共模块因为存在于缓存里，就可以直接进行加载了，而不是再进行网络请求了。

那么如何进行拆包，分模块进行加载，这就需要 webpack 内置插件：CommonsChunkPlugin，下面我将通过一个例子，来诠释 webpack 该如何进行配置。

本文的代码放在我的 Github 上，有兴趣的可以下载来看看：

git clone https://github.com/happylindz/blog.git
cd blog/code/multiple-page-webpack-demo
npm install

阅读下面的内容之前我强烈建议你看下我之前的文章：深入理解 webpack 文件打包机制，理解 webpack 文件的打包的机制有助于你更好地实现持久化缓存。

例子大概是这样描述的：它由两个页面组成 pageA 和 pageB

// src/pageA.js
import componentA from './common/componentA';

// 使用到 jquery 第三方库，需要抽离，避免业务打包文件过大
import $ from 'jquery';

// 加载 css 文件，一部分为公共样式，一部分为独有样式，需要抽离
import './css/common.css'
import './css/pageA.css';

console.log(componentA);
console.log($.trim('    do something   '));

// src/pageB.js
// 页面 A 和 B 都用到了公共模块 componentA，需要抽离，避免重复加载
import componentA from './common/componentA';
import componentB from './common/componentB';
import './css/common.css'
import './css/pageB.css';

console.log(componentA);
console.log(componentB);

// 用到异步加载模块 asyncComponent，需要抽离，加载首屏速度
document.getElementById('xxxxx').addEventListener('click', () => {
  import( /* webpackChunkName: "async" */
    './common/asyncComponent.js').then((async) => {
      async();
  })
})

// 公共模块基本长这样
export default "component X";

上面的页面内容基本简单涉及到了我们拆分模块的三种模式：拆分公共库，按需加载和拆分公共模块。那么接下来要来配置 webpack：

const path = require('path');
const webpack = require('webpack');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
module.exports = {
  entry: {
    pageA: [path.resolve(__dirname, './src/pageA.js')],
    pageB: path.resolve(__dirname, './src/pageB.js'),
  },
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'js/[name].[chunkhash:8].js',
    chunkFilename: 'js/[name].[chunkhash:8].js'
  },
  module: {
    rules: [
      {
        // 用正则去匹配要用该 loader 转换的 CSS 文件
        test: /\.css$/,
        use: ExtractTextPlugin.extract({
          fallback: "style-loader",
          use: ["css-loader"]
        })  
      }
    ]
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: 'common',
      minChunks: 2,
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: ({ resource }) => (
        resource && resource.indexOf('node_modules') >= 0 && resource.match(/\.js$/)
      )
    }),
    new ExtractTextPlugin({
      filename: `css/[name].[chunkhash:8].css`,
    }),
  ]
}

第一个 CommonsChunkPlugin 用于抽离公共模块，相当于是说 webpack 大佬，如果你看到某个模块被加载两次即以上，那么请你帮我移到 common chunk 里面，这里 minChunks 为 2，粒度拆解最细，你可以根据自己的实际情况，看选择是用多少次模块才将它们抽离。

第二个 CommonsChunkPlugin 用来提取第三方代码，将它们进行抽离，判断资源是否来自 node_modules，如果是，则说明是第三方模块，那就将它们抽离。相当于是告诉 webpack 大佬，如果你看见某些模块是来自 node_modules 目录的，并且名字是 .js 结尾的话，麻烦把他们都移到 vendor chunk 里去，如果 vendor chunk 不存在的话，就创建一个新的。

这样配置有什么好处，随着业务的增长，我们依赖的第三方库代码很可能会越来越多，如果我们专门配置一个入口来存放第三方代码，这时候我们的 webpack.config.js 就会变成：

// 不利于拓展
module.exports = {
  entry: {
    app: './src/main.js',
    vendor: [
      'vue',
      'axio',
      'vue-router',
      'vuex',
      // more
    ],
  },
}

第三个 ExtractTextPlugin 插件用于将 css 从打包好的 js 文件中抽离，生成独立的 css 文件，想象一下，当你只是修改了下样式，并没有修改页面的功能逻辑，你肯定不希望你的 js 文件 hash 值变化，你肯定是希望 css 和 js 能够相互分开，且互不影响。

运行 webpack 后可以看到打包之后的效果:

├── css
│   ├── common.2beb7387.css
│   ├── pageA.d178426d.css
│   └── pageB.33931188.css
└── js
    ├── async.03f28faf.js
    ├── common.2beb7387.js
    ├── pageA.d178426d.js
    ├── pageB.33931188.js
    └── vendor.22a1d956.js

可以看出 css 和 js 已经分离，并且我们对模块进行了拆分，保证了模块 chunk 的唯一性，当你每次更新代码的时候，会生成不一样的 hash 值。

唯一性有了，那么我们需要保证 hash 值的稳定性，试想下这样的场景，你肯定不希望你修改某部分的代码(模块，css)导致了文件的 hash 值全变了，那么显然是不明智的，那么我们去做到 hash 值变化最小化呢？

换句话说，我们就要找出 webpack 编译中会导致缓存失效的因素，想办法去解决或优化它？

影响 chunkhash 值变化主要由以下四个部分引起的：

1. 包含模块的源代码
2. webpack 用于启动运行的 runtime 代码
3. webpack 生成的模块 moduleid(包括包含模块 id 和被引用的依赖模块 id)
4. chunkID

这四部分只要有任意部分发生变化，生成的分块文件就不一样了，缓存也就会失效，下面就从四个部分一一介绍：

一、源代码变化：

显然不用多说，缓存必须要刷新，不然就有问题了

二、webpack 启动运行的 runtime 代码：

看过我之前的文章：深入理解 webpack 文件打包机制 就会知道，在 webpack 启动的时候需要执行一些启动代码。

(function(modules) { 
  window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
    // ...
  };
  function __webpack_require__(moduleId) {
    // ...
  }
  __webpack_require__.e = function requireEnsure(chunkId, callback) {
    // ...
    script.src = __webpack_require__.p + "" + chunkId + "." + ({"0":"pageA","1":"pageB","3":"vendor"}[chunkId]||chunkId) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkId] + ".js";
  };
})([]);

大致内容像上面这样，它们是 webpack 的一些启动代码，它们是一些函数，告诉浏览器如何加载 webpack 定义的模块。

其中有一行代码每次更新都会改变的，因为启动代码需要清楚地知道 chunkid 和 chunkhash 值得对应关系，这样在异步加载的时候才能正确地拼接出异步 js 文件的路径。

那么这部分代码最终放在哪个文件呢？因为我们刚才配置的时候最后生成的 common chunk 模块，那么这部分运行时代码会被直接内置在里面，这就导致了，我们每次更新我们业务代码(pageA, pageB, 模块)的时候， common chunkhash 会一直变化，但是这显然不符合我们的设想，因为我们只是要用 common chunk 用来存放公共模块(这里指的是 componentA)，那么我 componentA 都没去修改，凭啥 chunkhash 需要变了。

所以我们需要将这部分 runtime 代码抽离成单独文件。

module.exports = {
  // ...
  plugins: [
    // ...
    // 放到其他的 CommonsChunkPlugin 后面
    new webpack.optimize.CommonsChunkPlugin({
      name: 'runtime',
      minChunks: Infinity,
    }),
  ]
}

这相当于是告诉 webpack 帮我把运行时代码抽离，放到单独的文件中。

├── css
│   ├── common.4cc08e4d.css
│   ├── pageA.d178426d.css
│   └── pageB.33931188.css
└── js
    ├── async.03f28faf.js
    ├── common.4cc08e4d.js
    ├── pageA.d178426d.js
    ├── pageB.33931188.js
    ├── runtime.8c79fdcd.js
    └── vendor.cef44292.js

多生成了一个 runtime.xxxx.js，以后你在改动业务代码的时候，common chunk 的 hash 值就不会变了，取而代之的是 runtime chunk hash 值会变，既然这部分代码是动态的，可以通过 chunk-manifest-webpack-plugin 将他们 inline 到 html 中，减少一次网络请求。

三、webpack 生成的模块 moduleid

在 webpack2 中默认加载 OccurrenceOrderPlugin 这个插件，OccurrenceOrderPlugin 插件会按引入次数最多的模块进行排序，引入次数的模块的 moduleId 越小，但是这仍然是不稳定的，随着你代码量的增加，虽然代码引用次数的模块 moduleId 越小，越不容易变化，但是难免还是不确定的。

默认情况下，模块的 id 是这个模块在模块数组中的索引。OccurenceOrderPlugin 会将引用次数多的模块放在前面，在每次编译时模块的顺序都是一致的，如果你修改代码时新增或删除了一些模块，这将可能会影响到所有模块的 id。

最佳实践方案是通过 HashedModuleIdsPlugin 这个插件，这个插件会根据模块的相对路径生成一个长度只有四位的字符串作为模块的 id，既隐藏了模块的路径信息，又减少了模块 id 的长度。

这样一来，改变 moduleId 的方式就只有文件路径的改变了，只要你的文件路径值不变，生成四位的字符串就不变，hash 值也不变。增加或删除业务代码模块不会对 moduleid 产生任何影响。

module.exports = {
  plugins: [
    new webpack.HashedModuleIdsPlugin(),
    // 放在最前面
    // ...
  ]
}

四、chunkID

实际情况中分块的个数的顺序在多次编译之间大多都是固定的, 不太容易发生变化。

这里涉及的只是比较基础的模块拆分，还有一些其它情况没有考虑到，比如异步加载组件中包含公共模块，可以再次将公共模块进行抽离。形成异步公共 chunk 模块。有想深入学习的可以看这篇文章：Webpack 大法之 Code Splitting

webpack 做缓存的一些注意点

1. CSS 文件 hash 值失效的问题
2. 不建议线上发布使用 DllPlugin 插件

CSS 文件 hash 值失效的问题：

ExtractTextPlugin 有个比较严重的问题，那就是它生成文件名所用的[chunkhash]是直接取自于引用该 css 代码段的 js chunk ；换句话说，如果我只是修改 css 代码段，而不动 js 代码，那么最后生成出来的 css 文件名依然没有变化。

所以我们需要将 ExtractTextPlugin 中的 chunkhash 改为 contenthash，顾名思义，contenthash 代表的是文本文件内容的 hash 值，也就是只有 style 文件的 hash 值。这样编译出来的 js 和 css 文件就有独立的 hash 值了。

module.exports = {
  plugins: [
    // ...
    new ExtractTextPlugin({
      filename: `css/[name].[contenthash:8].css`,
    }),
  ]
}

如果你使用的是 webpack2，webpack3，那么恭喜你，这样就足够了，js 文件和 css 文件修改都不会影响到相互的 hash 值。那如果你使用的是 webpack1，那么就会出现问题。

具体来讲就是 webpack1 和 webpack 在计算 chunkhash 值得不同：

webpack1 在涉及的时候并没有考虑像 ExtractTextPlugin 会将模块内容抽离的问题，所以它在计算 chunkhash 的时候是通过打包之前模块内容去计算的，也就是说在计算的时候 css 内容也包含在内，之后才将 css 内容抽离成单独的文件，

那么就会出现：如果只修改了 css 文件，未修改引用的 js 文件，那么编译输出的 js 文件的 hash 值也会改变。

对此，webpack2 做了改进，它是基于打包后文件内容来计算 hash 值的，所以是在 ExtractTextPlugin 抽离 css 代码之后，所以就不存在上述这样的问题。如果不幸的你还在使用 webpack1，那么推荐你使用 md5-hash-webpack-plugin 插件来改变 webpack 计算 hash 的策略。

不建议线上发布使用 DllPlugin 插件

为什么这么说呢？因为最近有朋友来问我，他们 leader 不让在线上用 DllPlugin 插件，来问我为什么？

DllPlugin 本身有几个缺点：

1. 首先你需要额外多配置一份 webpack 配置，增加工作量。
2. 其中一个页面用到了一个体积很大的第三方依赖库而其它页面根本不需要用到，但若直接将它打包在 dll.js 里很不值得，每次页面打开都要去加载这段无用的代码，无法使用到 webpack2 的 Code Splitting 功能。
3. 第一次打开的时候需要下载 dll 文件，因为你把很多库全部打在一起了，导致 dll 文件很大，首次进入页面加载速度很慢。

虽然你可以打包成 dll 文件，然后让浏览器去读取缓存，这样下次就不用再去请求，比如你用 lodash 其中一个函数，而你用dll会将整个 lodash 文件打进去，这就会导致你加载无用代码过多，不利于首屏渲染时间。

我认为的正确的姿势是：

1. 像 React、Vue 这样整体性偏强的库，可以生成 vendor 第三方库来去做缓存，因为你一般技术体系是固定的，一个站点里面基本上都会用到统一技术体系，所以生成 vendor 库用于缓存。
2. 像 antd、lodash 这种功能性组件库，可以通过 tree shaking 来进行消除，只保留有用的代码，千万不要直接打到 vendor 第三方库里，不然你将大量执行无用的代码。

结语

好了，感觉我又扯了很多，最近在看 webpack 确实收获不少，希望大家能从文章中也能有所收获。另外推荐再次推荐一下我之前写的文章，能够更好地帮你理解文件缓存机制：深入理解 webpack 文件打包机制

参考链接：

• Webpack中hash与chunkhash的区别，以及js与css的hash指纹解耦方案
• webpack多页应用架构系列（十六）：善用浏览器缓存，该去则去，该留则留
• 用 webpack 实现持久化缓存
• Webpack 真正的持久缓存实现

原文地址

常见前端面试题总结 (一)

一、W3C 标准盒模型和 IE 盒模型区别：

• W3C 标准盒模型：

盒子的高宽是由盒子的内容区仅由 width, height 决定的，不包含边框，内外边距。

• IE 盒模型：

在 IE 盒模型中，盒子宽高不仅包含了元素的宽高，而且包含了元素的边框以及内边距。

所以在同样的设置下，IE 下的元素会看起来相对于标准盒子来的小，如果你想要标准盒子变为像 IE 盒模型，可以对元素样式进行设置：

.item {
  box-sizing: border-box;      //IE 盒模型效果
  box-sizing: content-box;     //默认值，标准盒模型效果
}

二、querySelectorAll 与 getElementsBy 系列的区别：

根据该问题下的答案 querySelectorAll 方法相比 getElementsBy 系列方法有什么区别？，我简单地总结一下：

1. querySelectorAll 属于 W3C 中 Selectors API 规范， 而 getElementsBy 系列则属于 W3C DOM 规范。
2. querySelectorAll 方法接受参数是 CSS 选择符，当传入的是不符合 CSS 选择符规范时会抛出异常，而 getElementsBy 系列则接受的参数是单一的 className，tagName 等等。
3. 从返回值角度来看，querySelectorAll 返回的是不变的结点列表，而 getElementsBy 系列返回的是动态的结点列表。

// Demo 1
var ul = document.querySelectorAll('ul')[0],
  lis = ul.querySelectorAll("li");
for(var i = 0; i < lis.length ; i++){
  ul.appendChild(document.createElement("li"));
}

// Demo 2
var ul = document.getElementsByTagName('ul')[0], 
  lis = ul.getElementsByTagName("li"); 
for(var i = 0; i < lis.length ; i++){
  ul.appendChild(document.createElement("li")); 
}

因为 Demo 2 中的 lis 是一个动态的结点列表， 每一次调用 lis 都会重新对文档进行查询，导致无限循环的问题。

而 Demo 1 中的 lis 是一个静态的结点列表，是一个 li 集合的快照，对文档的任何操作都不会对其产生影响。

• 普遍认为：getElementsBy 系列性能比 querySelectorAll 好
• querySelectorAll 返回值为一个 NodeList，而 getElementsBy 系列返回值为一个 HTMLCollection

三、NodeList 与 HTMLCollection 区别：

1. HTMLCollection 是元素集合而 NodeList 是节点集合(即可以包含元素，文本节点，以及注释等等)。
2. node.childNodes，querySelectorAll(虽然是静态的) 返回的是 NodeList，而 node.children 和 node.getElementsByXXX 返回 HTMLCollection。

四、动态作用域和静态作用域的区别：

• 静态作用域又称之为词法作用域：即词法作用域的函数中遇到既不是形参也不是函数内部定义的局部变量的变量时，它会根据函数定义的环境中查询。

var foo = 1;

function static() {
  console.log(foo);
}

(function() {
  var foo = 2;
   static();
}());

JS 的变量是遵循静态作用域的，在上述代码中会打印出 1 而非 2，因为 static 函数在作用域创建的时候，记录的 foo 是 1，如果是动态作用域的话，那么它应该打印出 2。

静态作用域是产生闭包的关键，即它在代码写好之后就被静态决定它的作用域了。

• 动态域的函数中遇到既不是形参也不是函数内部定义的局部变量的变量时，到函数调用的环境去查询

在 JS 中，关于 this 的执行是基于动态域查询的，下面这段代码打印出 1，如果按静态作用域的话应该会打印出 2

var foo = 1;

var obj = {
  foo: 2,
  bar: function() {
    console.log(this.foo);
  }
};

var bar = obj.bar;
bar();

五、数据类型检测方式：

• typeof：使用 typeof 检测数据类型，返回值有：number, string, boolean, undefined, function, object

常见的返回值就不说了，需要注意的是下面的几种情况：

console.log(typeof NaN);          //number
console.log(typeof typeof typeof function(){})      //string
var str = 'abc';     
console.log(typeof str++);         //number
console.log(typeof ('abc' + 1));   //string


console.log(typeof null);          //object
console.log(typeof /\d/g);         //object
console.log(typeof []);            //object
console.log(typeof new Date());    //object
console.log(typeof Date());        //string
console.log(typeof Date);          //function

• instanceof：只要在当前实例的原型链上，用 instanceof 检测出来的结果都是 true，所以在类的原型继承中，最后检测出来的结果未必是正确的。

使用 instanceof 判断基本类型：

var str1 = 'abc';
var str2 = new String('abc');

console.log(str1 instanceof String);                //false
console.log(str2 instanceof String);                //true

console.log(false instanceof Boolean);              //false
console.log(new Boolean(false) instanceof Boolean)   //true

判断基本类型还是用 typeof 吧，instanceof 不适合。

判断实例：

function Foo(){} 
var foo = new Foo(); 
console.log(foo instanceof Foo)     //true

判断继承关系：

function Parent() {}
function Child() {}

Child.prototype = new Parent();
Child.prototype.constructor = Child;

var child = new Child();
console.log(child instanceof Child);             //true
console.log(child instanceof Parent);            //true
console.log(child instanceof Object);            //true
console.log(Child instanceof Function);          //true
console.log(Function instanceof Object);         //true 
console.log(Child instanceof Child);             //false

如果你对上面输出的结果感到困惑，那建议你看下这面这篇文章：深入理解javascript原型和闭包（5）--instanceof - 王福朋 - 博客园

• constructor：检测数据类型

console.log((1).constructor === Number);        //true
console.log("a".constructor === String);        //true
console.log([].constructor  === Array);         //true
console.log({}.constructor  === Object);        //true

检测功能还是挺全面的，不过也有它的局限性：如果我们把类的原型进行重写了，在重写的过程中，很有可能把之前 constructor 给覆盖掉，这样检测出的结果就不准确了。

function Fn() {}
Fn.prototype = new Array();
var f = new Fn();
console.log(f.constructor === Array);                // true

并且 constructor 检测不出 null，undefined 的类型，所以判断类型用 constructor 也不太好用

• Object.prototype.toStrong.call

Object.prototype.toStrong.call() 是检测数据类型最准确最常用的方式，

function toString(data) {
  return Object.prototype.toString.call(data).slice(8, -1);
}

console.log(toString('abc') === 'String'); 
console.log(toString(1) === 'Number');
console.log(toString(false) === 'Boolean');
console.log(toString(null) === 'Null');
console.log(toString(undefined) === 'Undefined');
console.log(toString([]) === 'Array');
console.log(toString({}) === 'Object');
console.log(toString(function(){}) === 'Function')

六、函数和对象的关系：

首先函数是一种对象：

var fn = function() {}
console.log(fn instanceof Object);  //true

对，函数是一种对象，但是函数却不像数组那样 ---- 你可以说数组是对象的一种，因为数组就像对象的一个子集一样，但是函数与对象之间，却不仅仅是包含和被包含的关系。

对象可以由函数创建：

function Fn() {
  this.name = "Lindz";
  this.year = 1995;
}
var fn1 = new Fn();      // {name: "Lindz", year: 1995}

上面的例子很简单，它说明了对象可以通过函数重建，但是其实对象都是通过函数创建的，有人可能会反驳，他认为：

var obj = { a: 10, b: 20 };
var arr = [5, true, "aa"];

但是这些都是编程中的语法糖，实际上编译器帮我们做了下面这些事：

var obj = new Object();
obj.a = 10;
obj.b = 20;

var arr = new Array();
arr[0] = 5;
arr[1] = true;
arr[2] = "aa";

console.log(typeof (Object));  // function
console.log(typeof (Array));  // function

七、JS 如何判断函数是 new 调用还是普通调用

第一种方式：通过 instanceof 判断

function Person() {
  if(this instanceof arguments.callee) {
    console.log('new 调用');
  }else {
    console.log('普通调用');
  }
}

let p1 = new Person();             // new 调用
let p2 = Person();		           // 函数调用 

第二种方式：通过 constructor

function Person() {
  if(this.constructor === arguments.callee) {
    console.log('new 调用');
  }else {
    console.log('普通调用');
  }
}

let p1 = new Person();             // new 调用
let p2 = Person();		   			// 函数调用 

原文地址

前言

在 React 的世界中，有容器组件和 UI 组件之分，在 React Hooks 出现之前，UI 组件我们可以使用函数，无状态组件来展示 UI，而对于容器组件，函数组件就显得无能为力，我们依赖于类组件来获取数据，处理数据，并向下传递参数给 UI 组件进行渲染。在我看来，使用 React Hooks 相比于从前的类组件有以下几点好处：

1. 代码可读性更强，原本同一块功能的代码逻辑被拆分在了不同的生命周期函数中，容易使开发者不利于维护和迭代，通过 React Hooks 可以将功能代码聚合，方便阅读维护
2. 组件树层级变浅，在原本的代码中，我们经常使用 HOC/render props 等方式来复用组件的状态，增强功能等，无疑增加了组件树层数及渲染，而在 React Hooks 中，这些功能都可以通过强大的自定义的 Hooks 来实现

React 在 v16.8 的版本中推出了 React Hooks 新特性，虽然社区还没有最佳实践如何基于 React Hooks 来打造复杂应用(至少我还没有)，凭借着阅读社区中大量的关于这方面的文章，下面我将通过十个案例来帮助你认识理解并可以熟练运用 React Hooks 大部分特性。

useState 保存组件状态

在类组件中，我们使用 this.state 来保存组件状态，并对其修改触发组件重新渲染。比如下面这个简单的计数器组件，很好诠释了类组件如何运行：在线 Demo

import React from "react";
class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      count: 0,
      name: "alife"
    };
  }
  render() {
    const { count } = this.state;
    return (
      <div>
        Count: {count}
        <button onClick={() => this.setState({ count: count + 1 })}>+</button>
        <button onClick={() => this.setState({ count: count - 1 })}>-</button>
      </div>
    );
  }
}

一个简单的计数器组件就完成了，而在函数组件中，由于没有 this 这个黑魔法，React 通过 useState 来帮我们保存组件的状态。在线 Demo

import React, { useState } from "react";
function App() {
  const [obj, setObject] = useState({
    count: 0,
    name: "alife"
  });
  return (
    <div className="App">
      Count: {obj.count}
      <button onClick={() => setObject({ ...obj, count: obj.count + 1 })}>+</button>
      <button onClick={() => setObject({ ...obj, count: obj.count - 1 })}>-</button>
    </div>
  );
}

通过传入 useState 参数后返回一个带有默认状态和改变状态函数的数组。通过传入新状态给函数来改变原本的状态值。值得注意的是 useState 不帮助你处理状态，相较于 setState 非覆盖式更新状态，useState 覆盖式更新状态，需要开发者自己处理逻辑。(代码如上)

似乎有个 useState 后，函数组件也可以拥有自己的状态了，但仅仅是这样完全不够。

useEffect 处理副作用

函数组件能保存状态，但是对于异步请求，副作用的操作还是无能为力，所以 React 提供了 useEffect 来帮助开发者处理函数组件的副作用，在介绍新 API 之前，我们先来看看类组件是怎么做的：在线 Demo

import React, { Component } from "react";
class App extends Component {
  state = {
    count: 1
  };
  componentDidMount() {
    const { count } = this.state;
    document.title = "componentDidMount" + count;
    this.timer = setInterval(() => {
      this.setState(({ count }) => ({
        count: count + 1
      }));
    }, 1000);
  }
  componentDidUpdate() {
    const { count } = this.state;
    document.title = "componentDidMount" + count;
  }
  componentWillUnmount() {
    document.title = "componentWillUnmount";
    clearInterval(this.timer);
  }
  render() {
    const { count } = this.state;
    return (
      <div>
        Count:{count}
        <button onClick={() => clearInterval(this.timer)}>clear</button>
      </div>
    );
  }
}

在例子中，组件每隔一秒更新组件状态，并且每次触发更新都会触发 document.title 的更新(副作用)，而在组件卸载时修改 document.title（类似于清除）

从例子中可以看到，一些重复的功能开发者需要在 componentDidMount 和 componentDidUpdate 重复编写，而如果使用 useEffect 则完全不一样。在线 Demo

import React, { useState, useEffect } from "react";
let timer = null;
function App() {
  const [count, setCount] = useState(0);
  useEffect(() => {
    document.title = "componentDidMount" + count;
  },[count]);
  
  useEffect(() => {
    timer = setInterval(() => {
      setCount(prevCount => prevCount + 1);
    }, 1000);
    return () => {
      document.title = "componentWillUnmount";
      clearInterval(timer);
    };
  }, []);
  return (
    <div>
      Count: {count}
      <button onClick={() => clearInterval(timer)}>clear</button>
    </div>
  );
}

我们使用 useEffect 重写了上面的例子，useEffect 第一个参数传递函数，可以用来做一些副作用比如异步请求，修改外部参数等行为，而第二个参数是个数组，如果数组中的值才会触发 useEffect 第一个参数中的函数。返回值(如果有)则在组件销毁或者调用函数前调用。

1. 比如第一个 useEffect 中，理解起来就是一旦 count 值发生改变，则修改 documen.title 值
2. 而第二个 useEffect 中数组没有传值，代表不监听任何参数变化，即只有在组件初始化或销毁的时候才会触发，用来代替 componentDidMount 和 componentWillUnmount

基于这个强大 Hooks，我们可以模拟封装出其他生命周期函数，比如 componentDidUpdate 代码十分简单

function useUpdate(fn) {
    // useRef 创建一个引用
    const mounting = useRef(true);
    useEffect(() => {
      if (mounting.current) {
        mounting.current = false;
      } else {
        fn();
      }
    });
}

现在我们有了 useState 管理状态，useEffect 处理副作用，异步逻辑，学会这两招足以应对大部分类组件的使用场景。

useContext 减少组件层级

上面介绍了 useState、useEffect 这两个最基本的 API，接下来介绍的 useContext 是 React 帮你封装好的，用来处理多层级传递数据的方式，在以前组件树种，跨层级祖先组件想要给孙子组件传递数据的时候，除了一层层 props 往下透传之外，我们还可以使用 React Context API 来帮我们做这件事，举个简单的例子：在线 Demo

const { Provider, Consumer } = React.createContext(null);
function Bar() {
  return <Consumer>{color => <div>{color}</div>}</Consumer>;
}
function Foo() {
  return <Bar />;
}
function App() {
  return (
    <Provider value={"grey"}>
      <Foo />
    </Provider>
  );
}

通过 React createContext 的语法，在 APP 组件中可以跨过 Foo 组件给 Bar 传递数据。而在 React Hooks 中，我们可以使用 useContext 进行改造。在线 Demo

const colorContext = React.createContext("gray");
function Bar() {
  const color = useContext(colorContext);
  return <div>{color}</div>;
}
function Foo() {
  return <Bar />;
}
function App() {
  return (
    <colorContext.Provider value={"red"}>
      <Foo />
    </colorContext.Provider>
  );
}

传递给 useContext 的是 context 而不是 consumer，返回值即是想要透传的数据了。用法很简单，使用 useContext 可以解决 Consumer 多状态嵌套的问题。参考例子

function HeaderBar() {
  return (
    <CurrentUser.Consumer>
      {user =>
        <Notifications.Consumer>
          {notifications =>
            <header>
              Welcome back, {user.name}!
              You have {notifications.length} notifications.
            </header>
          }
      }
    </CurrentUser.Consumer>
  );
}

而使用 useContext 则变得十分简洁，可读性更强且不会增加组件树深度。

function HeaderBar() {
  const user = useContext(CurrentUser);
  const notifications = useContext(Notifications);
  return (
    <header>
      Welcome back, {user.name}!
      You have {notifications.length} notifications.
    </header>
  );
}

useReducer

useReducer 这个 Hooks 在使用上几乎跟 Redux/React-Redux 一模一样，唯一缺少的就是无法使用 redux 提供的中间件。我们将上述的计时器组件改写为 useReducer，在线 Demo

import React, { useReducer } from "react";
const initialState = {
  count: 0
};
function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return { count: state.count + action.payload };
    case "decrement":
      return { count: state.count - action.payload };
    default:
      throw new Error();
  }
}
function App() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({ type: "increment", payload: 5 })}>
        +
      </button>
      <button onClick={() => dispatch({ type: "decrement", payload: 5 })}>
        -
      </button>
    </>
  );
}

用法跟 Redux 基本上是一致的，用法也很简单，算是提供一个 mini 的 Redux 版本。

useCallback 记忆函数

在类组件中，我们经常犯下面这样的错误：

class App {
    render() {
        return <div>
            <SomeComponent style={{ fontSize: 14 }} doSomething={ () => { console.log('do something'); }}  />
        </div>;
    }
}

这样写有什么坏处呢？一旦 App 组件的 props 或者状态改变了就会触发重渲染，即使跟 SomeComponent 组件不相关，由于每次 render 都会产生新的 style 和 doSomething，所以会导致 SomeComponent 重新渲染，倘若 SomeComponent 是一个大型的组件树，这样的 Virtual Dom 的比较显然是很浪费的，解决的办法也很简单，将参数抽离成变量。

const fontSizeStyle = { fontSize: 14 };
class App {
    doSomething = () => {
        console.log('do something');
    }
    render() {
        return <div>
            <SomeComponent style={fontSizeStyle} doSomething={ this.doSomething }  />
        </div>;
    }
}

在类组件中，我们还可以通过 this 这个对象来存储函数，而在函数组件中没办法进行挂载了。所以函数组件在每次渲染的时候如果有传递函数的话都会重渲染子组件。

function App() {
  const handleClick = () => {
    console.log('Click happened');
  }
  return <SomeComponent onClick={handleClick}>Click Me</SomeComponent>;
}

而有了 useCallback 就不一样了，你可以通过 useCallback 获得一个记忆后的函数。

function App() {
  const memoizedHandleClick = useCallback(() => {
    console.log('Click happened')
  }, []); // 空数组代表无论什么情况下该函数都不会发生改变
  return <SomeComponent onClick={memoizedHandleClick}>Click Me</SomeComponent>;
}

老规矩，第二个参数传入一个数组，数组中的每一项一旦值或者引用发生改变，useCallback 就会重新返回一个新的记忆函数提供给后面进行渲染。

这样只要子组件继承了 PureComponent 或者使用 React.memo 就可以有效避免不必要的 VDOM 渲染。

useMemo 记忆组件

useCallback 的功能完全可以由 useMemo 所取代，如果你想通过使用 useMemo 返回一个记忆函数也是完全可以的。

useCallback(fn, inputs) is equivalent to useMemo(() => fn, inputs).

所以前面使用 useCallback 的例子可以使用 useMemo 进行改写：

function App() {
  const memoizedHandleClick = useMemo(() => () => {
    console.log('Click happened')
  }, []); // 空数组代表无论什么情况下该函数都不会发生改变
  return <SomeComponent onClick={memoizedHandleClick}>Click Me</SomeComponent>;
}

唯一的区别是：**useCallback 不会执行第一个参数函数，而是将它返回给你，而 useMemo 会执行第一个函数并且将函数执行结果返回给你。**所以在前面的例子中，可以返回 handleClick 来达到存储函数的目的。

所以 useCallback 常用记忆事件函数，生成记忆后的事件函数并传递给子组件使用。而 useMemo 更适合经过函数计算得到一个确定的值，比如记忆组件。

function Parent({ a, b }) {
  // Only re-rendered if `a` changes:
  const child1 = useMemo(() => <Child1 a={a} />, [a]);
  // Only re-rendered if `b` changes:
  const child2 = useMemo(() => <Child2 b={b} />, [b]);
  return (
    <>
      {child1}
      {child2}
    </>
  )
}

当 a/b 改变时，child1/child2 才会重新渲染。从例子可以看出来，只有在第二个参数数组的值发生变化时，才会触发子组件的更新。

useRef 保存引用值

useRef 跟 createRef 类似，都可以用来生成对 DOM 对象的引用，看个简单的例子：在线 Demo

import React, { useState, useRef } from "react";
function App() {
  let [name, setName] = useState("Nate");
  let nameRef = useRef();
  const submitButton = () => {
    setName(nameRef.current.value);
  };
  return (
    <div className="App">
      <p>{name}</p>

      <div>
        <input ref={nameRef} type="text" />
        <button type="button" onClick={submitButton}>
          Submit
        </button>
      </div>
    </div>
  );
}

useRef 返回的值传递给组件或者 DOM 的 ref 属性，就可以通过 ref.current 值访问组件或真实的 DOM 节点，从而可以对 DOM 进行一些操作，比如监听事件等等。

当然 useRef 远比你想象中的功能更加强大，useRef 的功能有点像类属性，或者说您想要在组件中记录一些值，并且这些值在稍后可以更改。

利用 useRef 就可以绕过 Capture Value 的特性。可以认为 ref 在所有 Render 过程中保持着唯一引用，因此所有对 ref 的赋值或取值，拿到的都只有一个最终状态，而不会在每个 Render 间存在隔离。参考例子：精读《Function VS Class 组件》

React Hooks 中存在 Capture Value 的特性：在线 Demo

function MessageThread() {
  const [message, setMessage] = useState("");

  const showMessage = () => {
    alert("You said: " + message);
  };

  const handleSendClick = () => {
    setTimeout(showMessage, 3000);
  };

  const handleMessageChange = e => {
    setMessage(e.target.value);
  };

  return (
    <>
      <input value={message} onChange={handleMessageChange} />
      <button onClick={handleSendClick}>Send</button>
    </>
  );
}

在点击 Send 按钮后，再次修改输入框的值，3 秒后的输出依然是点击前输入框的值。这就是所谓的 capture value 的特性。而在类组件中 3 秒后输出的就是修改后的值，因为这时候 message 是挂载在 this 变量上，它保留的是一个引用值，对 this 属性的访问都会获取到最新的值。讲到这里你应该就明白了，useRef 创建一个引用，就可以有效规避 React Hooks 中 Capture Value 特性。

function MessageThread() {
  const latestMessage = useRef("");

  const showMessage = () => {
    alert("You said: " + latestMessage.current);
  };

  const handleSendClick = () => {
    setTimeout(showMessage, 3000);
  };

  const handleMessageChange = e => {
    latestMessage.current = e.target.value;
  };
}

只要将赋值与取值的对象变成 useRef，而不是 useState，就可以躲过 capture value 特性，在 3 秒后得到最新的值。

useImperativeHandle 透传 Ref

通过 useImperativeHandle 用于让父组件获取子组件内的索引 在线 Demo

import React, { useRef, useEffect, useImperativeHandle, forwardRef } from "react";
function ChildInputComponent(props, ref) {
  const inputRef = useRef(null);
  useImperativeHandle(ref, () => inputRef.current);
  return <input type="text" name="child input" ref={inputRef} />;
}
const ChildInput = forwardRef(ChildInputComponent);
function App() {
  const inputRef = useRef(null);
  useEffect(() => {
    inputRef.current.focus();
  }, []);
  return (
    <div>
      <ChildInput ref={inputRef} />
    </div>
  );
}

通过这种方式，App 组件可以获得子组件的 input 的 DOM 节点。

useLayoutEffect 同步执行副作用

大部分情况下，使用 useEffect 就可以帮我们处理组件的副作用，但是如果想要同步调用一些副作用，比如对 DOM 的操作，就需要使用 useLayoutEffect，useLayoutEffect 中的副作用会在 DOM 更新之后同步执行。在线 Demo

function App() {
  const [width, setWidth] = useState(0);
  useLayoutEffect(() => {
    const title = document.querySelector("#title");
    const titleWidth = title.getBoundingClientRect().width;
    console.log("useLayoutEffect");
    if (width !== titleWidth) {
      setWidth(titleWidth);
    }
  });
  useEffect(() => {
    console.log("useEffect");
  });
  return (
    <div>
      <h1 id="title">hello</h1>
      <h2>{width}</h2>
    </div>
  );
}

在上面的例子中，useLayoutEffect 会在 render，DOM 更新之后同步触发函数，会优于 useEffect 异步触发函数。

React Hooks 不足

尽管我们通过上面的例子看到 React Hooks 的强大之处，似乎类组件完全都可以使用 React Hooks 重写。但是当下 v16.8 的版本中，还无法实现 getSnapshotBeforeUpdate 和 componentDidCatch 这两个在类组件中的生命周期函数。官方也计划在不久的将来在 React Hooks 进行实现。

原文地址

Redux 异步流最佳实践

阅读本文之前，希望你对 Redux 有个清晰的认知，如果不熟悉的话可以看这篇文章：揭秘 React 状态管理

如果觉得本文有帮助，可以点 star 鼓励下，本文所有代码都可以从 github 仓库下载，读者可以按照下述打开:

git clone https://github.com/happylindz/blog.git
cd blog/code/asynchronousAction/
cd xxx/
yarn
yarn start

我们知道，在 Redux 的世界中，Redux action 返回一个 JS 对象，被 Reducer 接收处理后返回新的 State，这一切看似十分美好。整个过程可以看作是：

view -> actionCreator -> action -> reducer -> newState ->(map) container component

但是真实业务开发我们需要处理异步请求，比如：请求后台数据，延迟执行某个效果，setTimout, setInterval 等等，所以当 Redux 遇到异步操作的时候，又该如何处理呢？

首先我们围绕一个简单的例子展开，然后通过各种方式将它实现出来，基本效果如下：

不使用中间件处理异步

这里我使用的是 CNode 官网的 API，获取首页的文章标题，并将他们全部展示出来，并且右边有个 X 按钮，点击 X 按钮可以将该标题删除。异步请求我们使用封装好的 axios 库，你可以这样发起异步请求：

const response = await axios.get('/api/v1/topics')

然后在你的 package.json 文件中加上代理字段

{
  "proxy": "https://cnodejs.org",
  //...
}

这样当你访问 localhost:3000/api/v1/topics Node 后台会自动帮你转发请求到 CNode，然后将获取到的结果返回给你，这个过程对你来说是透明的，这样能有效避免跨域的问题。

cd asynchronous_without_redux_middleware/
yarn 
yarn start

老规矩，我们先来看看项目结构：

├── actionCreator
│   └── index.js
├── actionTypes
│   └── index.js
├── constants
│   └── index.js
├── index.js
├── reducers
│   └── index.js
├── store
│   └── index.js
└── views
    ├── newsItem.css
    ├── newsItem.js
    └── newsList.js

我们在异步请求时候一共有三种 actionTypes，分别为 FETCH_START, FETCH_SUCCESS, FETCH_FAILURE，这样对应着视图就有四种状态 (constants)：INITIAL_STATE, LOADING_STATE, SUCCESS_STATE, FAILURE_STATE。

actionCreator 对 actionTypes 多一层封装，返回的都还是同步 action，主要的逻辑由视图组件来完成。

// views/newsList.js
const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        fetchNewsTitle: async() => {
            dispatch(actionCreator.fetchStart())
            try {
                const response = await axios.get('/api/v1/topics')
                if(response.status === 200) {
                    dispatch(actionCreator.fetchSuccess(response.data))
                }else {
                    throw new Error('fetch failure')
                }
            } catch(e) {
                dispatch(actionCreator.fetchFailure())
            }
        }
    }
}

我们可以看出，在发起异步请求之前，我们先发起 FETCH_START action，然后开始发起异步请求，当请求成功之后发起 FETCH_SUCCESS action 并传递数据，当请求失败时发起 FETCH_FAILURE action。

在上面的例子，我们没有破坏同步 action 这个特性，而是将异步请求封装在了具体的业务代码中，这种直观的写法存在着一些问题：

1. 每当我们发起异步请求后，我们总是需要写这样重复的代码，手动地处理获取的数据，其实我们更希望异步返回后能够自我消化处理后面的步骤，对于业务层来说，我只需要给出一个信号，比如：FETCH_START action，后续内容就不要再关心了，应用能帮我处理。
2. 当我们在不同的组件里有同样的异步代码，我们最好将它进行抽象，提取到一个公共的地方进行维护。
3. 没有做竞态处理：点击按钮可以获取 CNode 标题并呈现，因为异步请求返回的时间具有不确定性，多次点击就可能出现后点击的请求先返回先渲染，而前面点击的请求后返回覆盖了最新的请求结果。

通过分析，我们得出需要提取这些逻辑到一个公共的部分，然后简单调用，后续操作自动完成，就像：

const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        fetchNewsTitle:() => {
            xxx.fetchStart() 
        }
    }
}

一种思路是将这些异步调用独立抽出到一个公共通用异步操作的文件夹，每个需要调用异步操作的组件就到这个目录下获取需要的函数，但是这样就存在一个问题，因为需要发起 action 请求，那么就需要 dispatch 字段，这就意味着每次调用时候必须显式地传入 dispatch 变量，即:

const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        fetchNewsTitle:() => {
            xxx.fetchStart(dispatch) 
        }
    }
}

这样写不够优雅，不过也不失为一种解决方案，可以进行尝试，这里就不展开了。

异步 Action

此前介绍的都是同步的 action 请求，接下来介绍一下异步的 action，我们希望在异步请求的时候，action 能够这样处理：

view -> asyncAction -> wait -> action -> reducer -> newState -> container component

这里 action 不再是同步的，而是具有异步功能，当然因为依赖于异步 IO，也会产生副作用。这里就会存在一个问题，我们需要发起两次 action 请求，这好像我们又得将 dispatch 对象传入函数中，显得不够优雅。同步和异步的调用方式截然不同：

• 同步情况：store.dispatch(actionCreator())
• 异步情况: asyncAction(store.dispatch)

好在我们有 Redux 中间件机制能够帮助我们处理异步 action，让 action 不再仅仅处理同步的请求。

Redux-thunk：简洁直接

Redux 本身只能处理同步的 action，但可以通过中间件来拦截处理其它类型的 action，比如函数(thunk)，再用回调触发普通 action，从而实现异步处理，在这点上所有 Redux 的异步方案都是类似的。

首先我们通过 redux-thunk 来改写我们之前的例子

cd asynchronous_with_redux_thunk/
yarn 
yarn start

首先需要在 store 里注入中间件 redux-thunk。

import { createStore, applyMiddleware } from 'redux'
import reducer from '../reducers'
import thunk from 'redux-thunk'

// ...

export default createStore(reducer, initValue, applyMiddleware(thunk))

这样 redux-thunk 中间件就能够在 action 传递给 reducer 前进行处理。

我们改写我们 actionCreator 对象，再需要那么多同步的 action，只需一个方法即可搞定。

// actionCreator/index.js
import * as actionTypes from '../actionTypes'
import axios from 'axios'

export default {
    fetchNewsTitle: () => {
        return async (dispatch, getState) => {
            dispatch({
                type: actionTypes.FETCH_START,
            })
            try {
                const response = await axios.get('https://cnodejs.org/api/v1/topics')
                if(response.status === 200) {
                    dispatch({
                        type: actionTypes.FETCH_SUCCESS,
                        news: response.data.data.map(news => news.title),
                    })
                }else {
                    throw new Error('fetch failure')
                }
            } catch(e) {
                dispatch({
                    type: actionTypes.FETCH_FAILURE
                })
            }
        }
    },
    // ...
}

这次 fecthNewsTitle 不再简单返回一个 JS 对象，而是返回一个函数，在函数内可以获得当前 state 以及 dispatch，然后之前的异步操作全部封装在这里。是 redux-thunk 中间让 dispatch 不仅能够处理 JS 对象，也能够处理一个函数。

之后我们在业务代码只需调用：

// views/App.js
const mapDispatchToProps = (dispatch, ownProps) => {
    return {
        fetchNewsTitle: () => {
            dispatch(actionCreator.fetchNewsTitle())
        }
    }
}

自此当以后 redux 需要处理异步操作的时候，只需将 actionCreator 设为函数，然后在函数里编写你的异步逻辑。

redux-thunk 是一个通用的解决方案，其核心**是让 action 可以变为一个 thunk ，这样的话:

• 同步情况： dispatch(action)
• 异步情况： dispatch(thunk)

redux-thunk 看似做了很多工作，实现起来却是相当简单：

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

乍一看有有很多层箭头函数链式调用，这其实跟中间件的机制有关，我们只需要关心，当 action 传递到中间件的时候，它会判断该 action 是不是一个函数，如果函数，则拦截当前的 action，因为在当前的闭包中存在 dispatch 和 getState 变量，将两个变量传递到函数中并执行，这就是我们在 actionCreator 返回函数时候能够用到 dispatch 和 getState 的关键原因。redux-thunk 看到传递的 action 是个函数的时候就将其拦截并且执行，这时候这个 action 的返回值已经不再关心，因为它根本没有被继续传递下去，不是函数的话它就放过这个 action，让下个中间件去处理它(next(action))

所以我们前面的例子可以理解为：

view -> 函数 action -> redux-thunk 拦截 -> 执行函数并丢弃函数 action -> 一系列 action 操作 -> reducer -> newState -> container component

不难理解我们将原本放在公共目录下的异步操作封装在了一个 action，通过中间件的机制让 action 内部能够拿到 dispatch 值，从而在 action 中能够产生更多的同步 action 对象。

redux-thunk 这种方案对于小型的应用来说足够日常使用，然而对于大型应用来说，你可能会发现一些不方便的地方，对于组合多 action，取消 action，竞态判断的处理就显然有点儿力不从心，这些东西我们也会在后面进行谈到。

redux-thunk **很棒，但是其实代码是有一定的相似，比如其实整个代码都是针对请求、成功、失败三部分来处理的，这让我们自然联想到 Promise，同样也是分为 pending、fulfilled、rejected 三种状态。

Redux-promise：瘦身过度

Promise 代表一种承诺，本用来解决异步回调地狱问题，首先我们先来看看 redux-promise 中间件的源码：

import { isFSA } from 'flux-standard-action';

function isPromise(val) {
  return val && typeof val.then === 'function';
}

export default function promiseMiddleware({ dispatch }) {
  return next => action => {
    if (!isFSA(action)) {
      return isPromise(action)
        ? action.then(dispatch)
        : next(action);
    }

    return isPromise(action.payload)
      ? action.payload.then(
          result => dispatch({ ...action, payload: result }),
          error => {
            dispatch({ ...action, payload: error, error: true });
            return Promise.reject(error);
          }
        )
      : next(action);
  };
}

和 redux-thunk 一样，我们抛开复杂的链式箭头函数调用，该中间件做的一件事就是判断 action 或 action.payload 是不是一个 Promise 对象，如果是的话，同样地拦截等待 Promise 对象 resolve 返回数据之后再调用 dispatch，同样的，这个 Promise action 也不会被传递给 reducer 进行处理，如果不是 Promise 对象就不处理。

所以一个异步 action 流程就变成了这样：

view -> Promise action -> redux-promise 拦截 -> 等待 promise resolve -> 将 promise resolve 返回的新的 action(普通) 对象 dispatch -> reducer -> newState -> container component

通过 redux-promise 中间件我们可以在编写 promise action，我们对之前的例子进行修改：

cd asynchronous_with_redux_promise/
yarn 
yarn start

我们修改一下 actionCreator：

// actionCreator/index.js
export default {
    fetchNewsTitle: () => {
        return axios.get('/api/v1/topics').then(response => ({
            type: actionTypes.FETCH_SUCCESS,
            news: response.data,
        })).catch(err => ({
            type: actionTypes.FETCH_FAILURE,
        }))
    },
}

修改 store 中间件 redux-promise

// store/index.js

import { createStore, applyMiddleware } from 'redux'
import reducer from '../reducers'
import reduxPromise from 'redux-promise'

export default createStore(reducer, initValue, applyMiddleware(reduxPromise))

效果:没有 Loading 这个中间状态

但是如果使用 redux-promise 的话相当于是延后执行了 action，等获取到结果之后再重新 dispatch action。这么写其实有个问题，就是无法发起 FETCH_START action，因为actionCreator 中没有 dispatch 这个字段，redux-promise 虽然赋予了 action 延后执行的能力，但是没有能力发起多 action 请求。

严格上来说，我们完全可以写一个中间件，通过判断 action 对象上的某个字段或者什么其他字段，代码如下:

const thunk = ({ dispatch, getState }) => next => action => {
	if(typeof action.async === 'function') {
	    return action.async(dispatch, getState);
	}
	return next(action);
}

如果能够这样理解 action 对象，那么我们也没有要求 Promise 中间件处理的异步 action 对象是 Promise 对象，只需要 action 对象谋改革字段是 Promise 字段就行，而 action 对象可以拥有其他字段来包含更多信息。所以我们可以自己编写一个中间件：

// myPromiseMiddleware
const isPromise = (obj) => {
    return obj && typeof obj.then === 'function';
}

export default ({ dispatch }) => (next) => (action) => {
    const { types, async, ...rest } = action
    if(!isPromise(async) || !(action.types && action.types.length === 3)) {
        return next(action)
    }
    const [PENDING, SUCCESS, FAILURE] = types
    dispatch({
        ...rest,
        type: PENDING,
    })
    return action.async.then(
        (result) => dispatch({ ...rest, ...result, type: SUCCESS }),
        (error) => dispatch({ ...rest, ...error, type: FAILURE })
    )
}

不难理解，中间件接受同样接收一个 action JS 对象，这个对象需要满足 async 字段是 Promise 对象并且 types 字段长度为 3，否则这不是我们需要的处理的 action 对象，我们传入的 types 字段是个数组，分别为 FETCH_START，FETCH_SUCCESS，FETCH_FAILURE，相当于是我们做个一层约定，让中间件内部去帮我们消化这样的异步 action，当 async promise 对象返回之后调用 FETCH_SUCCESS，FETCH_FAILURE action。

我们改写 actionCreator

// actionCreator/index.js
export default {
    myFetchNewsTitle: () => {
        return {
            async: axios.get('/api/v1/topics').then(response => ({
                news: response.data,
            })),
            types: [ actionTypes.FETCH_START, actionTypes.FETCH_SUCCESS, actionTypes.FETCH_FAILURE ]
        }
    },
}

这样写相当于是我们约定好了格式，然后让相应地中间件去处理就可以了。但是扩展性较差，适合小型团队共同开发约定好具体的异步格式。

Redux-saga：功能强大

redux-saga 也是解决 redux 异步 action 的一个中间件，不过它与前面的解决方案思路有所不同，它另辟新径：

1. redux-saga 完全基于 ES6 的生成器。
2. 不污染 action，仍使用同步的 action 策略，而是通过监控 action，自动做处理。
3. 所有带副作用的操作，如异步请求，业务控制逻辑代码都可以放到独立的 saga 中来。

让异步行为成为架构中独立的一层(称为 saga)，既不在 action creator 中，也不和 reducer 沾边。

它的出发点是把副作用 (Side effect，异步行为就是典型的副作用) 看成"线程"，可以通过普通的 action 去触发它，当副作用完成时也会触发 action 作为输出。

详细的文档说明可以看: Redux-saga Beginner Tutorial

接下来我也会举很多例子来说明 redux-saga 的优点。

我们老规矩先来改写我们之前的例子:

cd asynchronous_with_redux_saga/
yarn 
yarn start

首先先来看 actionCreator：

import * as actionTypes from '../actionTypes'
export default {
    fetchNewsTitle: () => {
        return {
            type: actionTypes.FETCH_START
        }
    },
	// ...
}

是不是变得很干净，因为处理异步的逻辑已经在 creator 里面了，转移到 saga 中，我们来看一下 saga 是怎么写的。

// sagas/index.js

import { put, takeEvery } from 'redux-saga/effects'
import * as actionTypes from '../actionTypes'
import axios from 'axios'

function* fetchNewsTitle() {
    try {
        const response = yield axios.get('/api/v1/topics')
        if(response.status === 200) {
            yield put({
                type: actionTypes.FETCH_SUCCESS,
                news: response.data,
            })
        }else {
            throw new Error('fetch failure')
        }
    } catch(e) {
        yield put({
            type: actionTypes.FETCH_FAILURE
        })
    }
}

export default function* fecthData () {
    yield takeEvery(actionTypes.FETCH_START, fetchNewsTitle)
}

可以发现这里写的跟之前写的异步操作基本上是一模一样，上面的代码不理解，takeEvery 监听所有的 action，每当发现 action.type === FETCH_START 时执行 fetchNewsTitle 这个函数，注意这里只是做监听 action 的动作，并不会拦截 action，这说明 FETCH_START action 仍然会经过 reducer 去处理，剩下 fetchNewsTitle 函数就很好理解，就是执行所谓的异步操作，这里的 put 相当于 dispatch。

最后我们需要在 store 里面使用 saga 中间件

// store/index.js
import createSagaMiddleware from 'redux-saga'
import mySaga from '../sagas'

const sagaMiddleware = createSagaMiddleware()

// ...

export default createStore(reducer, initValue, applyMiddleware(sagaMiddleware))
sagaMiddleware.run(mySaga)

通过注册 saga 中间件并且 run 监听 saga 任务，也就是前面提到的 fecthData。

基于这么一个简单的例子，我们可以看到 saga 将所有的带副作用的操作与 actionCreator 和 reducer 进行分离，通过监听 action 来做自动处理，相比 async action creator 的方案，它可以保证组件触发的 action 是纯对象。

参考回答：redux-saga 实践总结

它与 redux-thunk 编写异步的方式有着它各自的应用场景，没有优劣之分，所谓存在即合理。redux-saga 相对于这种方式，具有以下的特点：

1. 生命周期有所不同，redux-saga 可以理解成一直运行与后台的长时事务，而 redux-thunk 是一个 action，因为 redux-saga 能做的事更多。
2. redux-saga 有诸多声明式易测的 Effects，比如无阻塞调用，中断任务，这些特性在业务逻辑复杂的场景下非常适用。
3. redux-saga 最具魅力的地方，是它保持了 action 的原义，保持 action 的简洁，把所有带副作用的地方独立开来，这些特性使得其在业务逻辑简单的场景下，也能保持代码清晰简洁。

在我看来：redux-thunk + async/await 的方式学习成本低，比较适合不太复杂的异步交互场景。对于竞态判断，多重 action 组合，取消异步等场景下使用则显得乏力，redux-saga 在异步交互复杂的场景下仍能够让你清晰直观地编写代码，不过学习成本相对较高。

以上我们介绍了三种 redux 异步方案，其实关于 redux 异步方案还有很多，比如：redux-observale，通过 rxjs 的方式来书写异步请求，也有像 redux-loop 这样的方式通过在 reducer 上做文章来达到异步效果。其实方案千千万万，各成一派，每种方案都有其适合的场景，结合自己实际的需求来选择你所使用的 redux 异步方案才最可贵。

thunk 和 saga 异步方案对比

对于前面获取异步的例子，还没有结束，它仍存在着一些问题：

1. 没有进行防抖处理，如果用户疯狂点击按钮，那么将会不断发起异步请求，这样无形之中就对带宽造成了浪费。
2. 没有做竞态判断，点击按钮可以获取 CNode 标题并呈现，因为异步请求返回的时间具有不确定性，多次点击就可能出现后点击的请求先返回先渲染，而前面点击的请求后返回覆盖了最新的请求结果。
3. 没有做取消处理，是想一下，在某些场景下，在等待的过程中，用户是有可能取消这个异步操作的，这时候就不呈现结果了。

下面我们将重新改写一个例子，分别用 redux-thunk 和 redux-saga 对其进行处理上述的问题，并进行比较。

我们要做的例子效果如下：

1. 有两个按钮用来模拟异步请求，分别在 5s 和 1s 内响应数据，我们需要保证按钮点击的顺序性，即当 5s 后数据返回时不会覆盖掉最新数值 1000，保证页面上显示的数据永远是最后一次点击获取到的数据。
2. 防抖处理，在 1000ms 内再次点击按钮不会进行响应。

cd race_with_redux_thunk/
yarn 
yarn start

查看 actionCreator：

// actions/index.js
import * as actionTypes from '../actionTypes'
let nextId = 0
let prev = 0
export const updateData = (ms) => {
     return (dispatch) => {
        let id = ++nextId
        let now = + new Date()
        if(now - prev < 1000) {
            return;
        }
        prev = now;

        const checkLast = (action) => {
            if(id === nextId) {
                dispatch(action)
            }
        }
        setTimeout(() => {
            checkLast({
                type: actionTypes.UPDATE_DATA,
                payload: ms,                    
            })
        }, ms)
    }
}