天地玄黄，宇宙洪荒

前端开发，重要的就是 2 个（类）文件：

• index.html
• 静态资源：js & css

一个一站式的前端开发框架，要做的就是定义、构建、使用以上文件，其中

• 「定义」是静态的，是描述式的
• 「构建」和「使用」是运行时的
• 由于 webpack 的普遍使用，「定义」的一大部分工作就是围绕 webpack 进行；「构建」和本地开发服务器的运行，也都是依赖 webpack

具体到 umi 框架，使用精巧的插件体系，把上述操作更加语义化以及细化

• 从纵向看，就是使用插件对 index.html 文件和 webpack files 进行配置
  • webpack files 是一大堆文件：webpack config / webpackrc / entry.js / router.js / etc
• 从横向看，就是执行命令，并且通过 apply 插件得到定制过的相关文件、配置作为 webpack 的输入

再搜索 umi 源码，可以看到更精细的插件 hook 点

• html 相关
  • modifyHTML
• webpack 相关
  • modifyWebpackConfig
  • modifyAFWebpackOpts
  • modifyEntryFile
  • router 相关
    • modifyRouterFile
    • modifyRouteComponent
    • modifyRoutes

以上这几个 hook 都是比较「纯粹」的，看名字就知道了：「modify」

还有一些 hook 点就不那么 pure 了，比如：generateFiles
作用是生成 DvaContainer.js 文件，直接就写到 writeSync 了
（为啥不搞成 pure hook 呢？可以的）

还有一些 hook 点是和运行时的生命周期挂钩的，看命名也就知道了

• beforeServerWithApp
• onStart
• beforeDevAsync
• beforeGenerateHTML
• buildSuccess（为啥不叫 onBuildSuccess ???）
• etc

关于 umi 命令生命周期如图所示：
传送门🚁：umijs/umi#87

然后，插件就可以选取自己需要的 hook 点进行配置，以 umi-plugin-dva 插件为例：

chenni:umi-plugin-dva/ (master✗) $ grep -rn 'api.register' *                                         [12:28:58]
lib/index.js:210:  api.register('generateFiles', () => {
lib/index.js:226:  api.register('modifyRouterFile', ({
lib/index.js:241:  api.register('modifyRouteComponent', ({
lib/index.js:273:  api.register('modifyEntryFile', ({
lib/index.js:285:  api.register('modifyAFWebpackOpts', ({
lib/index.js:298:  api.register('modifyPageWatchers', ({
src/index.js:178:  api.register('generateFiles', () => {
src/index.js:201:  api.register('modifyRouterFile', ({ memo }) => {
src/index.js:222:  api.register('modifyRouteComponent', ({ memo, args }) => {
src/index.js:255:  api.register('modifyEntryFile', ({ memo }) => {
src/index.js:269:  api.register('modifyAFWebpackOpts', ({ memo }) => {
src/index.js:285:  api.register('modifyPageWatchers', ({ memo }) => {

所以，最后再总结一下：

• umi 使用插件体系进行框架的配置和使用
• 从纵向看，是静态的，通过插件配置各种 hook 点，定义 index 文件、webpack 配置、生命周期 hook
  • 纯配置类 hook，modifyXXX
  • 生命周期类 hook，on/before/afterXXX
  • 其他不纯洁的 hook😅
• 从横向看，是运行时的，加载需要的插件，在生命周期的各个点读取和执行 hook

ref:

• umi as a Compiler: https://hackmd.io/s/ByGeBtv9z

未完待续（代码走读：插件的加载和执行）

本文记录了 rc-menu 中对于溢出菜单项自动收起的实现，由于之前踩了挺多坑，特此记录，希望温故能知新。

问题：

水平菜单在空间不足时能够自动将剩余部分收起

思路：

rc-menu 本身自带 submenu 功能，所以通过计算 scrollWidth 和 width 之间的差距来找出所有需要收起的菜单项，将它们统一收进一个构造出的 submenu item, 这样理论上能通过最少的代码变更优雅地实现这个功能。

踩坑1.0

当计算得出所有需要收起的菜单项之后，�需要解决一个问题，那就是如何隐藏原有的菜单项目。这里给出两种可能的尝试。

使用 visibility: 'hidden':

  renderChildren(children) {
    // lastVisibleIndex 为最后一个可见的菜单项 index
    const { lastVisibleIndex } = this.state;
    return React.Children.map(children, (childNode, index) => {
        if (lastVisibleIndex !== undefined) {
          if (index <= lastVisibleIndex) {
            // 菜单项可见，直接渲染
            return childNode;
          } else if (index === lastVisibleIndex + 1) {
            // 第一个被隐藏的项目，在这个位置渲染构造出的自动收起的菜单项
            return this.getOverflowedSubMenuItem();
          } else {
            // 隐藏菜单项
            return React.cloneElement(
                childNode,
                // 1. 我们需要显示隐藏菜单项，因为第一个被隐藏的菜单项可能会部分可见，
                // 而且无法被自动收起的占位菜单项全部遮盖
                // 2. 考虑不不用 display: 'none'，因为在后续的 resize 过程中,
                // 我们还需要能够获得所有菜单项的 scrollWidth 来重新计算是否需要
                // 在某个位置渲染自动收起的占位菜单项。
                { style: { visibility: 'hidden' } },
              );
          }
        }
    });

坑：同 key 导致被隐藏元素也会被触发菜单开启

如下图所示，因为溢出菜单项只是被隐藏起来，但是元素还是在 dom，而 ... 占位的菜单项中的元素是根据原来的元素克隆而出，而 rc-menu 使用 eventKey 作为真正的 key，克隆过程中 eventKey 没有改变，导致被克隆元素跟原有元素同 key, 所以如果一个子菜单被打开时，被隐藏的菜单项中的子菜单也会被激活。

在不明白问题的本质时，所以决定与其简单的隐藏，不如直接选择不去渲染剩下的元素，这样就不会碰到上述问题。至于所需要用来参照的元素宽度值，只要在每次需要计算的时候在页面的某个地方单独渲染菜单并记录所有元素的大小，这样就可以拿到所有元素原始的正确尺寸。

  renderChildren(children) {
    // lastVisibleIndex 为最后一个可见的菜单项 index
    const { lastVisibleIndex } = this.state;
    return React.Children.map(children, (childNode, index) => {
        if (lastVisibleIndex !== undefined) {
          if (index <= lastVisibleIndex) {
            // 菜单项可见，直接渲染
            return childNode;
          } else if (index === lastVisibleIndex + 1) {
            // 第一个被隐藏的项目，在这个位置渲染构造出的自动收起的菜单项
            return this.getOverflowedSubMenuItem();
          } else {
            // 隐藏菜单项不再渲染
            return null; 
          }
        }
        return childNode;
    });
  }

// 当需要重新计算菜单溢出收起时, memorize rendered menuSize
  setChildrenSize() {

    const container = document.body.appendChild(document.createElement('div'));
    container.setAttribute('style', 'position: absolute; top: 0; visibility: hidden');

    this.store = create({
      selectedKeys: [],
      openKeys: [],
      activeKey: {},
    });

    ReactDOM.render(
      <Provider store={this.store}>
        <Tag {...rest}>{children}</Tag>
      </Provider>, // content

      container, // container

      () => { // callback
        const ul = container.childNodes[0];
        const scrollWidth = getScrollWidth(ul);

        this.props.children.forEach((c, i) => this.childrenSizes[i] = getWidth(ul.children[i]));

        this.originalScrollWidth = scrollWidth;

        ReactDOM.unmountComponentAtNode(container);
        document.body.removeChild(container);
        this.handleResize();
      });
  }

坑：不能随意在外部进行 React.Render

rc-menu 的元素不可以这样随意提出，因为用户代码可能依赖各种个样的 Provider，比如 rc-menu 常常被用作导航头，所以碰到需要 router 作为 provider 的情况下，这里就会挂掉

正确的做法：

其实为了解决第一个坑，用踩第二个坑的做法是完全没有必要的。这里只需要改变被隐藏元素的 render key 就好了。

  renderChildren(children) {
    // lastVisibleIndex 为最后一个可见的菜单项 index
    const { lastVisibleIndex } = this.state;
    return React.Children.map(children, (childNode, index) => {
        if (lastVisibleIndex !== undefined) {
          if (index <= lastVisibleIndex) {
            // 菜单项可见，直接渲染
            return childNode;
          } else if (index === lastVisibleIndex + 1) {
            // 第一个被隐藏的项目，在这个位置渲染构造出的自动收起的菜单项
            return this.getOverflowedSubMenuItem();
          } else {
            // 隐藏菜单项
            return React.cloneElement(
                childNode,
                // 这里修改 eventKey 是为了防止隐藏状态下还会触发 openkeys 事件
                { style: { visibility: 'hidden' }, eventKey: `${childNode.props.eventKey}-hidden` },
              );
          }
        }
    });
  }

踩坑2.0

对于子元素发生变化的情况，溢出自动收起也需要重新计算。导航头文字在不同语言环境下的切换就是最常见的例子。最简单直观的实现方式：

  componentDidUpdate(prevProps) {
    if (prevProps.children !== this.props.children
      || prevProps.overflowedIndicator !== this.props.overflowedIndicator
    ) {
// 检查更新并且重新计算溢出自动收起占位符的位置。
      this.updateNodesCacheAndResize();
    }
  }

坑：重新挂载导致的组件闪动

在 ant-design 的 demo 页面，因为某种原因，在打开收起菜单中的子菜单时，会看到子菜单闪动，用户只是想打开子菜单，但是竟然看到了内部子菜单的闪动。也就是说在这个过程中子菜单重新挂载了。这是为什么呢？两个问题：

• 因为用户代码的实现方式，打开子菜单的操作触发了 menu 自上而下的更新，这时候 componentDidUpdate 被激发了，而且因为是从 menu 自上而下的更新，children 的引用发生变化，因此出现了不必要的重新计算。
• 上面我们避免了在外面单独渲染菜单的方式，但是在采用正确的方式之前，还踩过一个坑，为了每次都可以获得原始的菜单尺寸，而且避免渲染被隐藏的菜单，所以每次更新过程中，选择了先正常渲染菜单一遍，获得所有元素正确的原始宽度之后，再进行溢出收起的渲染逻辑：

renderChildren(children) {
    // 每次 componentWillReceiveProps 里，
    // 将 lastVisibleIndex 初始值置成 undefined 
    const { lastVisibleIndex } = this.state;
    return React.Children.map(children, (childNode, index) => {
        // 在 componentDidUpdate 里根据上一轮获得的原始菜单大小
        // 重新计算 lastVisibleIndex，然后执行下面 if 中的逻辑
        if (lastVisibleIndex !== undefined) {
          if (index <= lastVisibleIndex) {
            // 菜单项可见，直接渲染
            return childNode;
          } else if (index === lastVisibleIndex + 1) {
            // 第一个被隐藏的项目，在这个位置渲染构造出的自动收起的菜单项
            return this.getOverflowedSubMenuItem();
          } else {
            // 隐藏菜单项不再渲染
            return null; 
          }
        } else {
          // 第一轮 lastVisibleIndex 为 undefined
          // 正常渲染菜单
          return childNode;
        }
    });
}

这样每次自上而下发生 componentDidUpdate 之后，其实元素在这个 if else 过程中发生了重新挂载。

正确的做法：MutationObserver + ResizeObserver

使用 MutationObserver + ResizeObserver 而不是简单的在 componentDidUpdate 中比较 children 引用。MutationObserver 用于监听子元素个数发生变化的情况，而 ResizeObserver 用来监听菜单项宽度发生变化的情况，这样回调函数的执行才是精准高效的，这解决第一个问题。

  componentDidMount() {
    const menuUl = ReactDOM.findDOMNode(this);
    if (!menuUl) {
        return;
    }
    this.resizeObserver = new ResizeObserver(entries => {
        entries.forEach(this.setChildrenWidthAndResize);
    });
    
    [].slice.call(menuUl.children).concat(menuUl).forEach(el => {
        this.resizeObserver.observe(el);
    });

    this.mutationObserver = new MutationObserver(() => {
      this.resizeObserver.disconnect();
      [].slice.call(menuUl.children).concat(menuUl).forEach(el => {
        this.resizeObserver.observe(el);
      });
      this.setChildrenWidthAndResize();
    });

    this.mutationObserver.observe(
      menuUl,
      { attributes: false, childList: true, subTree: false }
    );
 }

对于第二个问题，如何避免二次渲染并且能够

• 先获得更新的原始菜单项的大小
• 根据原始菜单的大小重新计算自动收起占位符

其实有了 MuationObserver + ResizeObserver 我们也避免了上述问题。因为本质上我们不再依赖 componentDidUpdate 这样的 react 生命周期函数，而是依赖原生的 js 事件，这样在回调函数中，重新计算菜单项的大小，然后 setState({ lastVisibleIndex }) 即可。

踩坑3.0

第三个坑是关于在正确的位置渲染溢出菜单项自动收起占位符的。最简单直观的方式是在菜单子元素末端渲染溢出占位符，然后用相对定位的方式来改变其在菜单项中的位置。

坑：不可随意修改 position 类型

rc-menu 作为 antd 的基类库，在许多地方都被用到。menu 一直是以 position: static 的方式存在的，冒然将 menu 的 position 改为 relative，会导致已有代码出现各种个样的 bug。

正确的做法：保持 position: static + 冗余占位符

千万不敢随意改动 position 的类型，尤其是对于最基础的基类组件库而言。如果尝试在渲染过程中将溢出占位符动态地插入原来的菜单子元素序列，那么可能造成其他的问题，比如重新计算位置信息的时候，需要用很多 if 语句去判断菜单的子元素是不是菜单项的原生子元素还是占位符；而且可能导致不必要的元素重新挂载。这里一个比较巧妙优雅的做法是，给每个菜单项后面都加一个占位符元素，正常情况下不显示，当需要的时候再显示。

  renderChildren(children) {
    // need to take care of overflowed items in horizontal mode
    const { lastVisibleIndex } = this.state;
    return (children || []).reduce((acc, childNode, index) => {
        let item = childNode;
        let overflowed = this.getOverflowedSubMenuItem(childNode.props.eventKey, []);
        if (lastVisibleIndex !== undefined
            &&
            this.props.className.indexOf(`${this.props.prefixCls}-root`) !== -1
        ) {
          if (index > lastVisibleIndex) {
            item = React.cloneElement(
              childNode,
              // 这里修改 eventKey 是为了防止隐藏状态下还会触发 openkeys 事件
              { style: { visibility: 'hidden' }, eventKey: `${childNode.props.eventKey}-hidden` },
            );
          }
          if (index === lastVisibleIndex + 1) {
            this.overflowedItems = children.slice(lastVisibleIndex + 1).map(c => {
              return React.cloneElement(
                c,
                // children[index].key will become '.$key' in clone by default,
                // we have to overwrite with the correct key explicitly
                { key: c.props.eventKey, mode: 'vertical-left' },
              );
            });
    
            overflowed = this.getOverflowedSubMenuItem(
              childNode.props.eventKey,
              this.overflowedItems,
            );
          }
        }
    
        const ret = [...acc, overflowed, item];
    
        if (index === children.length - 1) {
          // need a placeholder for calculating overflowed indicator width
          ret.push(this.getOverflowedSubMenuItem(childNode.props.eventKey, [], true));
        }
        return ret;
    }, []);
  }

最后再总结一下踩过的坑和得到的经验教训。

• react 中许多怪异的问题都跟 key 有关。本文中因为克隆元素后元素同 key 结果导致行为协同
• 使用 React.Render 时应当警醒，是否会缺失潜在的必要 Provider
• 要敬畏每一次 render, 尤其要知道 render 中的 if else 引起的元素重新挂载
• 学会使用 MuationObserver 和 ResizerObserver， 事半功倍！
• 要敬畏 position 类型，随意将 position: static 改为 relative 可能会很多潜在问题。
• 有时候冗余元素也是很好的解法！

感兴趣的同学可以查看 懵逼跌坑里 和 学乖爬起来后 的代码实现区别。

1. 异步任务

我从具体的项目中分离出了一个有趣的问题，可以描述如下：

页面上有一个按钮，每次点击它，都会发送一个ajax请求，
并且，用户可以在ajax返回之前点击它。

现在我们要实现一个功能，
以按钮的点击顺序展示ajax的响应结果。

2. 准备活动

为了以后编码的方便，先将ajax请求mock一下，

let count = 0;

// 模拟ajax请求，以随机时间返回一个比之前大一的自然数
const mockAjax = async () => {
    console.warn('send ajax');
    await new Promise((res, rej) => setTimeout(() => res(++count), Math.random() * 3000));
    console.warn('ajax return');
    return count;
};

然后，假设按钮的id为sendAjax，

<input id="sendAjax" type="button" value="Click" />

3. 冷静再冷静

document.querySelector('#sendAjax').addEventListener('click', async () => {
    const result = await mockAjax();
    console.log(result);
});

一开始，我们可能会想到这样的办法。
可惜，这是有问题的。

因为click事件，可能会在后面async函数还未返回之前，再次触发。
导致前一个请求还未返回，后面又发起了新请求。

其次，我们可能还会想到，记录每一个请求的时间戳，将结果排序，
这也是有问题的，因为我们不知道未来还有多少次点击（<- 下文的关键信息），
如果无法拿到所有的结果，那么排序就有困难了。

那怎么办呢？
如果请求还未返回之前，能进行控制就好了。

4. 让我们Lazy一点

于是我想到了把新请求lazy化，放到一个队列中，
如果当前有其他任务在执行，就暂不处理。
否则，如果当前是空闲的，那就把队列中的任务都取出来，依次执行。

const PromiseExecutor = class {
    constructor() {
        // lazy promise队列
        this._queue = [];

        // 一个变量锁，如果当前有正在执行的lazy promise，就等待
        this._isBusy = false;
    }

    each(callback) {
        this._callback = callback;
    }

    // 通过isBusy实现加锁
    // 如果当前有任务正在执行，就返回，否则就按队列中任务的顺序来执行
    add(lazyPromise) {
        this._queue.push(lazyPromise);

        if (this._isBusy) {
            return;
        }

        this._isBusy = true;

        // execute是一个async函数，执行后立即返回，返回一个promise
        // 因此，add可以在execute内的promise resolved之前再次执行
        this.execute();
    };

    async execute() {

        // 按队列中的任务顺序来依次执行
        while (this._queue.length !== 0) {
            const head = this._queue.shift();
            const value = await head();
            this._callback && this._callback(value);
        }

        // 执行完之后，解锁
        this._isBusy = false;
    };
};

以上代码，我用了一个队列和变量锁，对新请求进行了管控。

其中的关键点是execute的异步性，
我们看到add函数在尾部调用了this.execute();，会立即返回。
这样就不会阻塞JavaScript线程，可以多次调用add函数了。

下面我们来看下它的使用方法吧，

const executor = new PromiseExecutor;

document.querySelector('#sendAjax').addEventListener('click', () => {

    // 添加一个lazy promise
    executor.add(() => mockAjax());
});

// 注册回调，该回调会按lazy promise的加入顺序，逐个获取它们resolved的值
executor.each(v => {
    console.log(v);
});

5. 更远一些

上文中有一句话，启发了我，
迫使我从不同的角度重新考虑了这个问题。

我们提到，由于“我们不知道未来还有多少次点击”，所以是无法进行排序的。
因此，我发现这是一个和“无穷流”相关的问题。
即，我们不应该把事件看成回调，而是应该看成流（stream）。

所以，我们可以寻找响应式的方式来解决它。
以下两篇文章可以帮你快速回顾一下响应式编程（Reactive Programming）。
——也称反应式编程 _(:зゝ∠)_

你所不知道的响应式编程
函数响应式流库探秘

好了，下面我们要开始进行响应式编程了。
首先，click事件可以形成一个“点击流”，

const clickStream = cont => document.querySelector('#sendAjax').addEventListener('click', cont);

这里的cont指的是Continuation，可以参考上面提到的第二篇文章。

其次，我们需要将这个“点击流”，变换成最终的“ajax结果流”，
并且保证“ajax结果流”的顺序，与“点击流”的顺序相同。

因此，问题在概念上就被简化了，
事实上，所有的stream连同operator一起，构成了一个Monad。

下面我们来编写operator吧，用来对流进行变换，我们只要记着，
“什么时候调用cont就什么时候把东西放到结果流中”，即可。

const streamWait = function (mapValueToPromise) {
    const stream = this;

    // 使用一个队列和一个变量锁来进行调度
    // 如果当前正在处理，就入队，否则就一次性清空队列
    // 并且在清空的过程中，有了新的任务还可以入队
    const queue = [];
    let isBusy = false;

    return cont => stream(async v => {
        queue.push(() => mapValueToPromise(v));

        // 如果当前正在处理，就返回，不改变结果stream中的值
        if (isBusy) {
            return;
        }

        // 否则就按顺序处理，将每一个任务的返回值放到结果流中
        isBusy = true;
        while (queue.length !== 0) {
            const head = queue.shift();
            const r = await head();
            cont(r);
        }

        // 处理完了以后，恢复空闲状态
        isBusy = false;
    });
};

我们再来看下怎么使用它，是不是更加通俗易懂了呀。

// 点击流
const clickStream = cont => document.querySelector('#sendAjax').addEventListener('click', cont);

// ajax结果流
const responseStream = streamWait.call(clickStream, e => mockAjax());

// 订阅结果流
responseStream(v => console.log(v));

Your mouse is a database. —— Erik Meijer

从 webpack 2 开始，开始有了 tree shaking 这项喜大普奔的技术。当你的代码使用 es6 模块系统时，webpack 可以标记导出了但未使用的 dead code ，并在丑化阶段移除它们，从而减小构建产物体积。

如果你尚未接触过此项技术，建议先阅读官方文档：Tree Shaking，以便有足够的基础阅读接下来的讨论。

如果不做任何处理，tree shaking 并不能非常显著地减小产物体积，原因简而言之，就是 tree shaking 过程中， webpack 无法判断一个模块包是否有副作用，因此即使引入了它但没有使用，webpack 也只能保守地选择保留其代码。

我们通过一个简单的例子来看下这个过程。

新建个简单的 webpack 项目：

// index.js

import { add } from './math';

// 引入了 add，但不使用
// console.log('1 + 1 =', add(1+1));

// math.js

import './big-module';

export function add(a, b) {
  return a + b;
}

export function mines(a, b) {
  return a - b;
}

// big-module.js

console.log('I am a big module');

// webpack.config.js

const path = require('path');
const UglifyJsPlugin = require('uglifyjs-webpack-plugin')

module.exports = {
  entry: './index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },

  devtool: 'none',
  mode: 'none',

  optimization: {
    minimize: true,
    minimizer: [
      new UglifyJsPlugin()
    ],
    namedModules: true,
    usedExports: true,
  }
};

namedModules 可以给 bundle 的模块标上名称，方便调试。
usedExports 可以标记未使用的导出模块，以便在丑化阶段移除它们。

index.js 引用了 math.js ，math.js 又引用了 big-module.js。但 index.js 并未使用 math.js 里的导出方法。按照 tree shaking 的理解，math.add 和 math.mines 方法会被移除。我们观察构建产物 bundle.js 可以验证这一结论：

math.js 里的所有导出方法都被移除了，这就减小了产物体积。但进一步可以发现，移除导出方法后的 math.js 和 big-module.js 其实并没有干任何事情，但仍然进入了产物，为什么不一并移除？其实这是可以理解的：如果单纯 import 了另个模块，webpack 无法判断引入的这个模块是否会产生副作用，比如修改 window 这种行为，所以必须保守地保留下来。

如同刚才的例子，big-module 里要打印一句话。如果仅因为 import 了但没使用而被移除的话，产物在执行的时候，就无法打印这句话了，即“有用的代码被误删”。

有副作用的模块多见于各类 polyfill。它们会修改 window 变量。

如果 tree shaking 彻底一点，把未使用但无副作用的模块一并删除，就能进一步减少产物体积。这个时候便要依赖 sideEffects 优化选项。

我们修改一点刚才的项目代码。

开启 webpack sideEffects：

声明此项目所有模块都无副作用：

重新 build 后，观察构建产物发现，math.js 和 big-module.js 都被移除了，整个 bundle 只剩下 index.js 空壳子：

所以这就是 sideEffects 优化选项的作用：“把未使用但无副作用的模块一并删除”。

正确使用此优化手段的威力巨大：

v4 beta 版时叫 pure module, 后来改成了 sideEffects

-- https://zhuanlan.zhihu.com/p/40052192

简历投递地址: chenglin.mcl#antfin.com

We want you! 让我们一起来创造惊艳的用户体验。

Node.js 工程师

• 工作地点: [杭州]
• 职位要求:
  • 两年以上工作经验，熟悉 Web 应用研发流程，对前端工程化有相关经验优先。
  • 熟练使用 Node.js 研发，有大规模高可用的服务端服务研发经验优先。
  • 有 Java、Python、Ruby、PHP、Go 等服务端研发经验优先。
  • 了解计算机系统原理，基础运维知识，对基础网络、存储、数据库、CDN、多媒体等某一领域有较深入的实践能力优先。
  • 对技术有强烈的进取心，具有良好的沟通能力和团队合作精神、优秀的分析问题和解决问题的能力。
• 工作描述:
  • 负责站点托管、页面渲染、文件存储、对象存储等基础 BaaS 服务。
  • 负责应用研发支撑平台：产品研发平台、CI/CD、质量、研发协同等。
  • 负责 Web 研发解决方案：打造大前端研发基础设施，支撑蚂蚁金服移动端、PC 端 Web 产品研发。
  • 负责基于 Node.js 的服务端应用框架和中间件开发，打造适合蚂蚁金服业务发展的企业级应用框架

前端开发专家

• 工作地点: [杭州]
• 职位要求:
  • 熟练掌握移动端 H5 开发、熟悉主流移动浏览器的技术特点；
  • 熟练运用 JavaScript、HTML5、CSS3等; 熟悉移动端 Web 动效相关高级特性, 如 canvas, CSS3 动画效果等；
  • 熟悉模块化、前端编译和构建工具，熟练运用主流的移动端JS库和开发框架，并深入理解其设计原理，例如：ReactJS、Zepto、AntD等；
  • 能提供完善的 WebApp 和混合 App（JS方向）技术方案，有服务端（ node/java 或其他语言）或 native 移动应用开发经验那就更好了；
  • 对技术有强烈的进取心，具有良好的沟通能力和团队合作精神、优秀的分析问题和解决问题的能力。
• 工作描述:
  • 前端开发——国内最大的第三方支付舞台，参与建设余额宝，基金，保险，花呗，借呗，网商银行等金融业务；
  • 改善体验——2亿用户的体验好不好，前端的作用需要你一同承担，关注用户，持续改进；
  • 前后协作——没有最好的流程，没有最好的开发环境，但有你的加入，我们将一起去完善，一同经历磨练，快速成长；
  • 质量效率——前端代码的效率、性能是你追求的方向，一同创建最适合的前端框架是我们的梦想。

IDE前端研发专家

• 工作地点: [杭州，北京，成都，上海，深圳]
• 职位要求:
  • 大学本科以上学历；三年以上 WEB 前端应用设计和开发经验，熟练掌握 HTML、CSS、JavaScript 和常用 WEB 开发语言，熟悉 React、Vue 或 Angular 等组件者优先；
  • 有nodejs开发经验者优先；
  • 有 WEB IDE 设计开发经验者优先；有 3D 图形（OpenGL WebGL）开发经验者优先；
  • 有一定的产品设计思维，有一定的前端架构设计经验，有较强的工程质量意识；
  • 性格开朗活泼，耐心、细致，有责任心，有较强的团队沟通和协作能力。
• 工作描述:
  • 基于云端的图形IDE研发，在线工具设计和开发，包括 WEB 版的 3D 建模工具、3D 动画设计工具以及导入导出工具等设计和开发，服务端图形解析及管理工作。

更多岗位

• Android客户端工程师[北京，上海，杭州]
• IOT容器工程师（windows) -Electron工程师[杭州]
• IDE前端研发专家[杭州]
• 资深数据研发工程师[杭州]
• 资深数据可视化研发工程师[杭州]
• Node.js技术专家[杭州]
• 产品运营专家[杭州]
• 资深交互设计师/交互设计专家[杭州]
• 高级前端专家[杭州]
• 产品专家-平台型产品[杭州]

前言

CSS 即层叠样式表（Cascading Stylesheet）。Web 开发中采用 CSS 技术，可以有效地控制页面的布局、字体、颜色、背景和其它效果。只需要一些简单的修改，就可以改变网页的外观和格式。

CSS3 是 CSS 的升级版本，这套新标准提供了更加丰富且实用的规范，如：盒子模型、列表模块、超链接方式、语言模块、背景和边框、文字特效、多栏布局等等。今天主要想跟大家分享CSS3 的渐变效果（Gradient）以及阴影（Shadow）和反射（Reflect）效果。

起因是之前看过一个网站叫 A Single Div，里面展示的内容都是只用了一个div + css来实现的。看过之后的感觉，就是惊叹～明明都是前端的同学，为什么别人的CSS这么优秀～


其中所有的实现基本都与background-image和box-shadow这两个属性相关，我的代码详情看这里： SingleDiv，可以自己先撸，撸不出来看网页源代码就可以啦～

background-image

background-image属性为元素设置背景图像。元素的背景占据了元素的全部尺寸，包括内边距和边框，但不包括外边距。默认地，背景图像位于元素的左上角，并在水平和垂直方向上重复。可以根据background-repeat属性来指定图像无限平铺、沿着某个轴（x 轴或 y 轴）平铺，或者根本不平铺，也可以根据background-position属性指定初始背景图像（原图像）放置的位置。

1. Regular-images普通的图片

• 提供普通的图形图片(graphic-image)的URL地址来设置图片背景—格式可以是：.PNG、.SVG、.JPG、.GIF、.WEBP。
• 使用dataURL，将图片数据嵌入到文档中。这种技术的优点是减少了一次HTTP请求，缺点是这种内嵌数据的图片大小比直接指定URL地址更大一些。

2. Gradient-images渐变的图片

详情请移步：css-tricks

3. Setting A Fallback Color

• 设置一个备用的背景颜色，这样的话，假如背景图像不可用，图像加载失败或者浏览器不支持渐变，至少还有一个备用颜色，页面也可获得良好的视觉效果。使用background-color属 性来声明纯色备用背景颜色。使用简写的background属性时，可以将备用纯色写在最后。

4. Multiple Background Images

• 以同时给一个元素指定多个背景图片。
• 写在前面的优先级高一些，显示在上层(像是z-index)。
• 在需要多个图片叠加显示一个完整的背景时，一般将不透明的、重复的图片写在后面，以免遮挡其他图片的显示。

box-shadow

这个属性用于给元素块添加周边阴影效果。

基本语法：{box-shadow:[inset] x-offset y-offset blur-radius spread-radius color}

• inset:投影方式可选，不写的时候默认是外阴影，[insert] 表示内阴影；
• x-offset: X轴偏移量，为正，阴影在右边，为负，阴影在左边；
• y-offset: Y轴偏移量，为正，阴影在底部，为负，阴影在顶部；
• blur-radius: 阴影模糊半径，可选，只能为正值，为0时，表示阴影不具有模糊效果，值越大，阴影的边缘就越模糊；
• spread-radius: 阴影扩展半径，可选，为正，阴影扩展，为负，阴影缩小；
• color： 阴影颜色。
• 多阴影重叠时，最先写的阴影显示在最顶层，blur-radius/spread-radius只有一个值得时候指的是模糊半径，从阴影边界开始向外拓展模糊的距离。

.box-shadow{ 
         box-shadow: -10px 0 10px red,/*左边阴影*/           
                        10px 0 10px yellow,/*右边阴影*/            
                        0 -10px 10px blue,/*顶部阴影*/             
                        0 10px 10px green,/*底部阴影*/              
                        0 0 20px black;/*四周都有黑色阴影*/
}

之前看到一个有意思的文章 前端人工智能？TensorFlow.js 学会游戏通关，使用tensorflow.js训练模型玩google无网页面的彩蛋T-Rex Runner 。看了下代码，恩...果断看不懂。先看下演示效果: Genetic Algorithm - T-Rex Runner，希望大家在读完这篇文章后至少能看懂源码了=。=，原理以后再扯，我也不懂。

实际上之前火爆过的flappy bird早就有多种神经网络或是强化学习的算法试验过了。但还是觉得很有意思，所以拿过来给大家做科普，顺便可以探讨下前端如何结合人工智能，可以做些什么？

Tensorflow.js?

TensorFlow.js 于3 月 30 日谷歌 TenosrFlow 开发者峰会正式发布，核心改编自deeplearn.js，面向JS提供一套可以在浏览器中运行的机器学习库(应该说是API，类似python)。

亮点是可以用WebGL加速，即可以用GPU加速，一般训练机器学习模型非常的消耗计算资源（比如能做机器学习计算的显卡会非常火爆)。

什么是Tensorflow?

• TensorFlow™ 是一个使用数据流图进行数值计算的开放源代码软件库。
• 最初由谷歌大脑团队开发，用于机器学习和深度神经网络的研究
• 但该系统具有很好的通用性，还可以应用于众多其他领域

Tensorflow.js 对我们前端工程师而言有什么优势和意义

• 使用JavaScript，对前端开发者友好。
• 在浏览器中运行ML的新机会，在浏览器中运行的ML意味着从用户的角度来看，不需要安装任何库或驱动程序。只需打开一个网页，程序即可运行
• 自动支持WebGL，并在GPU可用时在后台加速代码
• 在移动端模型可以利用传感器数据，例如陀螺仪或加速度传感器。
• Imagination，虽然现在landing case并不多，但这块想象空间比较大，比如pix2code 根据图片出UI

比如：Sketching Interfaces 从原型到代码

玩起来!

https://js.tensorflow.org/#getting-started

虽然部分demo可能是之前机器学习玩剩下的，但这些例子算是首次在纯浏览器中训练运行。

• 纯浏览器的机器学习钢琴演奏
  https://magenta.tensorflow.org/demos/performance_rnn/index.html

• 实时面部识别，姿势识别（试一下)
  https://storage.googleapis.com/tfjs-models/demos/posenet/camera.html

• Webcam 控制pacman
  https://storage.googleapis.com/tfjs-examples/webcam-transfer-learning/dist/index.html

…

快速开始

官网例子解说，目标是能够看懂t-rex-runner的代码

过程: 给定数据，训练拟合函数，输出模型，根据模型预测给定值的输出

<html>
  <head>
    <!-- Load TensorFlow.js -->
    <script src="https://cdn.jsdelivr.net/npm/@tensorflow/[email protected]"> </script>

    <!-- Place your code in the script tag below. You can also use an external .js file -->
    <script>
      // 线性回归模型(可以理解为线性方程)
      const model = tf.sequential();
      model.add(tf.layers.dense({units: 1, inputShape: [1]}));

      // 设定损失函数为平均方差和，训练算法为随机梯度下降算法sgd
      model.compile({loss: 'meanSquaredError', optimizer: 'sgd'});

      // 训练数据，X轴和y轴
      const xs = tf.tensor2d([1, 2, 3, 4], [4, 1]);
      const ys = tf.tensor2d([1, 3, 5, 7], [4, 1]);

      // 训练数据拟合后，预测新值的输出
      model.fit(xs, ys).then(() => {
        model.predict(tf.tensor2d([5], [1, 1])).print();
      });
    </script>
  </head>

  <body>
  </body>
</html>

核心概念

Tensor 张量

a set of numerical values shaped into an array of one or more dimensions.
将一系列数值切分到数组或多维中

// 2x3 Tensor
const shape = [2, 3]; // 2 rows, 3 columns
const a = tf.tensor([1.0, 2.0, 3.0, 10.0, 20.0, 30.0], shape);
a.print(); // print Tensor values
// Output: [[1 , 2 , 3 ],
//          [10, 20, 30]]

把一个张量想象成一个n维的数组或列表。看到这玩意让我想到了大学线性代数里的向量和矩阵，后来查到还有一个标量。

标量(单独的数，0维)：
x

向量: (可以理解为一维数组)

矩阵: (可以理解为二维数组)

我们可以将标量视为零阶张量，矢量视为一阶张量，那么矩阵就是二阶张量，当然还可以更多阶...

当然对于低阶的张量，tensorflow提供了方便的API来构造:

tf.scalar,  // 标量
tf.tensor1d, // 向量
tf.tensor2d, // 矩阵
tf.tensor3d // 三维数组
tf.tensor4d. // 四维数组

// 比如: 
const c = tf.tensor2d([[1.0, 2.0, 3.0], [10.0, 20.0, 30.0]]);
c.print();
// Output: [[1 , 2 , 3 ],
//          [10, 20, 30]]


// 还有比如
tf.zeros // 全张量初始化为0
tf.ones  // 全张量初始化为1

const zeros = tf.zeros([3, 5]);
// Output: [[0, 0, 0, 0, 0],
//          [0, 0, 0, 0, 0],
//          [0, 0, 0, 0, 0]]

张量一旦创建不可改变，但你可以在他们上做操作生成新的张量。很像React的Immutable.js的**

Variables 变量

变量通过张量初始化，但是值可以改变

const initialValues = tf.zeros([5]);
const biases = tf.variable(initialValues); // initialize biases
biases.print(); // output: [0, 0, 0, 0, 0]

const updatedValues = tf.tensor1d([0, 1, 0, 1, 0]);
biases.assign(updatedValues); // update values of biases
biases.print(); // output: [0, 1, 0, 1, 0]

Operations 操作

张量用于存储数据，操作可以修改这些数据，返回新的张量。用下来像是以张量为基本单位进行的便捷操作，比如:

// 乘方操作
const d = tf.tensor2d([[1.0, 2.0], [3.0, 4.0]]);
const d_squared = d.square();
d_squared.print();
// Output: [[1, 4 ],
//          [9, 16]]

// 张量加减乘法
const e = tf.tensor2d([[1.0, 2.0], [3.0, 4.0]]);
const f = tf.tensor2d([[5.0, 6.0], [7.0, 8.0]]);

const e_plus_f = e.add(f);
e_plus_f.print();
// Output: [[6 , 8 ],
//          [10, 12]]

// 当然还可以链式操作
const sq_sum = e.add(f).square();

模型和层

模型： 给定输入，产生输出，像一个方程。

有的时候方程可能非常复杂，我们只有这些方程的数据，然后需要通过这些数据对这个方程进行拟合（训练），然后给出新的数据，我们就能够通过这个模型进行预测。

from网络: 根据已知数据寻找模型参数的过程就是训练，最终搜索到的映射\hat{f}被称为训练出来的模型

Tensorflow.js 给出了两种创建模型的方式，一种是通过各种操作直接描述模型，比如:

		// 声明标量，方程的常量
      const a = tf.scalar(2); 
      const b = tf.scalar(4);
      const c = tf.scalar(8);
      
		// 因为js没有操作符重载，所以各种操作不是那么直观。
      function predict(input) {
		  // tensor存在GPU内存中，tidy用于清理除了最后返回的张量以外的中间张量，防止内存泄露，另外还有dispose函数用于清除单个张量。
        return tf.tidy(() => {
          // y = a * x ^ 2 + b * x + c
          const x = tf.scalar(input);
          const ax2 = a.mul(x.square());
          const bx = b.mul(x);
          const y = ax2.add(bx).add(c);
          return y;
        })
      }
		
		predict(2).print();
		// 24

第二种方式是使用tf提供的高阶API ，tf.model，用层来构建模型，什么是层？层是深度学习中的一个重要抽象概念，一个普通的神经网络通常由多个层组成，比如输入层，输出层，隐藏层，深度学习为什么深？就是因为隐藏层比较多(大于2）。

例子：

// 不要问我RNN是什么，我也不懂...
const model = tf.sequential(); // 线性模型，每一层的输入依赖于上一层的输出
model.add(
// RNN : 循环神经网络(Recurrent Neural Network) https://zybuluo.com/hanbingtao/note/541458
  tf.layers.simpleRNN({ 
    units: 20,
    recurrentInitializer: 'GlorotNormal',
    inputShape: [80, 4]
  })
);

// SGD: 随机梯度下降算法 https://www.zybuluo.com/hanbingtao/note/448086  暂时也讲不清楚
const optimizer = tf.train.sgd(LEARNING_RATE); // 算法
model.compile({optimizer, loss: 'categoricalCrossentropy'}); // 编译
model.fit({x: data, y: labels)}); // 训练

好吧，如果你一定要知道SGD是啥:

RNN是啥：

我也没看懂…不班门弄斧了…看懂了再讲…

一个Tensorflow的具体例子: 训练拟合曲线（官方教程)

https://js.tensorflow.org/tutorials/fit-curve.html 快速开始教程（拟合线性方程）的进阶版本，教程都可以在官网找到，了解核心概念后看这些代码应该能大概看懂了。

代码示例:
https://github.com/tensorflow/tfjs-examples/tree/master/polynomial-regression-core

运行效果:

目标方程: y = ax^3 + bx^2 + cx + d. 参数值为: a: -0.8, b: -0.2, c: 0.9, d: 0.5

运行目标：我们知道函数长这样，但具体的参数值不清楚，猜测a,b,c,d的值。训练的过程就是最小化误差的过程

三步走

1. 初始化参数为tf变量，初始化为随机值

const a = tf.variable(tf.scalar(Math.random()));
const b = tf.variable(tf.scalar(Math.random()));
const c = tf.variable(tf.scalar(Math.random()));
const d = tf.variable(tf.scalar(Math.random()));

2. 创建模型，模型为上述的目标方程:

function predict(x) {
  // y = a * x ^ 3 + b * x ^ 2 + c * x + d
  return tf.tidy(() => {
    return a.mul(x.pow(tf.scalar(3)))
      .add(b.mul(x.square()))
      .add(c.mul(x))
      .add(d);
  })
}

3. 训练，训练以上模型，即学习目标参数值。训练模型需要:

• 损失函数:
• 优化函数
• 训练循环

损失函数

判断拟合程度，一般为均方误差( 平方损失除以样本数)这个值越低，代表拟合越好。评价好坏用。

function loss(prediction, labels) {
	// 预测值和真实值的差值平方取平均，比方说完全拟合，结果就是0
  const error = prediction.sub(labels).square().mean();
  return error;
}

优化函数

随机梯度下降算法(最常见的优化算法），求取目标函数(损失函数)的最小值

// 学习率，每次一小步，逐渐靠近目标值
const learningRate = 0.5;
const optimizer = tf.train.sgd(learningRate);

训练循环

训练多少轮，即调整多少次数值

const numIterations = 75;
async function fit(xs, ys, numIterations) {
  for (let iter = 0; iter < numIterations; iter++) {
	  // train
    optimizer.minimize(() => {
      const pred = predict(xs);
      return loss(pred, ys);
    })
  }
  await tf.nextFrame();
}

回头看 T-Rex-Runner问题

途中有三个恐暴龙是因为作者用的多玩家模式优化算法，通过多只恐暴龙同时训练，达到见多识广的效果（多重影分身）。

问题描述: 根据状态(输入)进行是否跳跃的预测predict（输出)。

输入:

return [
      state.obstacleX / CANVAS_WIDTH,      // 障碍物离暴龙的距离
      state.obstacleWidth / CANVAS_WIDTH,  // 障碍物宽度
      state.speed / 100                    // 当前游戏全局速度
 ];

输出:

[0.2158, 0.8212] 
// 其中第一维代表暴龙保持状态不变的可能性，而第二维度代表跳跃的可能性

预测方式:
f([0.1428, 0.02012, 0.00549]) = [0.2158, 0.8212]表示预测结果为跳跃

如何训练

训练过程嵌入生命周期，最主要在以下三个函数中嵌入训练和预测过程:

• onReset：游戏重置
• onCrash：恐暴龙爆炸
• onRunning: 恐暴龙在跑

onRunning函数(Predict)

跑的过程中判断是否要跳，还是保持不动。

function handleRunning({ tRex, state }) {
  return new Promise((resolve) => {
    if (!tRex.jumping) { // 在跳的过程中不做判断
      let action = 0;
      const prediction = tRex.model.predictSingle(convertStateToVector(state));
      prediction.data().then((result) => {
        if (result[1] > result[0]) { // 不跳
          action = 1;
          tRex.lastJumpingState = state;
        } else { // 跳
          tRex.lastRunningState = state;
        }
        resolve(action);
      });
    } else {
      resolve(0);
    }
  });
}

onCrash（重要训练数据)

crash的时候进行训练数据的收集

function handleCrash({ tRex }) {
  let input = null;
  let label = null;
  if (tRex.jumping) { //  crash的时候在跳
    input = convertStateToVector(tRex.lastJumpingState);
    label = [1, 0]; // 下次遇到这种情况别跳啊
  } else { // crash的时候在跑
    input = convertStateToVector(tRex.lastRunningState);
    label = [0, 1]; // 下次遇到这种情况要跳啊
  }
	// 存下来crash的数据
  tRex.training.inputs.push(input);
  tRex.training.labels.push(label);
}

onReset(训练节点)

function handleReset({ tRexes }) {
  const tRex = tRexes[0];
  if (firstTime) { // 首次初始化模型
    firstTime = false;
    tRex.model = new NNModel();
    tRex.model.init();
    tRex.training = {
      inputs: [],
      labels: []
    };
  } else { // 第二次之后开始训练
    tRex.model.fit(tRex.training.inputs, tRex.training.labels);
  }
}

训练模型（以NN神经网络为例)

和之前的predict不同，这个函数的样子我们未知，使用神经网络模拟。看他的模型，你会发现你也能看得懂了(至少是语法层面上)。

  predict(inputXs) { // 预测
    const x = tensor(inputXs);
    const prediction = tf.tidy(() => {
      const hiddenLayer = tf.sigmoid(x.matMul(this.weights[0]).add(this.biases[0]));
      const outputLayer = tf.sigmoid(hiddenLayer.matMul(this.weights[1]).add(this.biases[1]));
      return outputLayer;
    });
    return prediction;
  }

  train(inputXs, inputYs) { // 单次训练
    this.optimizer.minimize(() => {
      const predictedYs = this.predict(inputXs);
      return this.loss(predictedYs, inputYs);
    });
  }

  fit(inputXs, inputYs, iterationCount = 100) { // 拟合，训练多次
    for (let i = 0; i < iterationCount; i += 1) {
      this.train(inputXs, inputYs);
    }
  }

  loss(predictedYs, labels) { // 损益度量
    const meanSquareError = predictedYs
      .sub(tensor(labels))
      .square()
      .mean();
    return meanSquareError;
  }

应用场景探索

• 各种人机交互场景的智能化，实时性要求较高的场景，对计算精度要求不高(用户浏览器没有那么高的算力)。
• 体感游戏，姿势识别，HTML5版的体感切水果...
• 在浏览器中玩[neural-style-tf](GitHub - cysmith/neural-style-tf: TensorFlow (Python API) implementation of Neural Style) ，之前比较火的图像融合应用（计算量可能不足，需要Opencv)
• 设计稿输出源码，辅助代码开发等
• 其他场景欢迎补充

参考资料

• https://blog.floydhub.com/turning-design-mockups-into-code-with-deep-learning/, 中文版 https://www.jiqizhixin.com/articles/2018-01-12-5
• Automated front-end development using deep learning https://blog.insightdatascience.com/automated-front-end-development-using-deep-learning-3169dd086e82
• Generate HTML, CSS straight from Sketch using Protoship
• 相关论文:
  • https://arxiv.org/abs/1705.07962 pix2code
  • https://machinelearningmastery.com/blog/page/2/ image caption tutorials
• 深度学习基础
  • https://blog.floydhub.com/my-first-weekend-of-deep-learning/
  • 零基础入门深度学习(1) - 感知器 https://zybuluo.com/hanbingtao/note/433855

在PC时代，302跳转似乎已经成为一种模式，在非常多的场景下使用302的方式，并且并没有发现有任何的不妥，但是在这几年做移动开发的时候，却发现302跳转带来了严重的性能问题，并且在最近的几个项目里特别明显，302在移动端的主要问题在于几个方面：

1. DNS Lookup
2. HTTPS的握手
3. 后续必然有一个request

在弱网环境下，一个302的请求会造成大概3s+的时间，在加上后续的200的请求，基本需要5s+的时间。

举一个例子说明：

在PC时代，做两个不同域名的信任登录，一般的做法为，访问a.com域名，然后a.com域名302到b.com域名，b.com域名使用token，从服务端去a.com的服务端验证，然后做好登录后，在302到真正的业务页面，b.com/page1.html。

这在PC时代是一个非常常用的方法，但是这种方法，在移动端就会造成严重的性能问题，一共有3次请求，前两次请求，在弱网环境下，耗时在10s左右的时候，当最后一次200的时候，可能总体时间已经超过了将近12s，12s的纯白屏，我相信对于任何用户都是无法忍受的，并且作为页面无法做任何体验上的优化，因为连一条js代码、html代码都还下来呢，并且这种性能问题，非常的隐蔽，因为常用的页面性能耗时是无法统计2次302跳转和一条200的请求时间的。

在测试阶段，由于使用的是wifi环境，性能非常好，几乎不会发现这个性能，因此这种情况，经常发现在线上，用户反馈很慢，才会注意到。这种时候，再改302的逻辑，会非常困难的。

想想OAuth的实现方式吧，这里就不说了。因此对于移动端，需要非常的注意这个问题。

实践经验：最多一次302，绝不要超过2次，否则就准备哭吧。

声明式编程

声明式编程可以提高程序整体的可读性（面向人、机器），包括不限于声明类型、声明依赖关系、声明API路径/方法/参数等等。从面向机器的角度，声明式的好处在于可以方便的提取这些元信息进行二次加工。声明式也是对系统整体的思考，找到关注点，划分切面，提高重用性。从命令式到声明式，是从要怎么做，到需要什么的转变。

本文偏重于 Egg 中的实践、改造，偏重于系统整体，在具体实现功能的时候，比如使用 forEach/map 替代 for 循环，使用 find/include 等替代 indexOf 之类的细节不做深入。

Controller

Controller 作为系统对外的接口，涉及到前后端交互，改变带来的提升是最明显的。

在 Java 体系里，Spring MVC 提供了一些标准的注解来支持API定义，一种普通的写法是：

@RequestMapping(value = "api/foo/{fooId}", method = RequestMethod.POST)
@ResponseBody
public Result<Void> create(HttpServletRequest request) {
  Boolean xxxx = StringUtils.isBlank(request.getParameter("fooId"));
  if (无权限) {
    ...
  }
  ...// 日志记录
}

这种声明式的写法使我们可以很容易的看出这里声明了一个 POST 的API，而不需要去找其他业务逻辑。不过这里也有一些问题，比如需要通读代码才能知道这个API的入参是 fooId，而当 Controller 的逻辑很复杂的时候呢？而权限判断之类的逻辑就更难看出了。

很显然这种写法对于看代码的人来说是不友好的。这种写法隐藏了参数信息这个我们关注的东西，自然很难去统一的处理入参，像参数格式化、校验等逻辑只能和业务逻辑写在一起。

而另一种写法就是把参数声明出来：

@RequestMapping(value = "api/foo/{fooId}", method = RequestMethod.POST, name = "创建foo")
@ResponseBody
public Result<Void> create(@PathVariable("fooId") String fooId, Optional<boolean> needBar) {
  ...
}

(Java 也在不断的改进，比如 JDK 8 加入的 Optional<T> 类型，结合 Spring 就可以用来标识参数为可选的)

这些都是在 Java/Spring 设计之内的东西，那剩下的比如权限、日志等需求呢？其实都是同理，这种系统上的关注点，可以通过划分切面的方式把需求提取出来，写成独立的注解，而不是跟业务逻辑一起写在方法内部，这样可以使程序对人，对机器都更可读。

抽象权限切面：

/**
  * 创建foo
  * @param fooId
  * @return
  */
@RequestMapping(value = "api/foo/{fooId}", method = RequestMethod.POST, name = '创建Foo')
@Permission(Code = PM.CREATE_FOO) // 假设权限拦截注解
@ResponseBody
public Result<Void> create(@PathVariable("fooId") String fooId) {
  ...
}

面向机器

声明式的优点不仅是对人更可读，在用程序做分析的时候也更方便。比如在日常开发中，经常有需求是后端人员需要给前端人员提供API接口文档等信息，最常用的生成文档的方式是写完善的注释，然后通过 javadoc 可以很容易的编写详细的文档，配合 Doclet API 也可以自定义 Tag，实现自定义需求。

注释是对代码的一种补充，从代码中可以提取的信息越多，注释中冗余的信息就可以越少，而声明式可以降低提取的成本。

得益于 Java 的反射机制，可以容易的根据代码提取接口的路由等信息，还可以根据这些信息直接生成前端调用的SDK进一步简化前端调用成本。

*ASP.NET WebAPI 也有很好的实现，参见官方支持：Microsoft.AspNet.WebApi.HelpPage

Egg

有了 Java 的前车之鉴，那在 Egg 中是不是也可以做相应的优化呢？当然是可以的，在类型方面有着 TypeScript 的助攻，而对比 Java 的注解，JavaScript 里的装饰器也基本够用。

改造前：

// app/controller/home.js
export class HomeController {
  async getFoo() {
    const { size, page } = this.ctx;
    ...
  }
}

// app/router.js
export (app) => {
  app.get('/api/foo', app.controller.home.getFoo);
}

改造后：

// app/controller/home.ts
export class HomeController {
  @route('/api/foo', { name: '获取Foo数据' })
  async getFoo(size: number, page: number) { // js的话，去掉类型即可
    ...
  }
}

使用装饰器的 API 可以实现跟 Java 类似的写法，这种方式也同时规范了注册路由的方式及信息，以此来生成API文档、前端SDK这类功能当然也是可以实现的，详情：egg-controller 插件

JavaScript 的实现的问题就在于缺少类型，毕竟代码里都没写嘛，对于简单场景倒也足够。当然，我们也可以使用 TypeScript 来提供类型信息。

TypeScript

其实从 JavaScript 切换到 TypeScript 的成本很低，最简单的方式就是将后缀由 js 改成 ts，只在需要的地方写上类型即可。而类型系统会带来许多方便，编辑器智能提示，类型检查等等。像 Controller 里的API出入参类型，早晚都是要写一遍的，无论是是代码里、注释里还是文档里，所以何不一并搞定呢？而且现在 Egg 官方也提供了针对 TypeScript 便捷的使用方案，可以尝试一下。

反射/元数据

TypeScript 在这方面对比 Java/C# 还是要弱不少，只能支持比较基础的元数据需求，而且由于 JavaScript 本身模块加载机制的原因，TypeScript 只能针对使用 decorators 的 Function、Class 添加元数据。比如泛型、复杂类型字段等信息都无法获取。不过也有曲线的解法，TypeScript 提供了 Compiler API，可以在编译时添加插件，而在编译期，由于是针对 TypeScript 代码，所以可以获取到丰富的信息，只是处理难度较大。

依赖注入

在其他组件层面也可以应用声明式编程来提升可读性，依赖注入就是一种典型的方式。

当我们拆分了两个组件类，A 依赖 B 的时候，最简单写法：

class A {
  foo() {}
}

class B {
  bar() {
    const a = new A();
  }
}

可以看到 B 直接实例化了对象 A，而当有多个类依赖 A 的话呢？这种写法会导致创建多个 A 的实例，而放到 Egg 的环境下，Service 是有可能需要 ctx 的，那么就需要 const a = new A(this.ctx); 显然是不可行的。

Egg 的解决方案是通过 loader 机制加载类，在 ctx 设置多个 getter ，统一管理实例，在首次访问的时候初始化实例，在 Egg 项目中的写法：

public class FooService extends Service {
    public foo() {
      this.ctx.service.barService.bar();
      ...
    }
}

为了实现实例的管理，所有组件都统一挂载到了 ctx 上，好处是不同组件的互访问变得非常容易，不过为了实现互访问，每个组件都强依赖了 ctx，通过 ctx 去查找组件，大家应该也看出来了，这实际上在设计模式里是服务定位器模式。在 TypeScript 下，类型定义会是问题，不过 Egg 做了辅助的工具，可以根据符合目录规范的组件代码生成对应的类型定义，通过 TypeScript 合并声明的特性合并到 Egg 里去。这也是当前性价比很高的方案。

这种方案的优点是互访问方便，弊端是 ctx 上挂载了许多与 ctx 本身无关的组件，导致 ctx 的类型是分布定义的，比较复杂，而且隐藏了组件间的依赖关系，需要查看具体的业务逻辑才能知道组件间依赖关系。

那在 Java/C# 中是怎么做的呢？在 Java/C# 中 AOP/IoC 基本都是各个框架的标配，比如 Spring 中：

@Component
public class FooService {
    @Autowired
    private BarService barService;

    public foo() {
      barService.bar();
      ...
    }
}

当然，在 Java 中一般都是声明注入 IFooService 接口，然后实现一个 IFooServiceImpl，不过在前端基本上不会有人这么干，没有这么复杂的需求场景。所以依赖注入在前端来说能做的，最多是将依赖关系明确声明，将与 ctx 无关的组件与 ctx 解耦。

Egg 中使用依赖注入改造如下：

public class FooService extends Service { // 如果不依赖 ctx 数据，也可以不继承
    // ts
    @lazyInject()
    barService: BarService;

    // js
    @lazyInject(BarService)
    barService;

    public foo() {
      this.barService.bar();
      ...
    }
}

换了写法之后，可以直观的看出 FooService 依赖了 BarService，并且不再通过 ctx 获取 BarService，提高了可读性。而依赖注入作为实例化组件的关注点是可以简单的实现一些面向切面的玩法，比如依赖关系图、函数调用跟踪等等。

egg-aop，Egg 下 AOP / IoC 插件

结语

代码是最好的文档，代码的可读性对后续可维护性是非常重要的，对人可读关系到后续维护的成本，而对机器可读关系到自动化的可能性。声明式编程更多的是去描述要什么/有什么而非怎么做，这在描述模块/系统间的关系的时候帮助很大，无论是自动化产出文档还是自动生成调用代码亦或是Mock对接等等，这都减少了重复劳动，而在大谈智能的时代，数据也代表了另一种可能性。

趣谈异步编程之“妈妈喊你回家吃饭”，来聊一聊 javascript 中常见的几种异步编程方式。

方式一：回调函数

小明饿了要吃饭，妈妈的饭要半个小时后才能做好，让小明先去读会儿书，饭好后再喊他。于是热腾腾的回调函数产生了：

function eat() {
	console.log('好的，我开动咯');
}

function cooking(callback) {
    console.log('妈妈认真做饭');
    setTimeout(function () {
      console.log('小明快过来，开饭啦')；  
      callback();
    }, 30 * 60 * 1000);
}

function read() {
    console.log('小明假装正在读书');
}

cooking(eat);
read();

/* 执行顺序：
妈妈认真做饭
小明假装正在读书
小明快过来，开饭啦
好的，我开动咯
*/

回调函数简单直观，对于读书中的小明来说，妈妈 cooking 是一个异步任务，完成之后妈妈直接调用 eat，以此来通知小明吃饭，于是小明有饭吃了。在 promise 出现前的很长一段时间中，回调函数是异步编程的首选。

但坑猿的是，多层回调函数也很可能会将你带入 callback hell 【回调地狱】，以至于曾经一度流传【据统计，javascript 代码注释中的脏话是所有语言中最多的】。

方式二：事件

生活是什么？生活就是不断重复，于是很快小明又饿了。

但有追求的程序员拒绝一直重复，这次换了个玩法：

function eat() {
    console.log('妈妈敲门啦，该去吃饭啦');
}

function cooking() {
    console.log('妈妈认真做饭');
    setTimeout(function () {
      console.log('小明，出来吃饭啦')；  
      cooking.$emit('done');
    }, 30 * 60 * 1000);
}

function read() {
    console.log('小明又假装正在读书');
    cooking.$on('done', eat);
}

cooking();
read();

/* 执行顺序：
妈妈认真做饭
小明又假装正在读书
小明，出来吃饭啦
妈妈敲门啦，该去吃饭啦
*/

可以看到，这次 eat 和 cooking 分手了，cooking 再也看不到 eat 的身影。当妈妈 cooking 完后大喝一声 done ！正在 read 的小明马上屁颠屁颠地跑过来了，为什么呢？因为小明读书的时候就一直竖着耳朵在听妈妈什么时候发出这声大喝。

在事件模型中，每个对象都是独立的个体，各自管理自己的状态，通过相互之间发送和接受消息来实现对象间通信。事件模型可以将代码格式从令人绝望的嵌套状转到优美的序列状，于是 jser 们可以从 callback hell 里爬出来了吗？既傻又天真。试想一下：如果真要你将一份多重嵌套的回调函数重构成事件模型模式，你会怎么做，你需要写多少行 $on 和 $emit ，需要为多少个无聊的事件起名字，相信你只会更绝望。

事件模型是一个优秀的异步方案，但显然，他更擅长解构，不是为了解决 callback hell 而存在。

方式三：发布/订阅

生活不止重复，也有意外。

今天小明和妈妈吵架了，互相都不说话，于是冤大头爸爸上线了，负责担任 传话筒 一职：

function eat() {
    console.log('爸爸叫我去吃饭啦');
}

function cooking(){
	console.log('妈妈认真做饭');
	setTimeout(function () {
		console.log('孩子他爸，叫小明出来吃饭');
  		Dad.publish("done");
	}, 30 * 60 * 1000);

}

function read() {
    console.log('小明依旧假装正在读书');
    Dad.subscribe('done', eat);
}

cooking();
read();

/* 执行顺序：
妈妈认真做饭
小明依旧假装正在读书
孩子他爸，叫小明出来吃饭
爸爸叫我去吃饭啦
*/

看完后智商在线的你可能会发现：这和事件模型有啥区别。。。

是的，它们没有本质区别，发布/订阅模式只是事件模型中比较高级的一种实现形式，加入爸爸这个 传话筒 后，所有的消息都由爸爸来传递、管理和跟踪。当勤奋的你代码量变得越来越大的时候，这个爸爸作用老大了。

方式四：Promise

Promise 是啥？

Promise 对象用于表示一个异步操作的最终状态（完成或失败），以及其返回的值。

某种角度上，它既学习了回调函数的简单直观，又借鉴了事件模型的状态内聚。一个 Promise 只有三种状态，我们需要关心 fulfilled 和 rejected ，分别用 then 和 catch 处理它们，于是回调地狱不见了，也不需要定义大堆事件，就这么简单，就这么神奇。

好吧，小明再次饿了，但这次我们让小明吃完后洗个碗，洗完碗后再拖个地......看看 Promise 怎么爬出 callback hell ：

function read() {
    console.log('小明认真读书');
}

function eat() {
    return new Promise((resolve, reject) => {
        console.log('好嘞，吃饭咯');
        setTimeout(() => {
            resolve('饭吃饱啦');
        }, 10 * 60 * 1000)
    })
}

function wash() {
    return new Promise((resolve, reject) => {
    	console.log('唉，又要洗碗');
        setTimeout(() => {
            resolve('碗洗完啦');
        }, 10 * 60 * 1000)
    })
}

function mop() {
    return new Promise((resolve, reject) => {
    	console.log('唉，还要拖地');
        setTimeout(() => {
            resolve('地拖完啦');
        }, 10 * 60 * 1000)
    })
}

const cooking = new Promise((resolve, reject) => {
    console.log('妈妈认真做饭');
    setTimeout(() => {
        resolve('小明快过来，开饭啦');
    }, 30 * 60 * 1000);
})
    
cooking.then(msg => {
    console.log(msg);
    return eat();
}).then(msg => {
    console.log(msg);
    return wash();
}).then(msg => {
    console.log(msg);
    return mop();
}).then(msg => {
    console.log(msg);
    console.log('终于结束啦，出去玩咯')
})
read();

/* 执行顺序：
妈妈认真做饭
小明认真读书
小明快过来，开饭啦
好嘞，吃饭咯
饭吃饱啦
唉，又要洗碗
碗洗完啦
唉，还要拖地
地拖完啦
终于结束啦，出去玩咯
*/ 

好了，很溜吧。

“妈妈喊你回家吃饭”到此结束，但异步编程是一个很大的议题，内容远不至此，等待你持续挖掘。

react是在13年左右开始开源的第一个版本，为什么 react 能取代我们之前用的 jQuery 这样的开发库，成为然后随着其开发理念和ReactNative这样的跨端研发库，使得 react 迅速成为最受欢迎的前端开发框架？

我们回顾下，在没有 react 这样的框架之前，我们使用 jQuery 来做前端开发的时候是什么样的、
举个简单的场景，
页面上有个按钮，点击后数字 +1，

<span>1</span> <a>+</a>

使用 jQuery，我们的代码大概是下面这样的：

$('a').on('click', () => {
 let num = parseInt($('span').text(), 10);
 $('span').text(++num);
});

这是在 jquery 时期很常见的代码，当时写这些代码的时候并没有觉得有什么问题，反而操作dom 的方式显得非常直观，开发者仅需要在页面上通过 获取元素，然后操作 dom 的元素即可。另外 jQuery 封装了很多的浏览器兼容性问题，让每个浏览器下的都有标准的 api 接口。
那么这种以 dom 为主的开发方式会带来什么问题呢？现在回过头去看，是能看到一些问题的，以dom为视角的开发，很多情况下是将后端渲染后的页面去做一些点缀性的交互操作。那这种交互操作对于开发的人来说，其实是很散的。在代码层面，完全看不到相关的逻辑关系。比如：

option.js

// 点击 a 按钮的时候的操作
$('.class_a').click(function() {
  // code...
});
// 点击 b 按钮的时候的操作
$('.class_a .class_b').click(function() {
  // code...
});

从这段代码里我们并不能看到这些 dom 操作跟我当前页面有什么关系，而更像是挂载在页面上的一段段贴片脚本，另外由于后端代码和前端的脚本是分开在不同的地方，那么当后端代码把相关的 dom 元素删除之后，很多情况下，我们并没有意识要去删除一些相关的无用的 js 代码，这会导致后续随着项目工程的越来越大，无效代码也越来越多。

那么这个问题怎么解，一个方式就是组件化，在那个年代，有很多的团队也在在这样的事情，只是那时候的方式是按照就近原则把相关的文件聚在一起，比较有名的是两个方案：一个是以 backbone 为主的 mvc 框架，一个是 facebook 的bigpipe，其实 backbone 或者 bigpipe 已经离现在的这种数据流为主的框架至少从代码结构层面已经很接近了。从工程维护的角度来讲，也都是一样的思路。那么为什么在这之后还会有 react 这样的框架出来？

很重要的一点是之前的这些框架，从思路上来说还是以 dom 操作为主，页面的渲染是一次性的，可以是后端渲染，也可以是前端通过模板引擎来渲染，但是后续的交互还是通过 dom 操作来完成。

而 react 带来的思路是 view = f(data); 页面渲染是通过 data 驱动，后续的交互操作也是通过 data 的变更来展示页面。

那这样的好处是什么呢？
1、前端与后端通过 json 来传递数据，可以方便的去做前后端分离。
2、组件化，让前端更易规模化和工程化
3、渲染层都由前端控制，且通过 virtual dom 让渲染更高效
4、页面的渲染通过数据驱动，页面变成了一个状态机，从而让之前的那种操作 dom 的不可追溯源头的方式变得更易追踪是什么操作导致的页面变化。

几年前 jQuery 还很火，基本上每个网站都有 jQuery 或者 YUI 这样的框架来做的，但是现在这类的框架变成了过时的东西，其实从很多的框架为什么会变得流行，一般都是因为它创新的思路去解决问题的方法。对我们来说也是一样，我们去解决一个遗留问题的时候，我们能否换个思路，用创新的方法去解决，或许会能打开一片新的天地。

起因

Router 描述了请求 URL 与 Controller 的对应关系。Eggjs 约定所有的路由都需要在 app/router.js 中申明，目录结构如下：

┌ app
├── router.js
│  ├── controller
│  │  ├── home.js
│  │  ├── ...

路由和对应的处理方法分开在 2 个地方维护，开发时经常需要在 router.js 与 Controller 之间来回切换。

前后台协作时，后端需要为每个 Api 都生成一份对应的 Api 文档给前端。

更优雅的实现

得益于 JavaScript 加入的 decorator 特性，可以使我们跟 Java/C# 一样，更加直观自然的做面向切面编程：

// 基础版
@route('/intro')
async intro() { }

// 定义 Method
@route('/intro', { method: 'post' })
async intro() { }

// 增加权限
@route('/intro', { method: 'post', role: xxxRole })
async intro() { }

// Controller 级别中间件
@route('/intro', { method: 'post', role: xxxRole, beforeMiddleware: xxMiddleware })
async intro() { }

为什么是这样的方案

为什么设计如此复杂的功能，是不是在滥用 Decorator？

先看看 route 的功能：

• 路由定义
• 参数校验
• 权限
• Controller 级别中间件

router 官方完整定义中包含的功能：路由定义、中间件、权限，及文档中未直接写的“权限”：

router.verb('router-name', 'path-match', middleware1, ..., middlewareN, app.controller.action);

比较下来会发现，只是多了“参数校验”功能。

参数校验

Eggjs 中参数校验的官方实践：

class PostController extends Controller {
    async create() {
        const ctx = this.ctx;
        try {
            // 校验参数
            // 如果不传第二个参数会自动校验 `ctx.request.body`
            ctx.validate(createRule);
        } catch (err) {
            ctx.logger.warn(err.errors);
            ctx.body = { success: false };
            return;
        }
    }
};

在我们的业务实践中这个方案会有 2 个问题：

• 参数漏校验

  比如用户提交的数据为 { a: 'a', 'b': 'b', c: 'c' }，如果校验规则只定义了 a，那么 b、c 就被漏掉了，并且后续业务中可能会使用这 2 个值。

• Eggjs 一个 request 生命周期内，可以随时随地通过 ctx.request 拿到用户数据

  因为“参数漏校验”问题的存在，导致后续业务变的不稳定，随时可能会因为用户的异常数据导致业务崩溃，或者出现安全问题。

解决方案

为了解决“参数漏校验”问题，我们做了如下约定：

• Controller 也需要申明入参

  class UserController extends Controller {
      @route('/api/user', { method: 'post' })
      async updateUser(username) {
          // ...
      }
  }
  

  上面的例子中，即使用户提交了海量数据，业务代码中也只能拿到 username

• Controller 之外的业务不应该直接访问 ctx.request 上的数据

  也就是说，当某个 Service 方法依赖用户数据时，应该通过入参获取，而不是直接访问 ctx.request

基于以上约定，分别看看 JS、TypeScript 下我们如何解决参数校验问题：

• JS

  @route('/api/user', {
      method: 'post',
      rule: {
          username: { type: 'string', max: 20 },
      }   
  })
  async updateUser(username) {
      // ...
  }
  

  这里使用了 egg-validate 底层依赖的 parameter 作为校验库

• TypeScript

  @route('/api/user', {
      method: 'post'
  })
  async updateUser(username: R<{ type: string, max: 20 }>) {
      // ...
  }
  

没看错，手动调用 ctx.validate(createRule) 并捕获异常的逻辑确实被我们省略掉了。“懒惰”是提高生产力的第一要素。参数、规则都有了，为什么还要自己撸代码呢？

新的前后端协作实践

传统的前后端开发协作方式中，后端提供 Api 给前端调用，代码类似这样：

function updateUser() {
    request
        .post(`/api/user`, { username })
        .then(ret => {
            
        });
}

前端同学需要关注路由、参数、返回值。而这些信息 Controller 都已经有了，直接生成前台 service 用起来是不是更方便呢：

• Controller 代码：

  export class UserController {
  
    @route({ url: '/api/user' })
    async getUserInfo(id: number) {
      return { ... };
    }
  }
  

• 生成的 service：

  export class UserService extends Base {
    /** 首页  */
    async getUserInfo(id: number) {
      const __data = { id };
      return await this.request({
        method: `get`,
        url: `/api/user`,
        data: __data,
      });
    }
  
  }
  
  export const metaService = new UserService();
  export default new UserService();
  

• 前台使用

  import { userService } from 'service/user';
  
  const userInfo = await userService.getUserInfo(id);
  

  对比原来的写法：

  function updateUser() {
      return new Promise((resolve, reject) => {
          request
          .post(`/api/user`, { username })
          .then(ret => {
              resolve(ret);
          }); 
      });
  }
  

  userService.getUserInfo 内部封装了 request 逻辑，前端不需要在关心调用过程。

如何在自己的项目中使用

我们已经把最佳实践抽象为了 egg-controller 插件，可以按下面的步骤安装使用：

1. 安装 egg-controller

   tnpm i -S egg-controller
   

2. 启用插件

   打开 config/plugin.js，增加以下配置

   aop: {
       enable: true,
       package: 'egg-aop',
   },
   controller: {
       enable: true,
       package: 'egg-controller',
   },
   

3. 使用插件

   详细用法参考 egg-controller 文档

之前，在 #27 里，介绍了流的一些基本概念，在 #25 中，又列举了一种轮询业务场景的实现，本文试图用这种理念去实现同样的轮询功能。本文的例子使用 xstream.js 来编写。

想要使用流的理念来实现业务功能，最重要的就是思维的抽象，比较直接的方法论是：

寻找一切变更的源头，理清事情之间的顺序和依赖关系。

在定时轮询整个场景中，我们可以发现，一切事情的起源是定时器，只有这个来源是不依赖于任何其他东西的，因此，我们得到了第一个数据流：

const periodic$ = xs.periodic(1000);

这样，就得到了一个每秒发生一次的流。

然后，这个流导致什么事情呢？

发送一个HTTP请求，并且取回结果。

并且，我们可以注意到，这个操作是由前一个流触发的，每一次定时器的变动都会触发一次请求，因此，可以进行这么一个映射：

timer => request

所以，可以得到以下代码：

const request$ = periodic$
  .map(_ => xs.fromPromise(request(endPointURL)))

此处，我们把一个普通的请求转化为了流，这个流里面实际上最多只会有一个值，也就是请求结果。

需要注意的是，经过我们上面的操作，数据流的形态已经变成二阶了，也就是说，request$ 中的每个元素，都又是一个流（从 Promise 转化出来的流）

想要得到我们预期的效果，就必须对这个流降阶，最简单的方式就是 flatten：

const imageUrl$ = request$.flatten();

降阶的意义是把高阶流的值提出来，并且合并到一个低阶流。刚才我们从 Promise 转出来的流，实际上每个里面只会有一个结果，本次降阶的含义大致类似于：

[[result1], [result2], [result3]] => [result1, result2, result3]

至此，我们只需直接订阅这个 imageUrl$，就可以持续不断地从其中获得新的图片地址了。

回顾整个过程，我们好像是建立了一条线路，或者一条管道，使得数据可以在其中流通。

但我们的需求还要更复杂一些，因为它是要允许通过一个开关，来控制定时拉取操作的启用与否。

那么，我们怎么才能把开关的逻辑加进去呢？

加开关的思路是在刚才的管道上加个阀门。

看看刚才的线路：

定时器 -> 请求 -> 请求结果

这个阀门加在哪里呢，很显然是加在请求和请求结果之间，因为我们的逻辑是：当开关关闭的时候，即使有还在发的请求，它的结果我们也不要了，所以在结果这里处理是比较合适的。

构造一个开关：

const switch$: Stream<boolean> = xs.create();

然后，把它跟之前的请求流组合起来：

const result$ = xs.combine(
    imageUrl$,
    switch$,
  )
  .filter(arr => {
    const isPolling = arr[1];
    return isPolling;
  })
  .map(arr => {
    const result = arr[0];
    return result.message;
  });

解释一下上面的代码：

• combine 操作，是把若干个流组合起来，以各自最后一个值，形成数组，所以，组合之后的流，每个值都是一个数组，数组的第一个值是请求结果，第二个值是开关
• filter 操作，丢弃所有开关关闭状态时候的值
• map 操作，把留下的结果的 message 取出，即为符合我们预期的值

整个过程的流转关系，可以画一个图如下：

periodic$ -> request$ -> imgUrl$ -> |
                                    | -> combine$ -> filter$ -> result$
                         switch$ -> |

整个视图之外的完整的逻辑如下：

import * as React from 'react';
import xs, { Stream } from 'xstream';
import { DogView } from '../DogView';

import request from '../../service/request';

const endPointURL = 'https://dog.ceo/api/breeds/image/random';

interface IAppState {
  imgUrl: string;
}

export default class App extends React.Component<{}, IAppState> {
  public state: IAppState = {
    imgUrl: 'https://images.dog.ceo/breeds/puggle/IMG_114654.jpg',
  };

  private switch$: Stream<boolean> = xs.create();
  private poll$: Stream<string>;

  public componentWillMount() {
    const request$ = xs.periodic(1000)
      .map(_ => xs.fromPromise(request(endPointURL)))
      .flatten();

    this.poll$ = xs.combine(
        request$,
        this.switch$,
      )
      .filter(arr => {
        const isPolling = arr[1];
        return isPolling;
      })
      .map(arr => {
        const result = arr[0];
        return result.message;
      });

    this.poll$.addListener({
      next: (imgUrl) => this.setState({
        imgUrl,
      }),
    })
  }

  public render() {
    return (
      <DogView
        onClickFetchImg={this.onClickFetchImg}
        onStartPolling={this.onStartPolling}
        onStopPolling={this.onStopPolling}
        dogImgURL={this.state.imgUrl}
      />
    );
  }

  private onClickFetchImg = async () => {
    const result = await request(endPointURL);
    this.setState({
      imgUrl: result.message,
    });
  }

  private onStartPolling = () => {
    // 偷懒起见，这里可以用 _n，比较正式一点的话，这里可以造一个 producer，或者拿这个按钮的事件来形成新的流
    this.switch$._n(true);
  }

  private onStopPolling = () => {
    this.switch$._n(false);
  }
} 

从这段代码中，我们可以看到，流式编程的简洁性与高度抽象性，并且，它在工程上可以达到一种平衡，也就是：

• 对普通的 crud 代码，一次性的请求，还是用 async-await 去解决，不增加额外的负担
• 对复杂场景，是一种对代码结构侵入很小的模式，并且，对 TypeScript 的支持非常好，而且其内部实现不依赖于 JavaScript 的高级语法特性

让 babel 帮你编译 typescript

babel & typescript

babel 和 typescript 如今已经成为我严重依赖的两个工具了。

babel 让我们能够使用未来的 ES 特性，typescript 让我们为 js 加上静态类型，静态类型有什么好处想必用过的人都深有体会。

不管两个工具各自如何好，放在一起用总是会有些别扭的地方...

两轮编译

很多时候我们使用 ts 之后还是没有办法去掉 babel 的依赖，因为我们可能依赖着 babel 生态里的很多插件，比方说做 antd 按需加载的 babel-plugin-import, 而这些插件无法脱离 babel 发挥作用。

那么这个时候你一定做过这样的事情：

1. 使用 typescript 把 ts 代码编译到 ES6，保留 jsx
2. 使用 babel 把 ES6 代码 和 jsx 编译到 ES5

如果你使用 webpack 的话你的配置文件可能如下：

{
    test: /\.tsx?$/,
    exclude: /node_modules/,
    use: [
        loader: 'babel-loader',
        loader: 'ts-loader',
    ]
}

可是这里明明它们做的事情是重叠的，我们为什么不能合并它们呢？

而且大家也早就有这方面的讨论，比如:

• Babel plugin for typescript
• babel-plugin-transform-typescript-strip-types

babel 7 & @babel/typescript

下一代的 babel 7 带来了新的能力，让我们可以不需要在编译两轮了

这件事情推进的关键在于 Babylon（Babel 使用的解析器）有了解析 typescript 的能力，有了这一层面的支持，我们就可以只使用 babel，而不用再加一轮 ts 的编译流程了

在 babel 7 中，我们使用新的 @babel/preset-typescript (其集成了 @babel/plugin-transform-typescript)

我们的 .babelrc 配置将变成这样：

{
  "presets": [
    "@babel/env",
    "@babel/react",
    "@babel/typescript"
  ]
}

你看是不是变得非常简洁？

有了这个，我们就可以只用 babel 就处理我们的 ts 代码了，我们也就可以去掉 ts-loader 之类的依赖了

类型检查

如果你需要类型检查你可以在 package.json 中加入如下 scripts

{
    "type-check": "tsc --noEmit"
}

或者说你在编译一个库，你同时希望生成声明文件，那么或许你会使用如下的脚本：

{
    "build": "tsc --emitDeclarationOnly && babel src --out-dir lib --extensions \".ts,.tsx\""
}

不妨在下个项目中一试吧

参考资料

https://zhuanlan.zhihu.com/p/28374218

https://babeljs.io/docs/en/next/babel-preset-typescript

http://artsy.github.io/blog/2017/11/27/Babel-7-and-TypeScript/

var i = 0;
while(i++<3){
    window.setTimeout(function(){
        console.log(i);
    },0);
    
    (function(clouser_i){
        window.setTimeout(function(){
            console.log('clouser:' + clouser_i);
        },1000);
    })(i);
}

在不运行的情况下，大家思考下会输出什么结果呢？

来解释下原因吧！

这篇文章的由来，是为了解决issue而做的总结。本来以为是使用不当，造成解析问题。深入追踪后发现是依赖包express-http-proxy没考虑这种情况，“一刀切”按照普通方式处理造成的。

剥茧抽丝的过程

示例工程，请求响应的过程可以下图展示：

首先看用户的代码逻辑，很简单就是用了application/x-www-form-urlencoded，并把参数通过qs.stringify(newOptions.body)处理&连接的字符串。

既然是真实server端接收到了{'{"username":"[email protected]", "password":"123"}': ''}这种形式的body，值得怀疑的地方有：

• 请求参数处理不当
• 代理配置有误
• 代理服务器请求有误
• 真实服务器未能识别格式。

疑点1：请求参数处理不当？

这个和MIME类型有关，科普下相关知识点。

MIME全名叫多用途互联网邮件扩展（Multipurpose Internet Mail Extensions），指的是一系列的电子邮件技术规范，主要包括RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289和RFC 2077。最初是为了将纯文本格式的电子邮件扩展到可以支持多种信息格式而定制的。后来被应用到多种协议里，包括我们常用的HTTP协议。

浏览器和服务器互发消息，消息头规定了是什么类型的消息(Content-type)，消息体就要是什么样的格式，这样彼此才能正确处理和解析消息。

application/x-www-form-urlencoded  # 使用HTTP的POST方法提交的表单
multipart/form-data  # 同上，但主要用于表单提交时伴随文件上传的场合

这两者规定了发送表单消息的格式。 x-www-form-urlencoded会将表单内的数据转换为键值对，不同的field会用"&"符号连接;空格被替换成"+";field和value间用”=“连接。如果是手动处理参数，也要处理成这种格式。 这说明，从浏览器发送消息到代理服务器，MIME设置和body格式，都是正确的。

疑点2：代理配置有误？

ant-design-pro项目中的mock主要依赖了roadhog，也就是代理是roadhog代为完成的。关键代码如下：

import proxy from 'express-http-proxy';
// ...
function createProxy(method, path, target) {
    return proxy(target, {
        // ...
    });
}
...
devServer.use(bodyParser.json({ limit: '5mb', strict: false }));
devServer.use(
    bodyParser.urlencoded({
        extended: true,
        limit: '5mb',
    }),
);
// ...
Object.keys(config).forEach(key => {
    const keyParsed = parseKey(key);
    // ...
    if (typeof config[key] === 'string') {
        let { path } = keyParsed;
        if (/\(.+\)/.test(path)) {
             path = new RegExp(`^${path}$`);
        }
        // 创建代理
        app.use(path, createProxy(keyParsed.method, path, config[key]));
    } else {
        // 本地mock
        app[keyParsed.method](
            keyParsed.path,
            createMockHandler(keyParsed.method, keyParsed.path, config[key]),
        );
    }
});

简单解释下，浏览器发送post到代理服务器，bodyParser会正确解析消息体并把数据以json格式存储到req.body。代理服务器响应的处理交由express-http-proxy去完成了。
看用户的代理配置很简单，并没有什么问题。

export default noProxy ? { 'POST /v2/api/*': 'http://127.0.0.1:3000' } : delay(proxy, 1000);

疑点3：真实服务器未能识别格式？

调试发现，POST请求发出时，参数形式已经改变(此时已经可以定位到出错点)，然后又把结果响应给代理服务器，这期间真实服务器这端没有什么问题。相关代码如下:

app.post('/', (req, res) => {
    const data = req.body;
    console.log('postbody', data);
    res.send(data);
});

疑点4：代理服务器请求有误！

express-http-proxy处理是个暗箱操作，暗箱里肯定存在处理req.body不当的地方。然后再把请求打包发送时，就造成了消息体格式问题。翻翻该包关键的代码，发现几处相关的：

# 该文件主要是处理options，会直接用浏览器端请求的headers大部分配置
/lib/requestOptions.js

# 这些文件处理body
/app/steps/buildProxyReq.js
/app/steps/decorateProxyReqBody.js
/app/steps/prepareProxyReq.js

# 该文件主要是向真实服务器发送请求，并监听真实服务器返回的数据
/app/steps/sendProxyRequest.js

# 该文件主要是响应浏览器端请求，并把真实服务器返回的数据 返回到浏览器端
/app/steps/sendUserRes.js

关键的处理不当的代码如下：

// ** 从代理服务器获取到req.body(json对象)，赋值给bodyContent
var parseBody = (!options.parseReqBody) ?
    Promise.resolve(null) :
    requestOptions.bodyContent(req, res, options);
// ...
return Promise
.all([parseBody, ...])
.then(function(responseArray) {
    Container.proxy.bodyContent = responseArray[0];
    // ...
    return Container;
});

if (bodyContent) {
    // ** 无视content-type，把bodyContent直接转成了json字符串
    bodyContent = container.options.reqAsBuffer ?
        as.buffer(bodyContent, container.options) :
        as.bufferOrString(bodyContent);
        // ...
}
container.proxy.bodyContent = bodyContent;

if (options.parseReqBody) {
    // ...
    if (bodyContent.length) {
       // ** 直接利用json字符串，而与content-type要求的格式不符
       proxyReq.write(bodyContent);
    }
    proxyReq.end();
}

proxy的原理

通过issue的追踪定位和对express-http-proxy的源码分析，可以很清楚地知道，核心模块就是http，核心方法就是http.request。浏览器发送请求到代理服务器，代理服务器通过http.request发送请求到真实服务器，然后在获取数据后返回结果给浏览器。就是这么简单~

注：首发于个人博客，时间是 2015-11-07

去年的这个时候，前端社区里 React.js 势头开始超越 Angular.js，现在 React 终于变成了前端最火的库。而近几个月同样发生着另外一个有趣又类似的事：在后端被广泛使用的 Rest (RESTful API)，开始受到各种质疑、特别是声称解决或替代 Rest 的方案如 GraphQL、Falcor 的出现并得到越来越多的关注，好像革命大旗举了起来。

Rest 有什么问题？大家普遍提到的有这些：

一：资源粒度

通过一个请求加载所有的信息同时使得我们的 Rest 资源保持隔离之间的冲突。 ref: GraphQL

Rest 的资源是拆分的“比较细的”，但应用里是想通过一个请求直接拿到尽可能多的数据，但对于 Rest 一次请求只能拿到某一个资源，这样就产生冲突了。

但对于这个问题，资源的 embeded 其实是可以解决的。目前对于那些有类似 “外键” 关联的资源（如一个学生数据库表里关联着老师的id），客户端发一个学生资源的请求、带上关联老师详情的 query 信息，就能把老师的详细信息关联查出来，一并发送给客户端。

二：实际场景

常见的图片瀑布流应用（无尽列表），随着用户鼠标滚动，要不停的发送请求，显示新的图片并获得相应的图片详细信息。

这种场景下，如果设计不当，例如在用户滚动的时候，才去加载需要的细粒度资源。那么假如获取一张图片的详细信息时，就需要发送至少 5 个资源请求，用户随便拖动下滚动条，就可能需要显示10张图片，这样一下子至少要发送 10*5 个资源请求，很明显这是不能忍的也是不对的。

这类场景正确的做法是只需要发送一次请求，返回一个列表数据，并在里边包含各种子资源即可。只是如果资源粒度比较细的话，子资源需要被 embed 进来就需要拼接不少参数，比较麻烦。

举个实例：

// 资源列表如：
[{
  id: 1
  name: "card",
  boxshot: "http://xx",
  rating: 5,
  bookmark: 2343,
  director: "david",
  // more fields
},
...
]

// Rest 请求列表资源
/list?rowOffset=0&rowSize=5&colOffset=5&colSize=15&titleprops=name,boxshot

// RPC 风格：
/list?pageSize=10x15&titleprops=name,boxshot

// 请求单个资源部分信息：
/list/123?props=name,rating,bookmark

以上可以看出，Rest 请求列表资源时，可能需要加很多参数，还不如 RPC 风格来的简单。这也大概正是 Falcor 作者要解决的问题，把 RPC 里的优点拿过来，更简单的组合资源。

Falcor 作者提到的 Rest 的设计初衷（视频）

The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web, but resulting in an interface that is not optimal for other forms of architectural interaction.

三：Rest API 的设计并不容易

一开始我们做系分时，可能比较容易划分出有哪些资源，对资源粒度划分也可能没那么难。但把这些资源组合或规划起来、对外提供 API 时，可能就没那么容易了，会有让人纠结的地方。如：

• 资源与子资源的组合和划分。有一些资源有明确的父子关系，但很多资源并没有，很多资源可能是平级关系、但需要互相联系起来。具体例子如：

GET /cars/711/drivers/ 
Returns a list of drivers for car 711

GET /cars/711/drivers/4 
Returns driver #4 for car 711

• 一些动作类资源的恰当处理，常见的如登陆、验证等。

这些问题看起来简单，实际去设计时、却很容易做不好。

那么 Rest 自身能否解决以上问题？

一开始 Rest 的出现，是为了解决 Rpc 的问题。Rpc 方式下，应用只有一个端点(endpoint)，导致紧耦合、不易缓存。

Rpc 和 Rest 的基本区别：

SOAP Web API采用RPC(面向方法Remote Procedure Call)风格，它采用面向功能的架构，所以在设计之初首先需要考虑的是提供怎样的功能。

RESTful Web API采用ROA(面向资源Resouce Oriented Architecture)架构，所以在设计之初首先需要考虑的是有哪些资源可供操作。

引用下 richardson rest 模型:

• Level 1 Resources （解决了 Rpc 问题）
• Level 2 Http verbs （使用 http verbs 来对各种资源进行 crud 操作，使应用接口更加的统一）
• Level 3 Hypermedia Controls
  • level 3 带来了 service discoverablility 和 self-documenting。举例就像访问了某一个最顶层资源，它会返回一个它的子资源列表地址；再访问其中某个子资源，这个子资源又返回它的子资源或关联资源的地址；依次下去甚至能发现整个应用的所有资源地址。实例如 GitHub-API。

文中作者只提到了第三层级。而上边我们提到过资源的父子资源的 embeded 试想可能的话，让所有资源都能自由的互相 embeded 或者自由的做关联，那就是更进了一步，也差不多能解决以上提到的问题。但即便做到如此，Rest 也还是有其让人觉得不爽的地方。

GraphQL / Falcor 这类方案，都是宣称解决了 Rest 的一些问题，但其实也只是特定的场景，而它们真的是更上一层楼？恐怕也不见得，待以后实践证明吧。

前言：

这个文章之前在别的地方发过，没有人讨论，所以在这里重新编写了一遍，写写自己的一点看法。
文中标题一二三不代表这些概念是同级的，只是代表我自己的思路。
我这里引入几个概念，是我自己理解所得，不权威，但有利于我自己的学习和理解。

块block

我把页面中宽度占满屏幕，高度任意的元素（或者区域）称为块。不管是盒式布局中常提到的上中下结构、左右结构和复杂结构，都可以用这个概念简化。

如：上中下结构，可将下图的页头、主体和页脚视为三个块。

如：左右结构，可将菜单和主体组合起来的整体视为一个块。如下所示，红色框框视为一个块。

如：复杂结构，也是一样的将页面分成独立的块。不管里面元素的布局，先从整体上分析和实现。

项item

手机中也是可以同样概念理解，即宽度占满屏幕，高度任意的一个块称为项。

如：常用移动页面的首页

如上图所示，我将图中红色边框的块称为一个项，并不理会项中是单一元素还是复杂元素。如第一项中单一的banner，第二项中四个菜单按钮，和最后那几个项中的左右上下结构。
其实上图中的标题和详细说明，这个上下结构也可以理解为一个项，只是它是放在外层大项中的小项。

Flex弹性布局

理解了上述两个概念，接下来我们就比较容易理解Flex弹性布局了。要是用弹性布局，块级元素设置display:flex;行内元素设置display:inline-flex;将该元素设置为Flex容器。表明该元素内的子元素将使用弹性布局。注意设置成Flex容器之后，内部子元素（以下称为子项）的浮动和对齐属性都会失效。接下来我们对Flex容器的各个属性进行说明。

1、flex-direction 子项的排列方向，分为从左到右，从右到左，从上到下，从下到上

1.1 row 从左到右display: flex;flex-direction:row;

<div style="padding: 10px;border: 1px solid black;display: flex;flex-direction:row;">
    <div style="border: 1px solid red;">页头</div>
    <div style="border: 1px solid blue;">主体</div>
    <div style="border: 1px solid green;">页脚</div>
</div>

1.2 row-reverse 从右到左display: flex;flex-direction:row-reverse;

1.3 column 从上到下display: flex;flex-direction:column;

1.4 column-reverse 从下到上display: flex;flex-direction:column-reverse;

2、flex-wrap 子项排列不下之后是否换行，分为不换行，排到下一行，排到上一行

2.1 nowrap 不换行display: flex;flex-direction:row;flex-wrap:nowrap;

<div style="width:120px;padding: 10px;border: 1px solid black;display: flex;flex-direction:row;flex-wrap: nowrap;">
    <div style="width:50px;border: 1px solid red;">页头</div>
    <div style="width:50px;border: 1px solid blue;">主体</div>
    <div style="width:50px;border: 1px solid green;">页脚</div>
</div>

这里外层容器和子项都设置了宽度，但实际的并没有效果，会自动扩展。

2.2 wrap 排到下一行display: flex;flex-direction:row;flex-wrap:wrap;

2.3 wrap-reverse 排到上一行display: flex;flex-direction:row;flex-wrap:wrap-reverse;

3、flex-flow 上面两个属性的组合，如可以直接设置从左到右排列，排不下排到下一行

<div style="width:160px;padding: 10px;border: 1px solid black;display: flex;flex-flow:row wrap;">
    <div style="width:50px;border: 1px solid red;">页头</div>
    <div style="width:50px;border: 1px solid blue;">主体</div>
    <div style="width:50px;border: 1px solid green;">页脚</div>
</div>

4、justify-content 子项在排列方向上的对齐方式，（横向说明）分为左对齐，右对齐，居中对齐，两端对齐中间等分布局和全部等间距布局

4.1 flex-start 左对齐display: flex;flex-direction:row;justify-content:flex-start;

<div style="width:300px;height:50px;padding: 10px;border: 1px solid black;display: flex;flex-direction:row;justify-content:flex-start">
    <div style="border: 1px solid red;">页头</div>
    <div style="border: 1px solid blue;">主体</div>
    <div style="border: 1px solid green;">页脚</div>
</div>

4.2 flex-end 右对齐display: flex;flex-direction:row;justify-content:flex-end;

4.3 center 居中对齐display: flex;flex-direction:row;justify-content:center;

4.4 space-between 两端对齐中间等分布局display: flex;flex-direction:row;justify-content:space-between;

4.5 space-around 全部等间距布局display: flex;flex-direction:row;justify-content:space-around;

5、align-items 子项在另一个方向上的对齐方式，（横向说明）分为上对齐，下对齐，居中对齐，上下拉伸充满，子项首行文字对齐

5.1 flex-start 上对齐display: flex;flex-direction:row;align-items:flex-start;

<div style="width:300px;height:50px;padding: 10px;border: 1px solid black;display: flex;flex-direction:row;align-items:flex-start;">
    <div style="font-size:12px;border: 1px solid red;">页头</div>
    <div style="font-size:24px;border: 1px solid blue;">主体</div>
    <div style="font-size:36px;border: 1px solid green;">页脚</div>
</div>

5.2 flex-end 下对齐display: flex;flex-direction:row;align-items:flex-end;

5.3 center 居中对齐display: flex;flex-direction:row;align-items:center;

5.4 stretch 上下拉伸充满display: flex;flex-direction:row;align-items:stretch;

5.5 baseline 子项首行文字对齐display: flex;flex-direction:row;align-items:baseline;

6、align-content 在子项内容排列多行时整体的对齐方式（就是设置行和行之间的排列），（横向说明）分为全部靠上、全部靠下、居中等，IE、Safari、Firefox不支持这个属性

6.1 flex-start 全部靠上display: flex;flex-flow:row wrap;align-content:flex-start;

<div style="width:300px;height:110px;padding: 10px;border: 1px solid black;display: flex;flex-flow:row wrap;align-content:flex-start;">
    <div style="width:50px;border: 1px solid red;">页头1</div>
    <div style="width:50px;border: 1px solid red;">页头2</div>
    <div style="width:50px;border: 1px solid red;">页头3</div>
    <div style="width:50px;border: 1px solid red;">页头4</div>
    <div style="width:50px;border: 1px solid blue;">主体1</div>
    <div style="width:50px;border: 1px solid blue;">主体2</div>
    <div style="width:50px;border: 1px solid blue;">主体3</div>
    <div style="width:50px;border: 1px solid blue;">主体4</div>
    <div style="width:50px;border: 1px solid green;">页脚1</div>
    <div style="width:50px;border: 1px solid green;">页脚2</div>
    <div style="width:50px;border: 1px solid green;">页脚3</div>
    <div style="width:50px;border: 1px solid green;">页脚4</div>
</div>

6.2 flex-end 全部靠下display: flex;flex-flow:row wrap;align-content:flex-end;

6.3 center 全部居中display: flex;flex-flow:row wrap;align-content:center;

6.4 space-between 两端对齐中间行等分布局display: flex;flex-flow:row wrap;align-content:space-between;

6.5 space-around 全部行等分布局display: flex;flex-flow:row wrap;align-content:space-around;

6.6 stretch 行上下拉伸充满display: flex;flex-flow:row wrap;align-content:stretch;

这里我将所有的布局都罗列出来，希望能让大家明白Flex的特点和用法，等到实际开发中有涉及相关内容的时候，再去查阅详细的API即可，子项也有类似的几个属性，用户设置布局和顺序，详细内容请另行查阅资料。
我自己觉得理解了什么是项，看到布局就能比较轻松地将布局切割开来。化繁为简，也有利于理解组件化。将每一个项整理出来，在项目中需要复用的就可以整理成组件。多个项目中能够复用的，就能整理成公用组件。用的高频的还能整理成UI框架。

记不住的话，可以开开发的时候，把这个页面打开在旁边，有惊喜哦！特别是在写小程序的时候，真心好用。

本系列讲述在 React 项目的实际开发中，我们如何通过 es6 的特性以及 React 的特性来实现我们的代码重用，今天是第一篇，初级：

试想我们现在有这样一个需求：

这是一个很典型的在登录及注册的业务场景。在这两个页面中，我们可以看到它们之间的相同之处，同时也有一些不同的点，那么简单抽象以下，我们可以将这两个页面按下面的模块来划分。

这样我们就得到了三个组件，分别是

由于 Header 和 Footer 是纯展示性组件，那么我们可以使用 React 的 stateless 组件。由于「登录」与「注册」的标题以及副标题不一样，所以我们需要传递两个 props 值进来，示例代码如下：

import React from "react";
const Header = props => {
  return (
    <div>
      <h1>{props.title}</h1>
      <h2>{props.subTitle}</h2>
    </div>
  );
};

export default Header;

同样的 Footer 的我们也可以使用该方式来剥离成公共组件。不过需要注意的是，与 Header 只有标题和副标题不同的是， Footer 的左侧内容和右侧内容其实是不是固定的，这个时候我们传递进来的 props 需要更灵活，而 Footer 要做的事情是帮传递进来的组件预留位置，此处我们简单以 left 、 right 来区分，示例代码如下：

import React from "react";
const Footer = props => {
  return (
    <div className="footer">
      <div className="options">{props.left}</div>
      <div className="options">{props.right}</div>
    </div>
  );
};

export default Footer;

这样我们的 Header 和 Footer 就有了，接下来是 Content 区域，与其他两个组件不同的是，Content 里面有个 「登录」或者「注册」按钮，点击后我们需要去触发相关的请求。那这样的组件我们该怎么写，这个时候有两种思路，第一种是组件中将业务逻辑内聚，由于该组件中需要用到 React 的生命周期函数，所以我们使用常规的 React.Component 来创建组件 如下：

import React from "react";

class Content extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      loading: false
    };
  }
  renderType = type => {
    if (type === "login") {
      return (
        <div>
          <input placeholder="帐号" />
          <input placeholder="密码" />
          <input type="submit" value="登录" />
        </div>
      );
    } else if (type === "regist") {
      return (
        <div>
          <input placeholder="帐号" />
          <input placeholder="密码" />
          <input type="submit" value="注册" />
        </div>
      );
    } else {
      return null;
    }
  };
  render() {
    return this.renderType(this.props.type);
  }
}

export default Content;

通过将逻辑内聚到组件的好处是我们有很多的状态是可以公用的，比如密码的正则判断等，但是带来的一个坏处是不太友好的扩展性。但是带来的是在业务中使用的简洁性。

最后我们可以简单的将登录注册以以下代码展示：

// Login
function Login() {
  return (
    <div className="App">
      <Header title={"登录"} subTitle={"欢迎来到"} />
      <Content type="login" />
      <Footer left={'登录'} right="找回密码" />
    </div>
  );
}

// regist
function Regist() {
  return (
    <div className="App">
      <Header title={"注册"} subTitle={"欢迎注册"} />
      <Content type="regist" />
      <Footer left={'登录'} right="直接登录" />
    </div>
  );
}

新知识很多，且学且珍惜。

在选择要系统地学习一个新的 __框架/库 __之前，首先至少得学会先去思考以下两点：

• 它是什么？
• 它解决了什么问题？

然后，才会带着更多的好奇心去了解：它的由来、它名字的含义、它引申的一些概念，以及它具体的使用方式...

本文尝试通过 自我学习/自我思考 的方式，谈谈对 redux-saga 的学习和理解。

学前指引

『Redux-Saga』是一个 库（Library），更细致一点地说，大部分情况下，它是以 Redux 中间件 的形式而存在，主要是为了更优雅地 管理 Redux 应用程序中的 副作用（Side Effects）。

那么，什么是 Side Effects?

Side Effects

来看看 Wikipedia 的专业解释（敲黑板，划重点）：

Side effects are the most common way that a program interacts with the outside world (people, filesystems, other computers on networks).

映射在 Javascript 程序中，Side Effects 主要指的就是：异步网络请求、__本地读取 localStorage/Cookie __等外界操作：

 Asynchronous things like__ data fetching__ and impure things like accessing the browser cache

虽然中文上翻译成 “副作用”�，但并不意味着不好，这完全取决于特定的 Programming Paradigm（编程范式），比如说：

Imperative programming is known for its frequent utilization of side effects.

所以，在 Web 应用，侧重点在于 Side Effects 的 优雅管理（manage），而不是 消除（eliminate）。

说到这里，很多人就会有疑问：相比于 redux-thunk 或者 redux-promise， 同样在处理 Side Effects（比如：异步请求）的问题上，redux-saga 会有什么优势？

Saga vs Thunk

这里是指 redux-saga vs redux-thunk。

首先，从简单的字面意义就能看出：背后的**来源不同 —— Thunk vs Saga Pattern。

这里就不展开讲述了，感兴趣的同学，推荐认真阅读以下两篇文章：

• 《Thunk | Rethinking Asynchronous Javascript》
• 《Saga Pattern | How to implement business transactions using Microservices》

其次，再从程序的角度来看：使用方式上的不同。

Note：以下示例会省去部分 Redux 代码，如果你对 Redux 相关知识还不太了解，那么《Redux 卍解》了解一下。

redux-thunk

一般情况下，actions 都是符合 FSA 标准的（即：a plain javascript object），像下面这样：

{
  type: 'ADD_TODO',
  payload: {
    text: 'Do something.'  
  }
};

它代表的含义是：每次执行 dispatch(action) 会通知 reducer ++将 action.payload（数据） 以 action.type 的方式（操作）++__同步更新__到 本地 store 。

而一个 丰富多变的 Web 应用，payload 数据往往来自于远端服务器，为了能将 __异步获取数据 __这部分代码跟 UI 解耦，redux-thunk 选择以 middleware 的形式来增强 redux store 的 dispatch 方法（即：支持了 dispatch(function)），从而在拥有了 ++异步获取数据能力++ 的同时，又可以进一步将 ++数据获取相关的业务逻辑++ 从 View 层分离出去。

来看看以下代码：

// action.js
// ---------
// actionCreator(e.g. fetchData) 返回 function
// function 中包含了业务数据请求代码逻辑
// 以回调的方式，分别处理请求成功和请求失败的情况
export function fetchData(someValue) {
  return (dispatch, getState) => {
    myAjaxLib.post("/someEndpoint", { data: someValue })
      .then(response => dispatch({ type: "REQUEST_SUCCEEDED", payload: response })
        .catch(error => dispatch({ type: "REQUEST_FAILED", error: error });
  };
}


// component.js
// ------------
// View 层 dispatch(fn) 触发异步请求
// 这里省略部分代码
this.props.dispatch(fetchData({ hello: 'saga' }));

如果同样的功能，用 redux-saga 如何实现呢？它的优势在哪里？

redux-saga

先来看下代码，大致感受下（后面会细讲）：

// saga.js
// -------
// worker saga
// 它是一个 generator function
// fn 中同样包含了业务数据请求代码逻辑
// 但是代码的执行逻辑：看似同步 (synchronous-looking)
function* fetchData(action) {
  const { payload: { someValue } } = action;
  try {
    const result = yield call(myAjaxLib.post, "/someEndpoint", { data: someValue });
    yield put({ type: "REQUEST_SUCCEEDED", payload: response });
  } catch (error) {
    yield put({ type: "REQUEST_FAILED", error: error });
  }
}

// watcher saga
// 监听每一次 dispatch(action)               
// 如果 action.type === 'REQUEST'，那么执行 fetchData
export function* watchFetchData() {
  yield takeEvery('REQUEST', fetchData);
}


// component.js
// -------
// View 层 dispatch(action) 触发异步请求 
// 这里的 action 依然可以是一个 plain object
this.props.dispatch({
  type: 'REQUEST',
  payload: {
    someValue: { hello: 'saga' }
  }
});

将从上面的代码，与之前的进行对比，可以归纳以下几点：

• ++数据获取相关的业务逻辑++ 被转移到单独 saga.js 中，不再是掺杂在 action.js 或 component.js 中。
• dispatch 的参数依然是一个纯粹的 action (FSA)，而不是充满 “黑魔法” thunk function。
• 每一个 saga 都是 一个 generator function，代码采用 同步书写 的方式来处理 异步逻辑（No Callback Hell），代码变得更易读（没错，这很 co~ ）。
• 同样是受益于 generator function 的 saga 实现，代码异常/请求失败 都可以直接通过 try/catch 语法直接捕获处理。

深入学习

最简单完整的一个单向数据流，从 hello saga 说起。

先来看看，如何将 store 和 saga 关联起来？

import { createStore, applyMiddleware } from 'redux';
import createSagaMiddleware from 'redux-saga';

import rootSaga from './sagas';
import rootReducer from './reducers';

// 创建 saga middleware
const sagaMiddleware = createSagaMiddleware();
// 注入 saga middleware
const enhancer = applyMiddleware(sagaMiddleware);

// 创建 store
const store = createStore(rootReducer, /* preloadedState, */ enhancer);

// 启动 saga
sagaMiddleWare.run(rootSaga);

代码分析：

• 8L：通过工厂函数 createSagaMiddleware 创建 sagaMiddleware（当然创建时，你也可以传递一些可选的配置参数）。
• 10L~13L：注入 sagaMiddleware，并创建 store 实例，意味着：之后每次执行 store.dispatch(action)，数据流都会经过 sagaMiddleware 这一道工序，进行必要的 “加工处理”（比如：发送一个异步请求）。
• 16L：启动 saga，也就是执行 rootSaga，通常是程序的一些初始化操作（比如：初始化数据、注册 action 监听）。

整合以上分析：程序启动时，run(rootSaga) 会开启 sagaMiddleware 对某些 action 进行监听，当后续程序中有触发 dispatch(action) （比如：用户点击）的时候，由于数据流会经过 sagaMiddleware，所以 sagaMiddleware 能够判断当前 action 是否有被监听？如果有，就会进行相应的操作（比如：发送一个异步请求）；如果没有，则什么都不做。

所以来看看，初始化程序时，rootSaga 具体可以做些什么？

// sagas/index.js
import { fork, takeEvery�, put } from 'redux-saga/effects';
import { push } from 'react-router-redux';
import ajax from '../utils/ajax';

export default function* rootSaga() {
  // 初始化程序（欢迎语 :-D）
  console.log('hello saga');

  // 首次判断用户是否登录
  yield fork(function* fetchLogin() {
    try {
      // 异步请求用户信息
      const user = yield call(ajax.get, '/userLogin');
      if (user) {
        // 将用户信息存入 本地 store
        yield put({ type: 'UPDATE_USER', payload: user })
      } else {
        // 路由跳转到 403 页面
        yield put(push('/403'));
      }
    } catch (e) {
      // 请求异常
      yield put(push('/500'));
    }

  });

  // watcher saga 监听 dispatch 传过来的 action
  // 如果 action.type === 'FETCH_POSTS' 那么 请求帖子列表数据
  yield takeEvery('FETCH_POSTS', function* fetchPosts() {
    // 从 store 中获取用户信息
    const user = yield select(state => state.user);
    if (user) {
      // TODO: 获取当前用户发的帖子
    }
  });
}

如同前面所说，rootSaga 里面的代码会在程序启动时，会依次被执行：

• 8L：控制台同步打印出 'hello saga' 欢迎语。
• 11L~21L：发起一个 异步非阻塞数据请求（Non-Blocking），初始化用户信息，也做了一些异常情况的容错处理。
• 31L~38L：takeEvery 方法会注册一个 watcher saga，对 { type: 'FETCH\_POSTS' } 的 action 实施监听，后续会执行与之匹配的 worker saga（比如：fetchPosts）。

PS：通常情况下，在无需进行 saga 按需加载 的情况下，rootSaga 里会集中 引入并注册 程序中所有用到的 watcher saga（就像 combine rootReducer 那样）。

最后再看看，程序启动后，一个完整的单向数据流是如何形成的？

import React from 'react';
import { connect } from 'react-redux';

// 关联 store 中 state.posts 字段 (即：帖子列表数据)
@connect(({ posts }) => ({ posts }))
class App extends React.PureComponent {
  componentDidMount() {
    // dispatch(action) 触发数据请求
    this.props.dispatch({ type: 'FETCH_POSTS' });
  }
  render() {
    const { posts = [] } = this.props;
    return (
      <ul>
      { posts.map((post, index) => (<li key={index}>{ post.title }</li>)) }
      </ul>
    );
  }
}

export default App;

当组件 <App /> 被执行挂载后，通过 dispatch({ type: 'FETCH\_POSTS' }) 通知 sagaMiddleware 寻找到 匹配的 watcher saga 后，执行对应的 woker saga，从而发起数据异步请求 ...... 最终 <App/> 会在得到最新 posts 数据后，执行 re-render 更新 UI。

至此，以上三个部分代码实现了基于 redux-saga 的一次 __完整单向数据流，__如果用一张图来表现的话 ，应该是这样：

文章看到这里，对于一个 redux-saga 新手而言，可能会留有这样的疑惑： 上述代码中 put/call/fork/takeEvery 这些方法是干什么用的？这就是接下来要详细讨论的 saga effects。

Effects

前面说到，saga 是一个 generator function，这就意味着它的执行原理必然是下面这样：

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

const iterator = saga(/* ...args */);

// 方法一：
// 一步一步，手动执行
let result;

result = iterator.next();
result = iterator.next(result.value);
result = iterator.next(result.value);
// ...
// done!!



// 方法二：
// 函数封装，自主执行
function next(args) {
  const result = iterator.next(args);
  if (result.done) {
    // 执行结束
    console.log(result.value);
  } else {
    // 根据 yielded 的值，决定什么时候继续执行（resume） 
    if (isPromise(result.value)) {
      result.value.then(next);
    } else {
      next(result.value)
    }
  }
}

next();

也就是说，generator function 在未执行完前（即：result.done === false），它的控制权始终掌握在__ 执行者（caller）__手中，即：

• caller 决定什么时候 恢复（resume）执行。
• caller 决定每次 yield expression 的返回值。

而 caller 本身要实现上面上述功能需要依赖原生 API ：iterator.next(value) ，value 就是 yield expression 的返回值。

举个例子：

function* gen() {
  const value = yield Promise.reslove('hello saga');
  console.log('value: ', value); // value??
}

单纯的看 gen 函数，没人知道 value 的值会是多少？

这完全取决于 gen 的执行者（caller），如果使用上面的 next 方法来执行它，value 的值就是 'hello saga'，因为 next 方法对 expression 为 promise 时，做了特殊处理（这不就是缩小版的 co 么~ wow~⊙o⊙）。

换句话说，expression 可以是任何值，关键是 caller 如何来解释 expression，并返回合理的值 ！

以此结论，推理来看：

• 大家熟知的 co 可以认为是一个 caller，它解释的 expression 是：promise/thunk/generator function/iterator 等。
• 这里的 sagaMiddleware 也算是一个 caller，它主要解释的 expression 就是 effect（当然还可以是 promise/iterator） 。

讲了这么多，那么 effect 到底是什么呢？先来看看官方解释：

An effect is a plain JavaScript Object containing some instructions to be executed by the saga middleware.

意思是说：effect 本质上是一个普通对象，包含着一些指令信息，这些指令最终会被 saga middleware 解释并执行。

用一段代码​来解释上述这句话：

function* fetchData() {
  // 1. 创建 effect
  const effect = call(ajax.get, '/userLogin');
  console.log('effect: ', effect);
  // effect:
  // {
  //   CALL: {
  //     context: null,
  //     args: ['/userLogin'],
  //     fn: ajax.get,
  //   }
  // }


  // 2. 执行 effect，即：调用 ajax.get('/userLogin')
  const value = yield effect;
  console.log('value: ', value);
}

可以明显的看出：

• call 方法用来创建 effect 对象__，__被称作是 effect factory。
• __yield __ 语法将 effect 对象 传给 sagaMiddleware，被解释执行，并返回值。

这里的 __call effect __表示执行 ajax.get('user/Login') ，又因为它的返回值是 promise， 为了等待异步结果返回，fetchData 函数会暂时处于 阻塞 状态。

除了上述所说的 call effect 之外，redux-saga 还提供了很多其他 effect 类型，它们都是由对应的 effect factory 生成，在 saga 中应用于不同的场景，比较常用的是：

• put：相当于在 saga 中调用 store.dispatch(action)。
• take：阻塞当前 saga，直到接收到指定的 action，代码才会继续往下执行，有种 Event.once() 事件监听的感觉。
• fork: 类似于 call effect，区别在于它不会阻塞当前 saga，如同后台运行一般，它的返回值是一个 task 对象。
• cancel：针对 fork 方法返回的 task ，可以进行取消关闭。
• ...等等

其中，比较难以理解的就属：如何区分 call 和 fork？什么是阻塞/非阻塞？这是接下来要讲的。

Call vs Fork

前面已经提到，saga 中 call 和 fork 都是用来执行指定函数 fn，区别在于：

• call effect 会阻塞当前 saga 的执行，直到被调用函数 fn 返回结果，才会执行下一步代码。
• fork effect 则不会阻塞当前 saga，会立即返回一个 task 对象。

举个例子，假设 fn 函数返回一个 promise：

// 模拟数据异步获取
function fn() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve('hello saga');
    }, 2000);
  });
}

function* fetchData() {
  // 等待 2 秒后，打印欢迎语（阻塞）
  const greeting = yield call(fn);
  console.log('greeting: ', greeting);

  // 立即打印 task 对象（非阻塞）
  const task = yield fork(fn);
  console.log('task: ', task);
}