前言 前端中的库很多，开发这些库的作者会尽可能的覆盖到大家在业务中千奇百怪的需求，但是总有无法预料到的，所以优秀的库就需要提供一种机制，让开发者可以干预插件中间的一些环节，从而完成自己的一些需求。 本文将从 koa、axios、vuex 和 redux 的实现来教你怎么编写属于自己的插件机制。 axios 首先我们模拟一个简单的 axios，这里不涉及请求的逻辑，只是简单的返回一个 Promise，可以通过 config 中的 error 参数控制 Promise 的状态。 axios… »

我们需要一个健全的架构捕获所有同步、异步的异常。业务方不处理异常时，中断函数执行并启用默认处理，业务方也可以随时捕获异常自己处理。 优雅的异常处理方式就像冒泡事件，任何元素可以自由拦截，也可以放任不管交给顶层处理。 回调 如果在回调函数中直接处理了异常，是最不明智的选择，因为业务方完全失去了对异常的控制能力。 下方的函数请求处理不但永远不会执行，还无法在异常时做额外的处理，也无法阻止异常产生时笨拙的 console.log… »

示例 思路 对于这个简单的案例来说，如果我们把它用 generator 函数表达，会是怎么样的呢？ 我们知道，generator 函数是不会自动执行的，每一次调用它的 next 方法，会停留在下一个 yield 的位置。 利用这个特性，我们只要编写一个自动执行的函数，就可以让这个 generator 函数完全实现 async 函数的功能。 那么大体上的思路已经确定了，asyncToGenerator 接受一个 generator 函数，返回一个 promise， 关键就在于，里面用 yield… »

前置知识 需求背景 已知始发站、终点站，如何查出满足条件的方案线路？即根据一个表关联多个表时如何查询相关字段？ sql 语句 根据以上的前置知识可得出一对多下的查询应该这样写： Sequelize 下的解决方案 从表的设计上考虑：将始发站、终点站写在主表中，无需考虑一对多的问题 根据以上的 sql 语句利用 Sequelize 去关联 最终为了实现上的简便，直接使用方案 1 // TODO 多对多方案也需要延伸下 »

项目架构 公司项目分为以下几种架构： 主项目-扩展项目：扩展项目前端独立，是以 npm 包的形式安装到主项目，后端可以独立编译，但不能独立运行，即后端与主项目共用一套，主项目需要对扩展项目编译出的后端代码进行监听来实现增量编译 主项目-子项目：微前端架构，子项目前、后端独立可运行 需求背景 需要解决主项目-扩展项目架构下主项目的后端不能增量编译的问题 技术选型 选型 优点 缺点 直接在 node_modules 目录下开发 主项目已实现对 node_modules 下扩展项目的监听 每次 npm… »