Node.js垃圾回收与内存管理

2020-03-17

前言

使用JavaScript进行前端开发时几乎完全不需要关心内存管理问题，对于前端编程来说，V8限制的内存几乎不会出现用完的情况，但是由于后端程序往往进行的操作更加复杂，并且长期运行在服务器不重启，如果不关注内存管理，导致内存泄漏，就算1GB，也会很快用尽。

垃圾回收器是一把十足的双刃剑。其好处是可以大幅简化程序的内存管理代码，因为内存管理无需程序员来操作，由此也减少了（但没有根除）长时间运转的程序的内存泄漏。对于某些程序员来说，它甚至能够提升代码的性能。另一方面，选择垃圾回收器也就意味着程序当中无法完全掌控内存，而这正是移动终端开发的症结。对于JavaScript，程序中没有任何内存管理的可能——ECMAScript标准中没有暴露任何垃圾回收器的接口。网页应用既没有办法管理内存，也没办法给垃圾回收器进行提示。

Node.js构建于Chrome V8引擎之上，因此本文首先讲解V8引擎的内存管理机制，了解底层原理后，再讲解Node开发中的内存管理与优化。

nodeJs查看垃圾回收日志的方式主要是在启动时添加 –trace_gc 参数。

more >>

展开全文 >>

css单位

2020-03-17

一、px，em，rem、vw、vh、pt

1.px (pixel，像素)

是一个虚拟长度单位，是计算机系统的数字化图像长度单位，如果px要换算成物理长度，需要指定精度DPI(Dots Per Inch，每英寸像素数)，在扫描打印时一般都有DPI可选。Windows系统默认是96dpi，Apple系统默认是72dpi。px 单位的值必须是整数值.

与px相关的一些单位

in - 表示英寸，是一个物理单位，在CSS中被直接映射成为px; 转换的方法是 1in = 96px

cm - 表示厘米，在生活中常用的单位，同样被映射为 px; 转换方法为 1cm = 37.8px

mm - 表示毫米，与cm类似，转换方法为 1mm = 0.1cm = 3.78px

2.em(相对长度单位，相对于当前对象内文本的字体尺寸)

是一个相对长度单位，指的是字符宽度的倍数，用法类似百分比，如：0.8em, 1.2em,2em等。通常1em=16px。

3.rem(root em，根em)

rem是一个相对单位，1rem等于html元素上字体设置的大小。我们只要设置html上font-size的大小，就可以改变rem所代表的大小。这样我们就有了一个可控的统一参考系。我们现在有两个目标：rem单位所代表的尺寸大小和屏幕宽度成正比，也就是设置html元素的font-size和屏幕宽度成正比rem单位和px单位很容易进行换算，方便我们按照标注稿写css

rem与em的区别

rem是相对于根元素（html）的字体大小

em是相对于其父元素的字体大小em最多取到小数点的后三位

4.vw、vh

css3中引入了一个新的单位vw/vh，与视图窗口有关，vw表示相对于视图窗口的宽度，vh表示相对于视图窗口高度，除了vw和vh外，还有vmin和vmax两个相关的单位。

各个单位具体的含义如下：单位含义vw相对于视窗的宽度，视窗宽度是100vwvh相对于视窗的高度，视窗高度是100vhvminvw和vh中的较小值vmax vw和vh中的较大值这里我们发现视窗宽高都是100vw／100vh，那么vw或者vh，下简称vw，很类似百分比单位。

vw和%的区别为：
%大部分相对于祖先元素，也有相对于自身的情况比如（border-radius、translate等)
vw/vh相对于视窗的尺寸

5.pt （点）

绝对长度单位，多用于字体尺寸，1px = 0.75pt

in:寸

cm:厘米

mm:毫米

q: 1/4毫米（quarter-millimeters）。绝对长度单位。

pt:point，大约1/72寸

pc:pica，大约6pt，1/6寸

1in = 2.54cm = 25.4mm = 101.6q = 72pt = 6pc = 96px

6.%

一般宽泛的讲是相对于父元素，但是并不是十分准确。

1、对于普通定位元素就是我们理解的父元素

2、对于position: absolute;的元素是相对于已定位的父元素

3、对于position: fixed;的元素是相对于 ViewPort（可视窗口）

展开全文 >>

CSS之BFC、IFC、GFC和FFC

2020-03-17

CSS2.1中只有BFC和IFC, CSS3中才有GFC和FFC。

What’s FC

FC的全称是：Formatting Contexts，是W3C CSS2.1规范中的一个概念。它是页面中的一块渲染区域，并且有一套渲染规则，它决定了其子元素将如何定位，以及和其他元素的关系和相互作用。

BFC

BFC(Block Formatting Contexts)块级格式化上下文。Block Formatting Contexts就是页面上的一个隔离的渲染区域，容器里面的子元素不会在布局上影响到外面的元素，反之也是如此。

如何产生BFC

float的值不为none。
overflow的值不为visible。
position的值不为relative和static。
display的值为table-cell, table-caption, inline-block中的任何一个。

那BFC一般有什么用呢

IFC

IFC(Inline Formatting Contexts)内联格式化上下文，IFC的line box（线框）高度由其包含行内元素中最高的实际高度计算而来（不受到竖直方向的padding/margin影响)
IFC中的line box一般左右都贴紧整个IFC，但是会因为float元素而扰乱。float元素会位于IFC与与line box之间，使得line box宽度缩短。同个ifc下的多个line box高度会不同。 IFC中时不可能有块级元素的，当插入块级元素时（如p中插入div）会产生两个匿名块与div分隔开，即产生两个IFC，每个IFC对外表现为块级元素，与div垂直排列。

那么IFC一般有什么用呢

水平居中：当一个块要在环境中水平居中时，设置其为inline-block则会在外层产生IFC，通过text-align则可以使其水平居中。
垂直居中：创建一个IFC，用其中一个元素撑开父元素的高度，然后设置其vertical-align: middle，其他行内元素则可以在此父元素下垂直居中。

GFC

GFC(GridLayout Formatting Contexts)网格布局格式化上下文，当为一个元素设置display值为grid的时候，此元素将会获得一个独立的渲染区域，我们可以通过在网格容器（grid container）上定义网格定义行（grid definition rows）和网格定义列（grid definition columns）属性各在网格项目（grid item）上定义网格行（grid row）和网格列（grid columns）为每一个网格项目（grid item）定义位置和空间。

GFC作用

和table又有什么区别呢？首先同样是一个二维的表格，但GridLayout会有更加丰富的属性来控制行列，控制对齐以及更为精细的渲染语义和控制。

FFC

FFC(Flex Formatting Contexts)自适应格式化上下文，display值为flex或者inline-flex的元素将会生成自适应容器（flex container），可惜这个牛逼的属性只有谷歌和火狐支持，不过在移动端也足够了，至少safari和chrome还是OK的，毕竟这俩在移动端才是王道。

Flex Box 由伸缩容器和伸缩项目组成。通过设置元素的 display 属性为 flex 或 inline-flex 可以得到一个伸缩容器。设置为 flex 的容器被渲染为一个块级元素，而设置为 inline-flex 的容器则渲染为一个行内元素。
伸缩容器中的每一个子元素都是一个伸缩项目。伸缩项目可以是任意数量的。伸缩容器外和伸缩项目内的一切元素都不受影响。简单地说，Flexbox 定义了伸缩容器内伸缩项目该如何布局

展开全文 >>

http1.0和http1.1以及http2.0区别

2020-03-11

http1.0与http1.1的区别

1)缓存处理，在http1.0 Expires,Last-Modified/If-Modified-Since，HTTP1.1增加Cache-Control、Etag、If-None-Match等更多可供选择的缓存头来控制缓存策略。

2)带宽优化及网络连接的使用，http1.0存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

3)错误通知的管理，在http1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

4)Host头处理，在http1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

通用头域:

Cache-Control: 缓存头域 => 常见值为no-cache(不允许缓存), no-store(无论请求还是响应均不允许缓存), max-age(规定可以客户端可以接受多长生命期的数据)
Keep-Alive: 使得服务端和客户端的链接长时间有效
Date: 信息发送的时间
Host: 请求资源的主机IP和端口号
Range: 请求资源的某一部分
User-Agent: 发出请求的用户的信息(鉴权)

5)长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

http2.0和http1.x的区别

1）http1的解析是基于文本协议的格式解析,而http2.0的协议解析是二进制格式,更加的强大

2）多路复用(Mutiplexing) : 一个连接上可以有多个request,且可以随机的混在一起,每个不同的request都有对应的id,服务端可以通过request_id来辨别,大大加快了传输速率

3）header压缩: http1.x中的header需要携带大量信息.而且每次都要重复发送.http2.0使用encode来减少传输的header大小.而且客户端和服务端可以各自缓存(cache)一份header filed表,避免了header的重复传输,还可以减少传输的大小.

4）服务端推送(server push): 可以通过解析html中的依赖,只能的返回所需的其他文件(css或者js等),而不用再发起一次请求.

http vs https

http：超文本传输协议（HyperText Transfer Protocol）是用于从服务器传输超文本到本地浏览器的传输协议。可以使浏览器更加高效。以明文发送信息，若黑客截取了浏览器和服务器之间的传输报文，就可以直接获得其中的信息。
https: 超文本传输安全协议(Hypertext Transfer Protocol Secure) 是一种通过计算机网络进行安全通信的传输协议。
https经由http进行通信，但利用SSL/TLS来加密数据包。
https开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

简而言之: https是在http上建立ssl加密层，并对传输数据进行加密，是http协议的安全版。

简言之区别如下：

http 是明文传输，HTTPS 通过 SSL\TLS 进行了加密
http 的端口号是 80，HTTPS 是 443
https 需要到 CA 申请证书，一般免费证书很少，需要交费
http 的连接简单，无状态；https 协议是由http+SSL/TLS 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

展开全文 >>

对MVC、MVP、MVVM的理解

2020-03-08

MVC

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

more >>

展开全文 >>

redux、koa、express 中间件源码解读

2020-03-06

express 和 koa 的中间件是用于处理 http 请求和响应的，但是二者的设计思路确不尽相同。大部分人了解的express和koa的中间件差异在于：

express采用尾递归方式，中间件一个接一个的顺序执行, 习惯于将response响应写在最后一个中间件中；
而koa的中间件支持 generator, 执行顺序是“洋葱圈”模型。

所谓的“洋葱圈”模型:

onion-model

不过实际上，express 的中间件也可以形成“洋葱圈”模型，在 next 调用后写的代码同样会执行到，不过express中一般不会这么做，因为 express的response一般在最后一个中间件，那么其它中间件 next() 后的代码已经影响不到最终响应结果了;

express

入口

首先看一下 express 的实现：

// express.js

var proto = require('./application');
var mixin = require('merge-descriptors');

exports = module.exports = createApplication;

function createApplication() {
    // app 同时是一个方法，作为http.createServer的处理函数
    var app = function(req, res, next) {
        app.handle(req, res, next);
    }

    mixin(app, proto, false);
    return app;
}

这里其实很简单，就是一个 createApplication 方法用于创建 express 实例，要注意返回值 app 既是实例对象，上面挂载了很多方法，同时它本身也是一个方法，作为 http.createServer的处理函数, 具体代码在 application.js 中：

// application.js
var http = require('http');
var flatten = require('array-flatten');
var app = exports = module.exports = {}

app.listen = function listen() {
  var server = http.createServer(this)
  return server.listen.apply(server, arguments)
}

这里 app.listen 调用 nodejs 的http.createServer 创建web服务，可以看到这里 var server = http.createServer(this) 其中 this 即 app 本身, 然后真正的处理程序即 app.handle;

中间件处理 - express

express 本质上就是一个中间件管理器，当进入到 app.handle 的时候就是对中间件进行执行的时候，所以，最关键的两个函数就是：

app.handle 尾递归调用中间件处理 req 和 res
app.use 添加中间件

全局维护一个stack数组用来存储所有中间件，app.use 的实现就很简单了，可以就是一行代码

// app.use
app.use = function(fn) {
    this.stack.push(fn);
}

express 的真正实现当然不会这么简单，它内置实现了路由功能，其中有 router, route, layer 三个关键的类，有了 router 就要对 path 进行分流，stack 中保存的是 layer实例，app.use 方法实际调用的是 router 实例的 use 方法, 有兴趣的可以自行去阅读。

app.handle 即对 stack 数组进行处理

app.handle = function(req, res, callback) {
    var stack = this.stack;
    var idx = 0;
    function next(err) {
        if (idx >= stack.length) {
            callback('err');
            return;
        }
        var mid;
        while(idx < stack.length) {
            mid = stack[idx++];
            mid(req, res, next);
        }
    }
    next();
}

这里就是所谓的”尾递归调用”，next 方法不断的取出stack中的“中间件”函数进行调用，同时把next 本身传递给“中间件”作为第三个参数，每个中间件约定的固定形式为 (req, res, next) => {}, 这样每个“中间件“函数中只要调用 next 方法即可传递调用下一个中间件。

之所以说是”尾递归“是因为递归函数的最后一条语句是调用函数本身，所以每一个中间件的最后一条语句需要是next()才能形成尾递归，否则就是普通递归，尾递归相对于普通递归的好处在于节省内存空间，不会形成深度嵌套的函数调用栈。

至此，express 的中间件实现就完成了。

koa

不得不说，相比较 express 而言，koa 的整体设计和代码实现显得更高级，更精炼；代码基于ES6 实现，支持generator(async await), 没有内置的路由实现和任何内置中间件，context 的设计也很是巧妙。

入口及目录

一共只有4个文件：

application.js 入口文件，koa应用实例的类
context.js ctx 实例，代理了很多request和response的属性和方法，作为全局对象传递
request.js koa 对原生 req 对象的封装
response.js koa 对原生 res 对象的封装

request.js 和 response.js 没什么可说的，任何 web 框架都会提供req和res 的封装来简化处理。所以主要看一下 context.js 和 application.js的实现

// context.js
/**
 * Response delegation.
 */

delegate(proto, 'res')
  .method('setHeader')

/**
 * Request delegation.
 */

delegate(proto, 'req')
  .access('url')
  .setter('href')
  .getter('ip');

context 就是这类代码，主要功能就是在做代理，使用了 delegate 库。

简单说一下这里代理的含义，比如delegate(proto, ‘res’).method(‘setHeader’) 这条语句的作用就是：当调用proto.setHeader时，会调用proto.res.setHeader 即，将proto的 setHeader方法代理到proto的res属性上，其它类似。

// application.js 中部分代码

constructor() {
    super()
    this.middleware = []
    this.context = Object.create(context)
}

use(fn) {
    this.middleware.push(fn)
}

listen(...args) {
    debug('listen')
    const server = http.createServer(this.callback());
    return server.listen(...args);
}

callback() {
    // 这里即中间件处理代码
    const fn = compose(this.middleware);

    const handleRequest = (req, res) => {
        // ctx 是koa的精髓之一, req, res上的很多方法代理到了ctx上, 基于 ctx 很多问题处理更加方便
        const ctx = this.createContext(req, res);
        return this.handleRequest(ctx, fn);
    };

    return handleRequest;
}

handleRequest(ctx, fnMiddleware) {
    ctx.statusCode = 404;
    const onerror = err => ctx.onerror(err);
    const handleResponse = () => respond(ctx);
    return fnMiddleware(ctx).then(handleResponse).catch(onerror);
}

同样的在listen方法中创建 web 服务, 没有使用 express 那么绕的方式，const server = http.createServer(this.callback()); 用this.callback()生成 web 服务的处理程序

中间件处理 - koa

构造函数 constructor 中维护全局中间件数组 this.middleware和全局的this.context 实例（源码中还有request，response对象和一些其他辅助属性）。和 express 不同，因为没有router的实现，所有this.middleware 中就是普通的”中间件“函数而非复杂的 layer 实例，
this.handleRequest(ctx, fn); 中 ctx 为第一个参数，fn = compose(this.middleware) 作为第二个参数, handleRequest 会调用 fnMiddleware(ctx).then(handleResponse).catch(onerror); 所以中间处理的关键在compose方法, 它是一个独立的包koa-compose, 把它拿了出来看一下里面的内容：

// compose.js
'use strict'
module.exports = compose
function compose (middleware) {
  return function (context, next) {
    let index = -1
    return dispatch(0)
    function dispatch (i) {
      index = i
      let fn = middleware[i]
      if (i === middleware.length) fn = next
      if (!fn) return Promise.resolve()
      try {
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
      } catch (err) {
        return Promise.reject(err)
      }
    }
  }
}

和express中的next 是不是很像，只不过他是promise形式的，因为要支持异步，所以理解起来就稍微麻烦点：每个中间件是一个async (ctx, next) => {}, 执行后返回的是一个promise, 第二个参数 next的值为 dispatch.bind(null, i + 1) , 用于传递”中间件“的执行，一个个中间件向里执行，直到最后一个中间件执行完，resolve 掉，它前一个”中间件“接着执行 await next() 后的代码，然后 resolve 掉，在不断向前直到第一个”中间件“ resolve掉，最终使得最外层的promise resolve掉。

这里和express很不同的一点就是koa的响应的处理并不在”中间件”中，而是在中间件执行完返回的promise resolve后：

1	return fnMiddleware(ctx).then(handleResponse).catch(onerror);

通过 handleResponse 最后对响应做处理，中间件会设置ctx.body, handleResponse也会主要处理 ctx.body ，所以 koa 的”洋葱圈“模型才会成立，await next()后的代码也会影响到最后的响应。

至此，koa的中间件实现就完成了。

redux

入口及目录 - redux

本文还是主要看一下它的中间件实现, 先简单说一下 redux 的核心处理逻辑, createStore 是其入口程序，工厂方法，返回一个 store 实例，store实例的最关键的方法就是 dispatch , 而 dispatch 要做的就是一件事：

1	currentState = currentReducer(currentState, action);

即调用reducer, 传入当前state和action返回新的state。

所以要模拟基本的 redux 执行只要实现 createStore , dispatch 方法即可。其它的内容如 bindActionCreators, combineReducers 以及 subscribe 监听都是辅助使用的功能，可以暂时不关注。

中间件处理 - redux

然后就到了核心的”中间件” 实现部分即 applyMiddleware.js：

// applyMiddleware.js

import compose from './compose'

export default function applyMiddleware(...middlewares) {
  return createStore => (...args) => {
    const store = createStore(...args)
    let dispatch = () => {
      throw new Error(
        `Dispatching while constructing your middleware is not allowed. ` +
          `Other middleware would not be applied to this dispatch.`
      )
    }

    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    }
    const chain = middlewares.map(middleware => middleware(middlewareAPI))
    dispatch = compose(...chain)(store.dispatch)

    return {
      ...store,
      dispatch
    }
  }
}

redux 中间件提供的扩展是在 action 发起之后，到达 reducer 之前，它的实现思路就和express 、 koa 有些不同了，它没有通过封装 store.dispatch, 在它前面添加中间件处理程序，而是通过递归覆写 dispatch ，不断的传递上一个覆写的 dispatch 来实现。

每一个 redux 中间件的形式为 store => next => action => { xxx }

这里主要有两层函数嵌套：

最外层函数接收参数store, 对应于 applyMiddleware.js 中的处理代码是 const chain = middlewares.map(middleware => middleware(middlewareAPI)), middlewareAPI 即为传入的store 。这一层是为了把 store 的 api 传递给中间件使用，主要就是两个api:

getState, 直接传递store.getState.
dispatch: (…args) => dispatch(…args)，这里的实现就很巧妙了，并不是store.dispatch, 而是一个外部的变量dispatch, 这个变量最终指向的是覆写后的dispatch, 这样做的原因在于，对于 redux-thunk 这样的异步中间件，内部调用store.dispatch 的时候仍然后走一遍所有“中间件”。

返回的chain就是第二层的数组，数组的每个元素都是这样一个函数next => action => { xxx }, 这个函数可以理解为接受一个dispatch返回一个dispatch, 接受的dispatch 是后一个中间件返回的dispatch.

还有一个关键函数即 compose, 主要作用是 compose(f, g, h) 返回 () => f(g(h(..args)))

现在在来理解 dispatch = compose(...chain)(store.dispatch) 就相对容易了，原生的 store.dispatch 传入最后一个“中间件”，返回一个新的 dispatch , 再向外传递到前一个中间件，直至返回最终的 dispatch, 当覆写后的dispatch 调用时，每个“中间件“的执行又是从外向内的”洋葱圈“模型。

至此，redux中间件就完成了。

参考：

尾调用：http://www.ruanyifeng.com/blog/2015/04/tail-call.html
redux: https://redux.js.org/advanced/middleware/

展开全文 >>

“数字签名与https”

2020-03-05

参考：
https://www.cnblogs.com/rinack/p/10743355.html
https://github.com/nanjixiong218/analys-middlewares

展开全文 >>

CSRF

2020-03-05

CSRF基本概念

CSRF，通常称为跨站请求伪造，英文名Cross-site request forgery

more >>

展开全文 >>

redux

2020-03-02

设计思想

（1）Web 应用是一个状态机，视图与状态是一一对应的。
（2）所有的状态，保存在一个对象里面。

三大原则

1. 单一数据源
2. 状态是只读的
3. 状态修改均由纯函数完成

基本概念

Store

Store 就是保存数据的地方，你可以把它看成一个容器。整个应用只能有一个 Store。
Redux 提供createStore这个函数，用来生成 Store。

1 2	import { createStore } from 'redux'; const store = createStore(fn);

上面代码中，createStore函数接受另一个函数作为参数，返回新生成的 Store 对象。

State

Store对象包含所有数据。如果想得到某个时点的数据，就要对 Store 生成快照。这种时点的数据集合，就叫做 State。
当前时刻的 State，可以通过store.getState()拿到。

1
2
3

import { createStore } from 'redux';
const store = createStore(fn);
const state = store.getState();

Redux 规定，一个 State 对应一个 View。只要 State 相同，View 就相同。你知道 State，就知道 View 是什么样，反之亦然。

Action

State 的变化，会导致 View 的变化。但是，用户接触不到 State，只能接触到 View。所以，State 的变化必须是 View 导致的。Action 就是 View 发出的通知，表示 State 应该要发生变化了。
Action 是一个对象。其中的type属性是必须的，表示 Action 的名称。其他属性可以自由设置，社区有一个规范可以参考。

const action = {
  type: 'ADD_TODO',
  payload: 'Learn Redux'
};

上面代码中，Action 的名称是ADD_TODO，它携带的信息是字符串Learn Redux。
可以这样理解，Action 描述当前发生的事情。改变 State 的唯一办法，就是使用 Action。它会运送数据到 Store。

Action Creator

View 要发送多少种消息，就会有多少种 Action。如果都手写，会很麻烦。可以定义一个函数来生成 Action，这个函数就叫 Action Creator。

const ADD_TODO = '添加 TODO';

function addTodo(text) {
  return {
    type: ADD_TODO,
    text
  }
}
const action = addTodo('Learn Redux');

上面代码中，addTodo函数就是一个 Action Creator。

store.dispatch()

store.dispatch()是 View 发出 Action 的唯一方法。

import { createStore } from 'redux';
const store = createStore(fn);
store.dispatch({
  type: 'ADD_TODO',
  payload: 'Learn Redux'
});

上面代码中，store.dispatch接受一个 Action 对象作为参数，将它发送出去。
结合 Action Creator，这段代码可以改写如下。

1	store.dispatch(addTodo('Learn Redux'));

Reducer

Store 收到 Action 以后，必须给出一个新的 State，这样 View 才会发生变化。这种 State 的计算过程就叫做 Reducer。
Reducer 是一个函数，它接受 Action 和当前 State 作为参数，返回一个新的 State。

const reducer = function (state, action) {
  // ...
  return new_state;
};

整个应用的初始状态，可以作为 State 的默认值。下面是一个实际的例子。

const defaultState = 0;
const reducer = (state = defaultState, action) => {
  switch (action.type) {
    case 'ADD':
      return state + action.payload;
    default: 
      return state;
  }
};
const state = reducer(1, {
  type: 'ADD',
  payload: 2
});

上面代码中，reducer函数收到名为ADD的 Action 以后，就返回一个新的 State，作为加法的计算结果。其他运算的逻辑（比如减法），也可以根据 Action 的不同来实现。
实际应用中，Reducer 函数不用像上面这样手动调用，store.dispatch方法会触发 Reducer 的自动执行。为此，Store 需要知道 Reducer 函数，做法就是在生成 Store 的时候，将 Reducer 传入createStore方法。

1 2	import { createStore } from 'redux'; const store = createStore(reducer);

纯函数

Reducer 函数最重要的特征是，它是一个纯函数。也就是说，只要是同样的输入，必定得到同样的输出。

纯函数是函数式编程的概念，必须遵守以下一些约束。

不得改写参数
不能调用系统 I/O 的API
不能调用Date.now()或者Math.random()等不纯的方法，因为每次会得到不一样的结果

由于 Reducer 是纯函数，就可以保证同样的State，必定得到同样的 View。但也正因为这一点，==Reducer 函数里面不能改变 State，必须返回一个全新的对象==，请参考下面的写法。

// State 是一个对象
function reducer(state, action) {
  return Object.assign({}, state, { thingToChange });
  // 或者
  return { ...state, ...newState };
}

// State 是一个数组
function reducer(state, action) {
  return [...state, newItem];
}

最好把 State 对象设成只读。你没法改变它，要得到新的 State，唯一办法就是生成一个新对象。这样的好处是，任何时候，与某个 View 对应的 State 总是一个不变的对象。

Store 允许使用store.subscribe方法设置监听函数，一旦 State 发生变化，就自动执行这个函数。

import { createStore } from 'redux';
const store = createStore(reducer);

store.subscribe(listener);

显然，只要把 View 的更新函数（对于 React 项目，就是组件的render方法或setState方法）放入listen，就会实现 View 的自动渲染。

store.subscribe方法返回一个函数，调用这个函数就可以解除监听。

let unsubscribe = store.subscribe(() =>
  console.log(store.getState())
);

unsubscribe();

Store 的实现

了解Redux 涉及的基本概念后，可以发现 Store 提供了三个方法。

- [ ] store.getState()
- [ ] store.dispatch()
- [ ] store.subscribe()

1 2	import { createStore } from 'redux'; let { subscribe, dispatch, getState } = createStore(reducer);

createStore方法还可以接受第二个参数，表示 State 的最初状态。这通常是服务器给出的。

1	let store = createStore(todoApp, window.STATE_FROM_SERVER)

上面代码中，window.STATE_FROM_SERVER就是整个应用的状态初始值。注意，如果提供了这个参数，它会覆盖 Reducer 函数的默认初始值。
createStore方法的一个简单实现

const createStore = (reducer) => {
  let state;
  let listeners = [];

  const getState = () => state;

  const dispatch = (action) => {
    state = reducer(state, action);
    listeners.forEach(listener => listener());
  };

  const subscribe = (listener) => {
    listeners.push(listener);
    return () => {
      listeners = listeners.filter(l => l !== listener);
    }
  };

  dispatch({});

  return { getState, dispatch, subscribe };
};

Reducer 的拆分

Reducer 函数负责生成 State。由于整个应用只有一个 State 对象，包含所有数据，对于大型应用来说，这个 State 必然十分庞大，导致 Reducer 函数也十分庞大。

请看下面的例子。

const chatReducer = (state = defaultState, action = {}) => {
  const { type, payload } = action;
  switch (type) {
    case ADD_CHAT:
      return Object.assign({}, state, {
        chatLog: state.chatLog.concat(payload)
      });
    case CHANGE_STATUS:
      return Object.assign({}, state, {
        statusMessage: payload
      });
    case CHANGE_USERNAME:
      return Object.assign({}, state, {
        userName: payload
      });
    default: return state;
  }
};

上面代码中，三种 Action 分别改变 State 的三个属性。

- [ ] ADD_CHAT：chatLog属性
- [ ] CHANGE_STATUS：statusMessage属性
- [ ] CHANGE_USERNAME：userName属性

这三个属性之间没有联系，这提示我们可以把 Reducer 函数拆分。不同的函数负责处理不同属性，最终把它们合并成一个大的 Reducer 即可。

const chatReducer = (state = defaultState, action = {}) => {
  return {
    chatLog: chatLog(state.chatLog, action),
    statusMessage: statusMessage(state.statusMessage, action),
    userName: userName(state.userName, action)
  }
};

上面代码中，Reducer 函数被拆成了三个小函数，每一个负责生成对应的属性。

这样一拆，Reducer 就易读易写多了。而且，这种拆分与 React 应用的结构相吻合：一个 React 根组件由很多子组件构成。这就是说，子组件与子 Reducer 完全可以对应。

Redux 提供了一个combineReducers方法，用于 Reducer 的拆分。你只要定义各个子 Reducer 函数，然后用这个方法，将它们合成一个大的 Reducer。

const reducer = combineReducers({
  a: doSomethingWithA,
  b: processB,
  c: c
})

// 等同于
function reducer(state = {}, action) {
  return {
    a: doSomethingWithA(state.a, action),
    b: processB(state.b, action),
    c: c(state.c, action)
  }
}

总之，combineReducers()做的就是产生一个整体的 Reducer 函数。该函数根据 State 的 key 去执行相应的子 Reducer，并将返回结果合并成一个大的 State 对象。

下面是combineReducer的简单实现。

const combineReducers = reducers => {
  return (state = {}, action) => {
    return Object.keys(reducers).reduce(
      (nextState, key) => {
        nextState[key] = reducers[key](state[key], action);
        return nextState;
      },
      {} 
    );
  };
};

你可以把所有子 Reducer 放在一个文件里面，然后统一引入。

import { combineReducers } from 'redux'
import * as reducers from './reducers'

const reducer = combineReducers(reducers)

参考：
http://www.ruanyifeng.com/blog/2016/09/redux_tutorial_part_one_basic_usages.html
Redux 异步流最佳实践 - 前端 - 掘金

#fe/framework/react

展开全文 >>

vuex数据流向

2020-03-02

vuex基础

https://vuex.vuejs.org/zh-cn

多组件共享状态，之前操作方式，由父组件传递到各个子组件。当路由等加入后，会变得复杂。引入viewx 解决共享问题。

原vue结构图

vue结构图

vuex结构图

Vuex对象结构（state，mutations，getters，actions）

state 对象数据
mutations 操作变更state数据
getters 计算state
actions 触发mutations

vuex解析图优化

参考：
https://www.cnblogs.com/reeber/p/10628935.html

展开全文 >>