女王控的博客

全部

222 篇文章

插件机制、拦截器、中间件

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

异步异常处理的演进

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

手写 async await 的最简实现

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

Sequelize一对多查询解决方案

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

基于nodemon实现监听文件链接变化

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

0%