vue之keep-alive

页面缓存

在Vue构建的单页面应用（SPA）中，路由模块一般使用vue-router。vue-router不保存被切换组件的状态，它进行push或者replace时，旧组件会被销毁，而新组件会被新建，走一遍完整的生命周期。

但有时候，我们有一些需求，比如跳转到详情页面时，需要保持列表页的滚动条的深度，等返回的时候依然在这个位置，这样可以提高用户体验。在Vue中，对于这种“页面缓存”的需求，我们可以使用keep-alive组件来解决这个需求。

keep-alive是什么

keepalive 是 Vue 内置的一个组件，可以使被包含的组件保留状态，或避免重新渲染，将组件进行持久化。也就是所谓的组件缓存

keep-alive使用方式

keep-alive是个抽象组件（或称为功能型组件），实际上不会被渲染在DOM树中。它的作用是在内存中缓存组件（不让组件销毁），等到下次再渲染的时候，还会保持其中的所有状态，并且会触发activated钩子函数。因为缓存的需要通常出现在页面切换时，所以常与router-view一起出现：

1
2
3
<keep-alive>
    <router-view />
</keep-alive>

如此一来，每一个在router-view中渲染的组件，都会被缓存起来。

如果只想渲染某一些页面/组件，可以使用keep-alive组件的include/exclude属性。include属性表示要缓存的组件名（即组件定义时的name属性），接收的类型为string、RegExp或string数组；exclude属性有着相反的作用，匹配到的组件不会被缓存。exclude优先级更高。假如可能出现在同一router-view的N个页面中，我只想缓存列表页和详情页，那么可以这样写：

1
2
3
<keep-alive :include="['ListView', 'DetailView']">
    <router-view />
</keep-alive>

被keepalive包含的组件不会被再次初始化，也就意味着不会重走生命周期函数。但是有时候是希望我们缓存的组件可以能够再次进行渲染，这时 Vue 为我们解决了这个问题 被包含在 keep-alive 中创建的组件，会多出两个生命周期的钩子: activated 与 deactivated：

  • activated 当 keepalive 包含的组件再次渲染的时候触发
  • deactivated 当 keepalive 包含的组件销毁的时候触发

keepalive是一个抽象的组件，缓存的组件不会被 mounted,为此提供activated和deactivated钩子函数

实现条件缓存：全局的include数组

上面include的写法不是常用的，因为它固定了哪几个页面缓存或不缓存，假如有下面这个场景：

  • 现有页面：首页（A）、列表页（B）、详情页（C），一般可以从：A->B->C；
  • B到C再返回B时，B要保持列表滚动的距离；
  • B返回A再进入B时，B不需要保持状态，是全新的

很明显，这个例子中，B是“条件缓存”的，C->B时保持缓存，A->B时放弃缓存。其实解决方案也不难，只需要将B动态地从include数组中增加/删除就行了。具体步骤是：

1.在Vuex中定义一个全局的缓存数组，待传给include：

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

export default {
    namespaced: true,
    state: {
        keepAliveComponents: [] // 缓存数组
    },
    mutations: {
        keepAlive (state, component) {
            // 注：防止重复添加（当然也可以使用Set）
            !state.keepAliveComponents.includes(component) && state.keepAliveComponents.push(component)
        },
        noKeepAlive (state, component) {
            const index = state.keepAliveComponents.indexOf(component)
            index !== -1 && state.keepAliveComponents.splice(index, 1)
        }
    }
}

2.在父页面中定义keep-alive，并传入全局的缓存数组：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// App.vue
<div class="app">
    <!--传入include数组-->
    <keep-alive :include="keepAliveComponents">
        <router-view></router-view>
    </keep-alive>
</div>

export default {
    computed: {
        ...mapState({
            keepAliveComponents: state => state.global.keepAliveComponents
        })
    }
}

3.缓存：在路由配置页中，约定使用meta属性keepAlive，值为true表示组件需要缓存。在全局路由钩子beforeEach中对该属性进行处理，这样一来，每次进入该组件，都进行缓存：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const router = new Router({
    routes: [
        {
            path: '/A/B',
            name: 'B',
            component: B,
            meta: {
                title: 'B页面',
                keepAlive: true // 这里指定B组件的缓存性
            }
        }
    ]
})

router.beforeEach((to, from, next) => {
    // 在路由全局钩子beforeEach中，根据keepAlive属性，统一设置页面的缓存性
    // 作用是每次进入该组件，就将它缓存
    if (to.meta.keepAlive) {
        store.commit('global/keepAlive', to.name)
    }
})

4.取消缓存的时机：对缓存组件使用路由的组件层钩子beforeRouteLeave。因为B->A->B时不需要缓存B，所以可以认为：当B的下一个页面不是C时取消B的缓存，那么下次进入B组件时B就是全新的：

1
2
3
4
5
6
7
8
9
10
11
12
13
export default {
    name: 'B',
    created () {
        // ...设置滚动条在最顶部
    },
    beforeRouteLeave (to, from, next) {
        // 如果下一个页面不是详情页（C），则取消列表页（B）的缓存
        if (to.name !== 'C') {
            this.$store.commit('global/noKeepAlive', from.name)
        }
        next()
    }
}

因为B的条件缓存，是B自己的职责，所以最好把该业务逻辑写在B的内部，而不是A中，这样不至于让组件之间的跳转关系变得混乱。

5.一个需要注意的细节：因为keep-alive组件的include数组操作的对象是组件名、而不是路由名，因此我们定义每一个组件时，都要显式声明name属性，否则缓存不起作用。而且，一个显式的name对Vue devtools有提示作用。

展开全文 >>

webpack优化

webpack优化的最终目的

快 + 小 + 按需加载 + 利用浏览器缓存

一个是速度、一个是体积、一个是用到什么加载什么、公用代码可以利用浏览器缓存

一、 减少webpack打包的时间

1. 优化 Loader 配置

对于 Loader 来说，影响打包效率首当其冲必属 Babel 了。因为 Babel 会将代码转为字符串生成 AST，然后对 AST 继续进行转变最后再生成新的代码，项目越大，转换代码越多，效率就越低。当然了，我们是有办法优化的。

首先我们可以优化 Loader 的文件搜索范围（Loader处理的文件路径，与不处理的文件路径指定。以及作用到什么类型的文件）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
module.exports = {
    module: {
        rules: [
        {
            // js 文件才使用 babel
            test: /\.js$/,
            loader: 'babel-loader',
            // 只在 src 文件夹下查找
            include: [resolve('src')],
            // 不会去查找的路径
            exclude: /node_modules/
        }
        ]
    }
}

对于 Babel 来说，我们肯定是希望只作用在 JS 代码上的，然后 node_modules 中使用的代码都是编译过的，所以我们也完全没有必要再去处理一遍。

当然这样做还不够，我们还可以将 Babel 编译过的文件缓存起来，下次只需要编译更改过的代码文件即可，这样可以大幅度加快打包时间

1
loader: 'babel-loader?cacheDirectory=true'

总结起来loader的优化点：

  • 比如babel-loader查找的路径，与不查找的路径指定
  • 缓存babel编译过的文件

2. HappyPack开启多线程打包

受限于 Node 是单线程运行的，所以 Webpack 在打包的过程中也是单线程的，特别是在执行 Loader 的时候，长时间编译的任务很多，这样就会导致等待的情况。

HappyPack 可以将 Loader 的同步执行转换为并行的，这样就能充分利用系统资源来加快打包效率了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
module: {
    loaders: [
        {
            test: /\.js$/,
            include: [resolve('src')],
            exclude: /node_modules/,
            // id 后面的内容对应下面
            loader: 'happypack/loader?id=happybabel'
        }
    ]
},
plugins: [
    new HappyPack({
        id: 'happybabel',
        loaders: ['babel-loader?cacheDirectory'],
        // 开启 4 个线程
        threads: 4
    })
]

通过此插件开启多线程打包，充分利用系统资源

3. DllPlugin （提前打包指定的类库）

DllPlugin 可以将特定的类库提前打包然后引入。这种方式可以极大的减少打包类库的次数，只有当类库更新版本才有需要重新打包，并且也实现了将公共代码抽离成单独文件的优化方案。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 单独配置在一个文件中
// webpack.dll.conf.js
const path = require('path')
const webpack = require('webpack')
module.exports = {
    entry: {
        // 想统一打包的类库
        vendor: ['react']
    },
    output: {
        path: path.join(__dirname, 'dist'),
        filename: '[name].dll.js',
        library: '[name]-[hash]'
    },
    plugins: [
        new webpack.DllPlugin({
            // name 必须和 output.library 一致
            name: '[name]-[hash]',
            // 该属性需要与 DllReferencePlugin 中一致
            context: __dirname,
            path: path.join(__dirname, 'dist', '[name]-manifest.json')
        })
    ]
}

然后我们需要执行这个配置文件生成依赖文件，接下来我们需要使用 DllReferencePlugin 将依赖文件引入项目中

1
2
3
4
5
6
7
8
9
10
11
// webpack.conf.js
module.exports = {
    // ...省略其他配置
    plugins: [
        new webpack.DllReferencePlugin({
            context: __dirname,
            // manifest 就是之前打包出来的 json 文件
            manifest: require('./dist/vendor-manifest.json'),
        })
    ]
}

总结：

  • 将特订的类库提前打包然后引入，减少打包类库的次数，加快打包速度
  • 同时将公共代码抽离成单独的文件

4. 代码并行压缩

在 Webpack3 中，我们一般使用 UglifyJS 来压缩代码，但是这个是单线程运行的，为了加快效率，我们可以使用 webpack-parallel-uglify-plugin 来并行运行 UglifyJS，从而提高效率。

在 Webpack4 中，我们就不需要以上这些操作了，只需要将 mode 设置为 production 就可以默认开启以上功能。代码压缩也是我们必做的性能优化方案，当然我们不止可以压缩 JS 代码，还可以压缩 HTML、CSS 代码，并且在压缩 JS 代码的过程中，我们还可以通过配置实现比如删除 console.log 这类代码的功能。

总结：

  • webpack4 生产模式，默认开启多个子进程（线程）由之前的一个一个压缩，变为并行压缩

5. 其他

  • resolve.extensions：用来表明文件后缀列表，默认查找顺序是 [‘.js’, ‘.json’]，如果你的导入文件没有添加后缀就会按照这个顺序查找文件。我们应该尽可能减少后缀列表长度，然后将出现频率高的后缀排在前面
  • resolve.alias：可以通过别名的方式来映射一个路径，能让 Webpack 更快找到路径
  • module.noParse：如果你确定一个文件下没有其他依赖，就可以使用该属性让 Webpack 不扫描该文件，这种方式对于大型的类库很有帮助

二、减少 Webpack 打包后的文件体积

1. Scope Hoisting

Scope Hoisting 会分析出模块之间的依赖关系，尽可能的把打包出来的模块合并到一个函数中去。代码体积更小，因为函数申明语句会产生大量代码，代码在运行时因为创建的函数作用域更少了，内存开销也随之变小

由于scope hositing 需要分析出模块之间的依赖关系，因此源码必须使用ES6模块化语句，不然就不能生效，原因和tree shaking一样

比如我们希望打包两个文件

1
2
3
4
// test.js
export const a = 1
// index.js
import { a } from './test.js'

对于这种情况，我们打包出来的代码会类似这样

1
2
3
4
5
6
7
8
9
10
[
    /* 0 */
    function (module, exports, require) {
        //...
    },
    /* 1 */
    function (module, exports, require) {
        //...
    }
]

但是如果我们使用 Scope Hoisting 的话，代码就会尽可能的合并到一个函数中去，也就变成了这样的类似代码

1
2
3
4
5
6
[
    /* 0 */
    function (module, exports, require) {
        //...
    }
]

这样的打包方式生成的代码明显比之前的少多了。如果在 Webpack4 中你希望开启这个功能，只需要启用 optimization.concatenateModules 就可以了。

1
2
3
4
5
module.exports = {
    optimization: {
        concatenateModules: true
    }
}

webpack3需要使用ModuleConcatenationPlugin

1
new webpack.optimize.ModuleConcatenationPlugin()

总之，尽可能的合并打包出来的模块到一个函数中去

2. Tree Shaking （webpack 4 生产环境 默认开启）

tree shaking是一个术语、通常用于打包时移除js中未引用的代码(dead-code)，它依赖于ES6模块系统中的import 和 export 的静态结构特性

Tree Shaking 可以实现删除项目中未被引用的代码，比如

1
2
3
4
5
// test.js
export const a = 1
export const b = 2
// index.js
import { a } from './test.js'

对于以上情况，test 文件中的变量 b 如果没有在项目中使用到的话，就不会被打包到文件中。

如果使用 Webpack 4 的话，开启生产环境就会自动启动这个优化功能。

三、按需加载(懒加载) + 动态加载 + 异步加载

当页面中一个文件过大并且还不一定用到的时候，我们希望在使用到的时候才开始加载这个文件俗称按需加载

这样可以减少页面的响应时间，提高访问速度。

webpack按需加载有 require.ensure和 import两种方法。

require.ensure 按需异步加载

CommonJS解决方案， webpack 特有的，已经被 import() 取代

1
2
3
4
5
6
require.ensure(
    dependencies: String[],
    callback: function(require),
    errorCallback: function(error),
    chunkName: String
)

给定 dependencies 参数，将其对应的文件拆分到一个单独的 bundle 中，此 bundle 会被异步加载。当使用 CommonJS 模块语法时，这是动态加载依赖的唯一方法。意味着，可以在模块执行时才运行代码，只有在满足某些条件时才加载依赖项。

import() 动态地加载模块

调用 import() 之处，被作为分离的模块起点，意思是，被请求的模块和它引用的所有子模块，会分离到一个单独的 chunk 中。

ES2015 loader 规范 定义了 import() 方法，可以在运行时动态地加载 ES2015 模块。

eg1. 当点击按钮时 再加载lazy.js 输出里面内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// lazy.js
export default 'lazy loader';

// main.js
let output = () => {
    import('./lazy').then(module => {
        console.log(module.default);
    });
};
ReactDOM.render(
    <div>
    <button onClick={output}>点击</button>
    </div>,
    document.querySelector('#root')
)

eg2. vue中的懒加载

1
2
3
4
5
6
7
const Login = () => import(/* webpackChunkName: "login" */'./login')

new VueRouter({
  routes: [
    { path: '/login', component: Login }
  ]
})

ps： require.ensure 和 import() 这个特性依赖于内置的 Promise。如果想在低版本浏览器使用 require.ensure，记得使用像 es6-promise 或者 promise-polyfill 这样 polyfill 库，来预先填充(shim) Promise 环境。

利用浏览器缓存

提取公共代码与第三方代码

将多个入口重复加载的公共资源提取出来

  • 相同的资源被重复的加载，浪费用户的流量和服务器的成本；
  • 每个页面需要加载的资源太大，导致网页首屏加载缓慢，影响用户体验。如果能把公共代码抽离成单独文件进行加载能进行优化，可以减少网络传输流量，降低服务器成本
1
2
3
4
5
6
7
8
optimization: {
    splitChunks: {
        // 默认打包node_modules到venders.js
        chunks: 'all'
    },
    // 将webpack运行时生成代码打包到runtime.js
    runtimeChunk: true
},

在webpack4.0 optimization.splitChunks替代了CommonsChunkPlugin

总结

优化角度

  • 打包速度
  • 产物体积
  • 按需加载、异步加载、动态加载
  • 利用浏览器缓存
  • 开发流程规范和体验

打包速度

  • 优化Loader配置 - 1）查找路径include exclude 2）缓存babel编译过的文件babel-loader?cacheDirectory=true
  • HappyPack开启多线程打包
  • DllPlugin提前打包指定的类库 webpack.dll.conf.js DllReferencePlugin，减少打包类库的次数，同时将公共代码抽离成单独的文件
  • 代码并行压缩 - webpack3 UglifyJS压缩混淆代码，webpack-parallel-uglify-plugin并行运行UglifyJS；Webpack4 mode = production时自动开启
  • 压缩html、css
  • resolve.extensions [‘.js’, ‘.json’]尽可能减少后缀列表长度,出现频率高的后缀排在前面
  • resolve.alias 别名映射路径,Webpack 不扫描该文件
  • module.noParse

产物体积

  • Scope Hoisting 尽可能的合并打包出来的模块到一个函数中去 optimization.concatenateModules ModuleConcatenationPlugin
  • js/css Tree Shaking webpack 4prod js 默认开启。css 用PurifyCssPlugin
  • 文件处理 & base64 & css-sprites
  • 代码压缩 UglifyJS

按需加载、异步加载、动态加载

require.ensure、import 路由懒加载

利用浏览器缓存做长缓存优化

提取公共代码与第三方代码做长缓存优化

开发流程规范和体验

  • 模块热更新
  • sourceMap
  • webpack-dev-server-proxy 接口代理
  • ts
  • BundleAnalyzerPlugin分析打包情况

参考：
https://juejin.im/post/5ac76a8f51882555677ecc06#heading-5

https://juejin.im/post/5dcc45136fb9a02b450c2818

展开全文 >>

实现cacheRequest，相同资源ajax只发一次请求

请实现一个cacheRequest方法，保证当前ajax请求相同资源时，真实网络层中，实际只发出一次请求（假设已经存在request方法用于封装ajax请求）

一开始看到第一感觉是，设个Http Headercache-control，把expire调大，不就自然会找浏览器缓存拿了。但是看到后面说提供自带的request方法和只发起一次ajax。那估计是想让笔者在业务层自己用代码解决这个cache问题。

more >>

展开全文 >>

a11y

什么是Accessibility - a11y

a11y

Accessibility，通常缩写为 A11Y ，这缩写取的是首字母 + 中间字母长度 + 结尾字母，译为 “可访问性”。这是一种让尽可能多的人访问我们所开发的网站的技术概念，通过这个概念，让互联网访问公平变得可能。

A11Y是一件非常正确的事，在某些国家与地区，甚至提供无障碍站点已经成为了法律的一部分。

Web根本的目的是为了服务于所有人，而不是受限于软硬件，语言，文化，位置以及身心状态。

Web Accessibility，译为 “网页亲和力（又称网络无障碍、网络可达性、网络可用性、网页可访问性）” 。

无论是一般人或者是身心障碍的朋友，都需要有规范的网站方可便捷地获取信息，无障碍网页则是拓展对网页的规范，以更严谨的态度及条件来设计网页，使网页内容落实“无障碍”让不同程度或需求的用户，可以顺畅的获取网站上的信息。

我们所应该关注的障碍类型

根据W3C所处的Web内容无障碍指南（WCAG）所提到的，主要的障碍类型有以下四类：

  • 视力障碍
  • 听力障碍
  • 行动障碍
  • 认知障碍

世界卫生组织(World Health Organization)的残疾和健康(Disability and health)状况说明书指出，“超过10亿人，约占世界人口的15%，患有某种形式的残疾”，“1.1亿至1.9亿成年人在功能上存在重大困难。”

视力障碍（Visual impairments）

视力障碍，是指视力下降到一定程度，导致某种程度的问题无法通过通常的手段（例如眼镜）解决。有些人还包括因无法接触眼镜或隐形眼镜而导致视力下降的人。视力障碍可能会导致人们在日常日常活动（例如驾车，阅读，社交和步行）中遇到困难。这部分的人通常会使用一些辅助的功能来阅读屏幕，例如放大镜，屏幕缩放以及屏幕阅读器。常见的屏幕阅读器有：

付费的产品：JAWS (Windows) 和 Dolphin Screen Reader (Windows)。
免费的产品：NVDA (Windows)，ChromeVox (Chrome, Windows and Mac OS X)和 Orca (Linux)。
内置的产品：VoiceOver (macOS, iPadOS, iOS)，Narrator (Microsoft Windows，ChromeVox (on Chrome OS)和 TalkBack (Android).

听力障碍（Hearing impairments）

听觉障碍又称听力缺损，指听觉部分或完全丧失，而耳聋人士则是指完全没有或几乎没有听力者。听力缺损可能发生在单耳或双耳，有可能是暂时或永久性质。孩童的听力问题可能影响语言学习，而对成人可能造成工作上的困难。对某些人而言，尤其是老年人口，听力缺损可能造成孤独感。

听力障碍的人可能听力水平低或甚至完全听不见声音，听力受损的人可能会使用ATs(请参阅针对患有听力、语音、言语或语言障碍的人的辅助设备)，不过在Web中并没有专门的ATs可以使用。

行动障碍（Mobility impairments）

行动障碍是指一个人不能使用他/她的一条或多条四肢，或缺乏行走、抓取或抬起物体的力量。轮椅、拐杖或助行器的使用可用于辅助行动。活动能力障碍可能由多种因素引起，如疾病、事故或先天性疾病，也可能是神经肌肉和骨科损伤所致。
声控轮椅是提高行动障碍人士生活质量最重要的发明之一。声控轮椅最初发明于1977年。
缺少手臂或者手指的障碍人士会严重影响使用键盘与鼠标，但是在近些年，语音识别设备跟软件都有了极大的发展，也为这部分障碍人士提供了不少的便利。

认知障碍（Cognitive impairments）

认知障碍是一种范围广泛的残疾类型，从能力最有限的智障人士到我们随着年龄增长和思考和记忆困难而出现的所有人。 该范围包括患有精神疾病的人，例如抑郁症和精神分裂症。 它还包括有学习障碍的人，例如阅读障碍和注意力缺陷多动障碍。 重要的是，尽管认知障碍的临床定义存在很多差异，但与之相关的人们会遇到一系列常见的功能问题。 其中包括难以理解内容，记住如何完成任务以及因网页布局不一致而引起的混乱。

另外提一点，就是癫痫患者也属于我们认知障碍者的范畴，我们在开发的时候，这部分人士也是我们需要考虑的。

在MDN上有为了认知障碍者总结的开发守则：

  • 用多种方式展示内容，例如通过文本，语音或视频；
  • 编写易于理解的内容，例如少用方言或者颜文字；
  • 重要的内容要细心写；
  • 尽量减少干扰，例如一些没什么用的功能与广告；
  • 网页布局与导航要一致；
  • 常规的元素样式，例如带下划线的链接（未访问时为蓝色）和访问时为紫色；
  • 流程交互要具有进度以及步骤指示；
  • 用户权限认证方式要简单；
  • 错误信息要展示清楚；
  • 表单要便于填写与操作。

WCAG

Web内容可访问性指南(WCAG)是由互联网的主要国际标准组织万维网联盟(W3C)的Web可访问性倡议(WAI)发布的一系列Web可访问性指南的一部分。它们是一组使Web内容更易于访问的建议，主要针对残疾人，但也适用于所有用户代理，包括高度受限的设备，如移动电话。WCAG2.0，于2008年12月发布，并于2012年10月成为国际标准化组织标准，ISO/IEC 40500：2012。WCAG 2.1于2018年6月成为W3C推荐标准。

WCAG主要指南如下：

可感知性（Perceivable）

信息和用户界面组件必须以可感知的方式呈现给用户。

为所有非文本内容提供替代文本，使其可以转化为人们需要的其他形式，如大字体印刷、盲文、语音、符号或更简单的语言。
为时基媒体提供替代。
创建可用不同方式呈现的内容（例如简单的布局），而不会丢失信息或结构。

可操作性（Operable）

用户界面组件和导航必须可操作。

  • 使所有功能都能通过键盘来操作。
  • 为用户提供足够的时间用以阅读和使用内容。
  • 不要设计会导致癫痫发作的内容。
  • 提供帮助用户导航、查找内容、并确定其位置的方法。

可理解性（Understandable）

信息和用户界面操作必须是可理解的。

  • 使文本内容可读，可理解。
  • 让网页以可预见的方式呈现和操作。
  • 帮助用户避免和纠正错误。

鲁棒性（Robust）

内容必须健壮到可信地被种类繁多的用户代理(包括辅助技术)所解释。

最大化兼容当前和未来的用户代理(包括辅助技术)。

WAI-ARIA

Web Accessibility Initiative –可访问的富Internet应用程序（WAI-ARIA）是由万维网联盟（W3C）发布的一项技术规范，该规范指定了如何增加网页的可访问性，尤其是动态内容以及使用该工具开发的用户界面组件。 Ajax，HTML，JavaScript和相关技术。

前言

WAI-ARIA是A11Y应用规范，主要就是针对于上述的障碍类型以及WCAG要求的技术细则，运用好这些技术细则，那么浏览障碍人士便能轻松访问我们的应用。

在本文，我们讨论下前端里的WAI-ARIA规范，以下是规范里的三个主要特征：

角色（Roles）

WAI-ARIA角色是使用role属性在元素上设置的，类似于role属性[role]中定义的role属性。

例子如下：

1
<li role="menuitem">Open file…</li>

此分类中的role可选属性如下：

a11y-role

如上图，role 可选属性有点多，但其实主要就分了四类：

抽象角色（Abstract Roles）
小部件角色（Widget Roles）
文件结构角色（Document Structure Roles）
地标角色（Landmark Roles）

其主要作用为：

  • 角色信息描述。
  • 相关角色的等级信息。
  • 角色上下文。
  • 引用其他规范中的相关概念。
  • 使用OWL（Web Ontology Language）提供允许语义继承的类型层次结构。
  • 每个角色支持的状态和属性。

状态与属性（States and Properties）

WAI-ARIA提供了可访问性状态和属性的集合，这些状态和属性用于支持各种操作系统平台上的平台可访问性API。辅助技术可以通过公共的用户代理应用（例如读屏软件）DOM或通过映射到平台可访问性API来访问这些信息。当与角色结合时，用户代理应用可以为辅助技术提供用户界面信息，以便随时传递给用户。状态或属性的更改将导致向辅助技术发出通知，这可能会警告用户发生了更改。

我们来看个例子：

1
<li role="menuitemcheckbox" aria-checked="true">Sort by Last Modified</li>

上面的例子里，使用了一个<li>来创建一个可点击的菜单，通过JS的事件来改变aria-checked，从而让用户代理应用理解这部分的功能作用。

由于这部分是用户主动进行的操作，并非默认状态，所以为了更佳的体验，我们可以对aria-checked=”true”时li进行样式处理，如下：

1
2
[aria-checked="true"] { font-weight: bold; }
[aria-checked="true"]:before { background-image: url(checked.gif); }

焦点管理（Managing Focus）

WAI-ARIA里提倡，所有的用户交互对象都应该是可聚焦的，就是键盘可选中的。

当我们使用标准的HTML标签以及WAI-ARIA小部件时，开发者应该按顺序创建键盘可访问的节点，例如Tabs键，方向键等。

参考：
https://juejin.im/post/5dee4e39f265da33ba5a799b

展开全文 >>

express之router

前言

从Express 4.0开始，路由器功能成了一个单独的组件Express.Router。它好像小型的express应用程序一样，有自己的use、get、param和route方法。

基本用法

首先，Express.Router是一个构造函数，调用后返回一个路由器实例。然后，使用该实例的HTTP动词方法，为不同的访问路径，指定回调函数；最后，挂载到某个路径。

1
2
3
4
5
6
7
8
9
10
11
var router = express.Router();

router.get('/', function(req, res) {
    res.send('首页');
});

router.get('/about', function(req, res) {
    res.send('关于');
});

app.use('/', router);

上面代码先定义了两个访问路径，然后将它们挂载到根目录。如果最后一行改为app.use(‘/app’, router)，则相当于为/app和/app/about这两个路径，指定了回调函数。

这种路由器可以自由挂载的做法，为程序带来了更大的灵活性，既可以定义多个路由器实例，也可以为将同一个路由器实例挂载到多个路径。

router.route方法

router实例对象的route方法，可以接受访问路径作为参数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
var router = express.Router();

router.route('/api')
    .post(function(req, res) {
        // ...
    })
    .get(function(req, res) {
        Bear.find(function(err, bears) {
            if (err) res.send(err);
            res.json(bears);
        });
    });

app.use('/', router);

router中间件

use方法为router对象指定中间件，即在数据正式发给用户之前，对数据进行处理。下面就是一个中间件的例子。

1
2
3
4
router.use(function(req, res, next) {
    console.log(req.method, req.url);
    next();
});

上面代码中，回调函数的next参数，表示接受其他中间件的调用。函数体中的next()，表示将数据传递给下一个中间件。

注意，中间件的放置顺序很重要，等同于执行顺序。而且，中间件必须放在HTTP动词方法之前，否则不会执行。

对路径参数的处理

router对象的param方法用于路径参数的处理，可以

1
2
3
4
5
6
7
8
9
10
router.param('name', function(req, res, next, name) {
    // 对name进行验证或其他处理……
    console.log(name);
    req.name = name;
    next();
});

router.get('/hello/:name', function(req, res) {
    res.send('hello ' + req.name + '!');
});

上面代码中，get方法为访问路径指定了name参数，param方法则是对name参数进行处理。注意，param方法必须放在HTTP动词方法之前。

app.route

假定app是Express的实例对象，Express 4.0为该对象提供了一个route属性。app.route实际上是express.Router()的缩写形式，除了直接挂载到根路径。因此，对同一个路径指定get和post方法的回调函数，可以写成链式形式。

1
2
3
4
5
6
7
8
app.route('/login')
    .get(function(req, res) {
        res.send('this is the login form');
    })
    .post(function(req, res) {
        console.log('processing');
        res.send('processing the login form!');
    });

上面代码的这种写法，显然非常简洁清晰。

参考：

https://javascript.ruanyifeng.com/nodejs/express.html#toc21

展开全文 >>

react-router的使用

前言

路由库React-Router是由官方维护的，当我们使用react时事实上也是唯一可选的路由库。它通过管理 URL，实现组件的切换和状态的变化，开发复杂的应用几乎肯定会用到。

一、基本用法

React Router 安装命令如下。

1
npm install -S react-router
more >>

展开全文 >>

前端工程化的理解

前端工程化

首先工程这个概念是工业领域的用词，前端工程化的这个概念提出说明前端项目已经发展到了一定的阶段，随便来个前端项目都不是随便拼几个页面，搞几个jq插件就能完成，前端已经不能抛开工程化来独立开发了，如react的jsx代码必须编译后才能在浏览器中使用，又如sass和less的代码浏览器也是不支持的。前端领域在扩大，pc h5 混合开发 node 等等，技术也不断更新，前端业务日益复杂化和多元化，就必须要有工程化的技术和思想来解决前端的业务问题。

比如，如何高效多人协作？如何保证项目的性能，稳定性，可用性，可维护性？如何提高项目的开发质量？这些都是工程化需要关注的问题。

工程化是一种思想，没有什么范式来参考，凡是有利于前端项目的可用性，可维护，可扩展的方法我觉得都属于前端工程化。工程化的目的无非就是三点：流程化、规范化、自动化。比如说，js，css的模块化，组件化开发。比如使用更友好的es6语法，ts的使用，可复用的打包编译方案，固话可移植的优化方案，再比如使用代理工具提升开发效率，项目配置sonar或者eslint代码审查工具，再有就是搭建合适的前端监控和日志系统，注重数据埋点和后评估，以及合理的前端单元测试和前端开发规范，敏捷开发，git工作流，持续集成，上线部署都是工程化需要解决和关注的问题。

实现前端工程化需要从哪些角度考虑

1.构建工具
2.持续集成
3.系统测试
4.日志统计
5.上线部署
6.敏捷开发
7.性能优化
8.基础框架

组件化

可组合（Composeable）：一个组件易于和其它组件一起使用，或者嵌套在另一个组件内部。如果一个组件内部创建了另一个组件，那么说父组件拥有（own）它创建的子组件，通过这个特性，一个复杂的 UI 可以拆分成多个简单的 UI 组件；
可重用（Reusable）：每个组件都是具有独立功能的，它可以被使用在多个 UI 场景；
可维护（Maintainable）：每个小的组件仅仅包含自身的逻辑，更容易被理解和维护；
可测试（Testable）：因为每个组件都是独立的，那么对于各个组件分别测试显然要比对于整个 UI 进行测试容易的多。

展开全文 >>

react-redux源码分析

前言

redux作为大型应用的状态管理工具，如果想配合react使用，需要借助react-redux。
redux主要完成两件事情：

  • 负责应用的状态管理，保证单向数据流
  • 当应用状态发生变化，触发监听器。

那么，如果想要将react和redux搭配使用，就需要react组件可以根据redux中所存储的状态（store）更新view。
并且可以改变store。其实react-redux主要就是完成了这两件事情。

第一，通过将store传入root组件的context，使子节点可以获取到state。
第二，通过store.subscribe订阅store的变化，更新组件。

另外还有对于性能的优化，减少不必要的渲染。

react-redux使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
import React from 'react';
import ReactDOM from 'react-dom';
import PropTypes from 'prop-types';
import { createStore } from 'redux';
import { Provider, connect } from 'react-redux';

const reducer = (state, action) => {
    if (action.type === 'add') {
        return {
            ...state,
            count: state.count + 1,
        }
    }
    return state;
};

const store = createStore(reducer, { count: 1 });

const mapStateToProps = (state) => {
    return ({
        count: state.count,
    });
};

const mapDispatchToProps = dispatch => ({
    add: () => dispatch({ type: 'add' }),
});

const mergeProps = (state, props) =>({
    countStr: `计数: ${state.count}`,
    ...props,
});

const options = {
    pure: true,
};

class App extends React.Component {
    render() {
        return (
            <div>
                <p>{this.props.countStr}</p>
                <button onClick={this.props.add}>点击+1</button>
            </div>
        )
    }
}

// @connect
const AppContainer = connect(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    options,
)(App);

ReactDOM.render(
    <Provider store={store}>
        <AppContainer />
    </Provider>,
    document.getElementById('root')
);

Provider： 接收从redux而来的store，以供子组件使用。
connect： 高阶组件，当组件需要获取或者想要改变store的时候使用。可以接受四个参数：

- mapStateToProps：取store数据，传递给组件。
- mapDispatchToProps：改变store数据。
- mergeProps：可以在其中对 mapStateToProps， mapDispatchToProps的结果进一步处理
- options：一些配置项，例如 pure.当设置为true时，会避免不必要的渲染

React-Redux的源码目录结构

├── components
│ ├── Provider.js
│ └── connectAdvanced.js
├── connect
│ ├── connect.js
│ ├── mapDispatchToProps.js
│ ├── mapStateToProps.js
│ ├── mergeProps.js
│ ├── selectorFactory.js
│ ├── verifySubselectors.js
│ └── wrapMapToProps.js
├── index.js
└── utils
├── PropTypes.js
├── Subscription.js
├── shallowEqual.js
├── verifyPlainObject.js
├── warning.js
└── wrapActionCreators.js

源码解读

基于react-redux 5.0.6

入口

首先来看一下index.js:

1
2
3
4
5
import Provider, { createProvider } from './components/Provider'
import connectAdvanced from './components/connectAdvanced'
import connect from './connect/connect'

export { Provider, createProvider, connectAdvanced, connect }

对外提供的API有四个:Provider、createProvider,connectAdvanced,connect

Provider部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Provider extends Component {
    getChildContext() {
        return { [storeKey]: this[storeKey], [subscriptionKey]: null }
    }

    constructor(props, context) {
        super(props, context)
        this[storeKey] = props.store;
    }

    render() {
        return Children.only(this.props.children)
    }
}

Provider组件写了3个方法，getChildContext、constructor、render。目的是使用context向下传递store。将store注入整个React应用的某个入口组件，通常是应用的顶层组件。

constructor是构造方法，this.store = props.store中的this表示当前的组件。在构造函数定义this.store的作用是为了能够在getChildContext方法中读取到store。

getChildContext方法，翻译过来就是上下文。作用是返回store。

render渲染，返回一个react子元素。Children.only是react提供的方法，this.props.children表示的是只有一个root的元素。

Connect部分

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
export function createConnect({
    connectHOC = connectAdvanced,
    mapStateToPropsFactories = defaultMapStateToPropsFactories,
    mapDispatchToPropsFactories = defaultMapDispatchToPropsFactories,
    mergePropsFactories = defaultMergePropsFactories,
    selectorFactory = defaultSelectorFactory
} = {}) {
    return function connect(
        mapStateToProps,
        mapDispatchToProps,
        mergeProps,
        {
            pure = true,
            areStatesEqual = strictEqual,
            areOwnPropsEqual = shallowEqual,
            areStatePropsEqual = shallowEqual,
            areMergedPropsEqual = shallowEqual,
            ...extraOptions
        } = {}
    ) {
        // 封装了传入的mapStateToProps等函数，这里可以先理解为 initMapStateToProps = () => mapStateToProps 这种形式
        const initMapStateToProps = match(mapStateToProps, mapStateToPropsFactories, 'mapStateToProps')
        const initMapDispatchToProps = match(mapDispatchToProps, mapDispatchToPropsFactories, 'mapDispatchToProps')
        const initMergeProps = match(mergeProps, mergePropsFactories, 'mergeProps')

        // 选择器（selector）的作用就是计算mapStateToProps，mapDispatchToProps, ownProps（来自父组件的props）的结果，
        // 并将结果传给子组件props。这就是为什么你在mapStateToProps等三个函数中写的结果，子组件可以通过this.props拿到。
        // 选择器工厂函数（selectorFactory）作用就是创建selector
        return connectHOC(selectorFactory, {
            // used in error messages
            methodName: 'connect',

            // used to compute Connect's displayName from the wrapped component's displayName.
            getDisplayName: name => `Connect(${name})`,

            // if mapStateToProps is falsy, the Connect component doesn't subscribe to store state changes
            shouldHandleStateChanges: Boolean(mapStateToProps),

            // passed through to selectorFactory
            initMapStateToProps,
            initMapDispatchToProps,
            initMergeProps,
            pure,
            areStatesEqual,
            areOwnPropsEqual,
            areStatePropsEqual,
            areMergedPropsEqual,

            // any extra options args can override defaults of connect or connectAdvanced
            ...extraOptions
        })
    }
}

export default createConnect()

connect是对connectHOC(connectAdvanced)的封装，connectAdvanced使用了defaultSelectorFactory，来创建selector。
react-redux默认的selectorFactory中包含了很多性能优化的部分

connectHOC(connectAdvanced)

connectAdvanced位于src / components / connectAdvanced.js，说明作者把它看做更接近于组件相关，它是Connect的基础。

connectAdvanced的签名如下

1
(selectorFactory, options) => WrappedComponent => HoistedComponent

用语言描述就是，connectAdvanced这个方法接受一个selectorFactory方法和一个配置对象，返回一个HOC方法，这个方法接收一个组件参数，并定义了一个叫Connect的组件，然后通过hoist-non-react-statics这个库，把WrappedComponent里面的非React的静态属性方法复制给Connect组件并返回。

selectorFactory部分

在解读selectorFactory代码之前，先说一下options.pure的作用。在开头的例子有一个配置项pure。作用是减少运算优化性能。当设置为false时，react-redux将不会优化，store.subscirbe事件触发，组件就会渲染，即使是没有用到的state更新，也会这样，举个例子

1
2
3
4
5
6
7
8
9
10
11
12
// 大家都知道reducer的写法
return {
    ...state,
    count: state.count + 1,
}

// 必须返回一个新对象，那么如果我只是修改原来state比如
state.count += 1;
return state;
// 你会发现组件将不会渲染，其实store里的值是发生变化的。
// 这时如果你非想这么写， 然后又想重新渲染怎么办？
// 就是将pure设置为false，这样组件就会完全实时更新。

看下selectorFactory.js finalPropsSelectorFactory作为最终导出的代码

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
export default function finalPropsSelectorFactory(dispatch, {
    initMapStateToProps,
    initMapDispatchToProps,
    initMergeProps,
    ...options
}) {
    const mapStateToProps = initMapStateToProps(dispatch, options)
    const mapDispatchToProps = initMapDispatchToProps(dispatch, options)
    const mergeProps = initMergeProps(dispatch, options)

    if (process.env.NODE_ENV !== 'production') {
        verifySubselectors(mapStateToProps, mapDispatchToProps, mergeProps, options.displayName)
    }

    const selectorFactory = options.pure
        ? pureFinalPropsSelectorFactory
        : impureFinalPropsSelectorFactory

    return selectorFactory(
        mapStateToProps,
        mapDispatchToProps,
        mergeProps,
        dispatch,
        options
    )
}

这里很好理解，是对selectorFactory的封装，根据options.pure的值，选取不同的SelectorFactory;

impureFinalPropsSelectorFactory

先来看看简单的impureFinalPropsSelectorFactory，无脑计算返回新值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
export function impureFinalPropsSelectorFactory(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    dispatch
) {
    return function impureFinalPropsSelector(state, ownProps) {
        return mergeProps(
            mapStateToProps(state, ownProps),
            mapDispatchToProps(dispatch, ownProps),
            ownProps
        )
    }
}
pureFinalPropsSelectorFactory

在需要的时候才执行mapStateToProps，mapDispatchToProps，mergeProps

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
export function pureFinalPropsSelectorFactory(
    mapStateToProps,
    mapDispatchToProps,
    mergeProps,
    dispatch,
    { areStatesEqual, areOwnPropsEqual, areStatePropsEqual }
) {
    let hasRunAtLeastOnce = false
    let state
    let ownProps
    let stateProps
    let dispatchProps
    let mergedProps

    function handleFirstCall(firstState, firstOwnProps) {
        state = firstState
        ownProps = firstOwnProps
        stateProps = mapStateToProps(state, ownProps)
        dispatchProps = mapDispatchToProps(dispatch, ownProps)
        mergedProps = mergeProps(stateProps, dispatchProps, ownProps)
        hasRunAtLeastOnce = true
        return mergedProps
    }

    function handleNewPropsAndNewState() {
        stateProps = mapStateToProps(state, ownProps)

        if (mapDispatchToProps.dependsOnOwnProps)
            dispatchProps = mapDispatchToProps(dispatch, ownProps)

        mergedProps = mergeProps(stateProps, dispatchProps, ownProps)
        return mergedProps
    }

    function handleNewProps() {
        if (mapStateToProps.dependsOnOwnProps)
            stateProps = mapStateToProps(state, ownProps)

        if (mapDispatchToProps.dependsOnOwnProps)
            dispatchProps = mapDispatchToProps(dispatch, ownProps)

        mergedProps = mergeProps(stateProps, dispatchProps, ownProps)
        return mergedProps
    }

    function handleNewState() {
        const nextStateProps = mapStateToProps(state, ownProps)
        const statePropsChanged = !areStatePropsEqual(nextStateProps, stateProps)
        stateProps = nextStateProps

        if (statePropsChanged)
            mergedProps = mergeProps(stateProps, dispatchProps, ownProps)

        return mergedProps
    }

    function handleSubsequentCalls(nextState, nextOwnProps) {
        const propsChanged = !areOwnPropsEqual(nextOwnProps, ownProps)
        const stateChanged = !areStatesEqual(nextState, state)
        state = nextState
        ownProps = nextOwnProps

        if (propsChanged && stateChanged) return handleNewPropsAndNewState()
        if (propsChanged) return handleNewProps()
        if (stateChanged) return handleNewState()
        return mergedProps
    }

    return function pureFinalPropsSelector(nextState, nextOwnProps) {
        return hasRunAtLeastOnce
            ? handleSubsequentCalls(nextState, nextOwnProps)
            : handleFirstCall(nextState, nextOwnProps)
    }
}

分两种情况：

  • 当第一次运行时，执行 handleFirstCall，将三个map函数运行一遍，并将结果缓存下来
  • 之后运行 handleSubsequentCalls，在其中将新的值和缓存的值做比较，如果变化，将重新求值并返回，如果没变化，返回缓存的旧值。

其中 mapFunction.dependsOnOwnProps 代表你传入的mapStateToProps是否使用了ownProps。
如果没有使用，那么props的变化将不会影响结果，换句话说对应的mapFunction将不会执行。
判断方法也很简单，就是获取function形参长度，如何获得呢？

https://juejin.im/post/5b8b5a60e51d4538c411ff12
https://github.com/reduxjs/react-redux/blob/v5.0.6/src/components/Provider.js
https://juejin.im/post/59eb25e651882549fc512bb7

展开全文 >>

React和Vue区别对比

React和Vue区别

1）设计思想

vue的官网中说它是一款渐进式框架，采用自底向上增量开发的设计。
react主张函数式编程，所以推崇纯组件，数据不可变，单向数据流，当然需要双向的地方也可以手动实现，
比如借助 onChange 和 setState 来实现一个双向的数据流。

more >>

展开全文 >>

前后端同构和SSR服务端渲染

前言

在前端页面的渲染这块，近几年来感觉经历了从服务端渲染(多页面)=>客户端渲染(SPA)=>同构渲染的演变，同构渲染是15年左右React火了一段时间后提出的概念（也差不多是《三体》那个时候），原文是 Isomorphic rendering，但是很快就有人驳斥不应该用 Isomorphic 这个词，而应该用 Universal Rendering。

提前列举一下术语：

1、前端渲染：浏览器一侧使用js，借助模版或vue、react、angular等框架做的DOM结构生成（首屏展示出来时，必然是 render.js 通过网络请求完毕，然后加上 JavaScript 执行完成之后的。）

2、后端渲染：服务器一侧，使用php、jsp、velocity、nodejs等技术实现DOM结构生成，并在HTTP请求中返回给浏览器（好处是转化 HTML 到 DOM，浏览器原生会比 JavaScript 生成 DOM 的时间短；省去了 SPA 中 JavaScript 的请求与编译执行时间）

3、同构渲染：简单来说就是一份代码，服务端先通过服务端渲染(server-side rendering，下称ssr)，生成html以及初始化数据，客户端拿到html和初始化数据后，通过对html的dom进行patch和事件绑定对dom进行客户端激活(client-side hydration，下称csh)，这个整体的过程叫同构渲染。其实就是满足三个条件：1)同一份代码 2)ssr 3)csh

Q. 问题来了，同构渲染和php,jsp的渲染有什么不同，同构渲染称得上ssr吗？

既然同构渲染就是一份代码ssr加csh，那么ssr部分本质上跟php，jsp也是一样，也就是模版引擎出来html字符串，但是同构要求能通过一份代码实现ssr，csh，同时服务端需要提供一份初始化数据以便csh，而且传统php，jsp不关注csh过程。

Q. 同构渲染能解决首屏加载和seo的问题吗？

其实解决这两个问题，是ssr来解决的，csh解决的只是交互问题。既然文件已经交由服务端渲染完，展示的速度肯定是提升的(因为不需要等待客户端渲染)，同样seo蜘蛛一般是分析服务端出来的html的，那么没有ssr的spa客户端等同于无法seo(当然一些蜘蛛也会提供spa的方案)，同构包括ssr，当然可以解决seo的问题

但解决归解决，不一定能很好解决。毕竟这几个其实不是同样的问题。就像我个人觉得ssr来实现seo本身就是个伪需求，同理首屏加载问题也是。

seo其实还能通过预渲染或者通过ua判断让蜘蛛走headless chrome渲染来解决。另外首屏加载速度问题的解决方案就更多了。

比较前后端还是属于不同环境，同构考验开发人员对大局观的考虑，约束了特定环境的一些开发灵活性，同时也影响代码解耦。ssr抛开这两点好处，甚至没有找到任何优点。所以这是当前前后端同构不温不火的重要原因

同构的历史背景

  • Web开发的历程是很有趣的，最初php、asp的年代，一切内容都是服务器渲染的；
  • 后来为了节省服务器资源，也更大限度利用客户端缓存，又出现了前后端分离的模式，从而有了专业的前端开发和后台开发。此时Web的特点是，js和html放到静态目录或者CDN，并以ajax方式获取后台的数据，在前端进行DOM组装。这种开发方式沿用至今，这是一个好的工作模式，专业的人做专业的事，确实有利于工作效率提高。引领SPA时代到来，但是JavaScirpt给我们带来的无刷新体验和组件化带来的开发效率的同时，白屏和SEO问题也随之而来。
  • 随着nodejs的流行，前端jser们又开始蠢蠢欲动，尝试吞并web接入这个后台的前沿地盘，把后台推到更后。大概2014年后，又出现了很多nodejs直出的方案，把页面数据都一次在HTML的请求中返回，无需浏览器端再发起ajax获取数据，而且服务器端把DOM结构都渲染好，拿到初始化数据给浏览器，浏览器得到html和初始数据进行patch和事件绑定对客户端激活。不得不说，这个方案带来了很多好处：既解决了白屏和 SEO 问题，又继承了SPA无刷新的用户体验和开发的组件化带来的效率。首屏速度更快，浏览器更省电。当然，随之而来的，就是更复杂的工作模式，jser需要做服务器端的逻辑，甚至一些代码需要同时用在浏览器和nodejs上。同构应运而生。

同构

百度搜一下前后端同构，清一色的vue、react。这些确实是同构，但我认为范围太窄，同构不是框架带来的问题，而是因为前后端独立渲染这种架构层面带来的问题

SSR核心原理

整体来说服务端渲染原理不复杂，其中最核心的内容就是同构。

1)node server 接收客户端请求，得到当前的req url path
2)然后在已有的路由表内查找到对应的组件，拿到需要请求的数据，将数据作为 props
、context或者store 形式传入组件
3)然后基于react内置的服务端渲染api renderToString() or renderToNodeStream() 把组件渲染为 html字符串或者 stream 流, 在把最终的html进行输出前需要将数据注入到浏览器端(注水)，
4)server 输出(response)后浏览器端可以得到数据(脱水)，浏览器开始进行渲染和节点对比，然后执行组件的componentDidMount完成组件内事件绑定和一些交互，浏览器重用了服务端输出的 html 节点，整个流程结束。

核心原理

同构之道

如何从实际项目需求的角度来看，找出自己所需的同构之道

同构，是为了提高用户体验的同时，提高团队的工作效率。接下来，我想根据项目的类型，说说自己的看法。

第一种，单页面应用

这个网站很类似一个APP，确实很有必要做成单页应用，有助于提高用户体验。
如果第一步选择了单页面应用，这里就衍生了另外的问题——SEO。而react等框架做了服务器渲染，最大目的其实也是解决SEO。
既然浏览器端选择了某个框架，例如React，而同时又考虑nodejs直出提高首屏的速度，那么就没有讨价还价的余地了，当然上react全家桶，前后端都用react。

第二种，多页面纯数据展示，每一页都比较简单，没有分屏的必要

如果项目是这样的情况，使用nodejs直出，无非就是提高打开速度。而前后端基本八竿子打不着，最多就是一些工具函数（转换一下日期格式，输入框校验）要做复用。

此时，没必要大费周折去考虑什么框架，因地制宜，想想自己需要什么即可。

要解决函数库的前后端复用，可以简单做commonjs/window的兼容。

如果浏览器端的代码比较多，就可以考虑粒度化，使用webpack做浏览器端代码打包，同时commonjs的写法也可以复用到nodejs层。

第三种，多页面而且每一页不是那么简单，首屏和次屏有一些HTML片段（模版）需要复用

用webpack做前端打包，这样前端各种代码和后台代码都是commonjs风格，可以二合一。而且发布前打包为一个大js文件，也省去nodejs每次请求动态合并js的消耗。
html模版发布前先做预编译，从html+模版语法，转为纯js代码，随着webpack打包到浏览器端大js文件中。
后端和前端都用到的代码，基于commonjs，尽可能的抽离封装。
最终合并的浏览器端大js还是动态合并到首屏HTML中。

引入了webpack到浏览器端，就能很好的解决了原先html模版传播的尴尬。而模块风格的统一，也有利于前后端代码更好的复用。

至于最终浏览器js是否打包到首屏HTML中，还是单独的部署CDN，这个其实就不是同构的问题了。不过对于移动端而言，还是建议合并在一起。

抽象一下，对于第三种项目情况，跳出我原先的项目。我认为，关键是要把前后端使用的模版统一为一个方式引入。

第四种，还是多页面，浏览器端没有模版拼装的需求，第三种情况的变种

或者说，这个不是一个单独的项目情况，只是因为用的技术方案不同。跟第三种情况一样，但次屏的渲染，我们不在浏览器端执行，而是继续交给nodejs。浏览器端通过ajax把次屏html片段拉取回来，然后直接塞到body中。而且，除此之外，浏览器端没有用户交互会导致已有的DOM发生重绘，或者极少内容重绘，不需要动用到模版。

在这个情况下，浏览器端js更纯粹的只关注事件处理。

我觉得这个又回到了第二种情况，只需要简单把一些库函数封装一下，做成前后端共用即可。

第四种情况，因为彻底抛弃了浏览器渲染，整个情况就简单多了，不需要考虑模版和很多逻辑js的前后端复用问题。

思考

上帝为了我们开了一扇窗，同时也会为我们关上一扇门。

我们所知的传统型 SPA，单页面应用，贴近用户端越近，交互越复杂，它的弊端就越明显，在我们享受 JavaScirpt 给我们带来的无刷新体验和组件化带来的开发效率的同时，『白屏』这个随着 SPA 各种优点随之而来的缺点被遗忘，我们拥有菊花方案在 JavaScript 没有将 DOM 构建好之前蒙层，或者是骨架屏方案让用户提前感知页面结构，拥有白屏监控方案将真实用户数据上报改进，但并没有触碰到白屏问题的本质，那就是『DOM 的构建者是 JavaScript，而非原生的浏览器』。

同构的到来既解决了白屏和 SEO 问题，又继承了SPA无刷新的用户体验和开发的组件化带来的效率。但是面临更大的挑战。

参考：
https://juejin.im/post/5c821dc45188257e1f2915b1
https://segmentfault.com/a/1190000016722457
https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics?hl=zh-cn
https://juejin.im/post/5d7deef6e51d453bb13b66cd#heading-5

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

Lozoe，<br>毕业于大连皇家民族学院，目前就职于驼厂<br><br>热爱大海与冷笑话，<br/>目前是一枚前端<br/><br/>爱生活，爱健身，爱编码<br>年轻无为，卖马为生。