格子熊
概览中的内联类型注释的代码示例用错了代码，当前用的是接口的示例代码，应该是内联类型注解的代码
### 前言 在遥远的几个月前，还在上家公司的时候，老板突发奇想，想要搞个代码片段平台，类似于 [snipit](https://snipit.io/)，实现代码片段的复用。本身这个需求并不难实现——简单的前端界面 + 简单的 node CURD，搞定收工，下班回家。 但是，在实际使用中，发现了一个使用痛点——没有在线调试功能，所有代码只能 copy 到本地，在本地进行调试。本着发现痛点就要解决痛点的指导思想，我当时思考了一段时间，希望寻找一个合适的解决方案来完美的解决这个痛点。总体来说，分为两种方案： 1. 服务端构建方案：最常见也是最成熟的解决方案，每次修改代码时，将代码传给服务端，由服务端构建后，最终进行代码替换。由于是在服务端进行打包，所以被称为服务端构建方案。在前几年，客户端涉及到构建问题一般采用服务端构建方案。 2. 浏览器实时构建方案：当前前端最热门的方向之一，在浏览器端进行代码构建，基本不需要与服务端交互（具体分不同细分方案），所以被称为浏览器实时构建。目前各个大厂的 Web IDE 基本采用这种方案。 相比于服务端构建方案，浏览器实时构建方案的优势在于：即时、高效以及最宝贵的——可离线运行（前提是做了合适的缓存方案）。 最终，出于各种因素，最终我选择了浏览器实时构建方案。 ### 浏览器实时构建方案 浏览器实时构建是最近两年前端的热门方向，所以也涌现了一大批成熟的解决方案。 个人总结为：bundle 方案以及 unbundle 方案两种。 #### bundle 方案（类...
每当有人问起：你们的公司的这款应用用户体验怎么样呀？访问量怎么样？此时，你该怎么回答呢？你会回答：UV、PV 巴拉巴拉，秒开率、FP、TTI 巴拉巴拉。 那么，这些数据是哪里来的呢？显而易见，这些数据都来自前端监控系统。 ### 前端监控的意义 当今时代，是一个快节奏的时代，应用的性能极大影响着用户的留存率，没有用户会忍受一个卡到爆的应用。而监控应用性能的重担，就由前端监控系统肩负着。 其次，对于线上应用来说，故障是不可避免的，对于高日活的应用来说，每次故障都意味着大量的损失。试想，如果是淘宝挂了一天，那么损失是多么惨痛。所以，对于开发人员来说，必须要尽早发现线上故障，而不是等到客户打爆客服的电话才发现。线上错误监控，也是前端监控的任务之一。 最后，作为商业公司，需要根据用户行为和数据进行分析，进一步制定各种策略，如果没有各种数据，那么 BI 会热情的找你谈谈人生。而这些数据，也是前端监控系统获取的。 总而言之，前端监控肩负着：性能监控、错误监控以及数据上报等功能，无论对于大公司还是小公司，可以说是必不可缺的了。 今天，我们先来聊聊前端监控中的错误监控。 ### 错误监控概述 一般来说，按照错误监控错误监控可以分为：脚本错误监控、请求错误监控以及资源错误监控。 ### 脚本错误监控 脚本错误大体可以分为两种：编译时错误以及运行时错误。其中，编译时错误一般在开发阶段就会发现，配合 lint 工具比如 eslint、tslint 等以及 git 提交插件比如 husky 等，基本可以保证线上代码不出现低级的编译时错误。大厂一般都有发布前置检测平台，能够在发布前提前发现编译时错误，当然，原理依然和之前所说的类似。 而发现并上报运行时错误就是前端检测平台的本质工作啦，一般来说，脚本错误监控指的就是运行时错误监控。 说到脚本错误监控，你想到的第一个是什么？对，就是 `try...
## 背景 事件的起因在于老板最近的两次“故障”，一次去年的，一次最近。共同原因都是脚手架在发布平台发布打包时出错，导致线上应用白屏不可用。 最神奇的是，事后多次 Code Review，结果还是没有发现任何能够导致该问题的 bug，最后推测有可能是服务器在发布打包的时候出了问题。 当老板第 N + 1 次吐槽因为他写的工程化工具领来的天外飞锅，我突然思考起来，如何才能避免这种天外飞锅。 归根结底，导致这类线上故障的原因都是在于打包上线的代码没有经过验证。针对这个问题，有两种方法可以解决： 1. 治本，由于请求地址不同，预发（测试）版本不可直接发线上，而线上版本缺少了上线之前的验证过程。所以，可以通过在发布系统的预发和线上之间，新增一个 beta 发布，beta 发布使用线上发布的打包流程，不同的是，只允许内网访问，专门用于内部测试。有人可能会问，哪怕添加了 beta 发布，依然无法保证线上发布重新打包的时候不出错呀？重点来了，这种解决方案的核心就在于，beta 发布测试通过后，直接将 beta 发布的打包产物进行线上发布，因为不需要二次打包，所以避免了打包过程中产生新的问题。由于添加 beta 发布需要不同岗位，比如运维、后端、移动端的协作，所以实施难度较大。 2. 治标，既然线上版本上线之前验证不了，那么上线之后立刻回归验证，如果发现问题，立刻手动回滚。正所谓没有人发现的故障就不是故障，perfect！ 正如之前所说的，治本的方法实施难度较大，所以，我们重点关注治标的方法，即上线之后进行回归验证。 说到这里，问大家一个问题，需求上线之后，作为前端，大家会主动进行回归验证而不是等测试进行验证吗？ 不管你们会不会，反正我是不会[doge]。...
## 聊聊 TypeScript 中的类型保护 在 TypeScript 中使用联合类型时，往往会碰到这种尴尬的情况： ```typescript interface Bird { // 独有方法 fly(); // 共有方法 layEggs(); } interface Fish { // 独有方法 swim(); // 共有方法 layEggs(); } function getSmallPet():...
众所周知，在组件式开发中，最大的痛点就在于组件之间的通信。在 Vue 中，Vue 提供了各种各样的组件通信方式，从基础的 props/$emit 到用于兄弟组件通信的 EventBus，再到用于全局数据管理的 Vuex。 在这么多的组件通信方式中，provide/inject 显得十分阿卡林（毫无存在感）。但是，其实 provide/inject 也有它们的用武之地。今天，我们就来聊聊 Vue 中 provide/inject 的应用。 ### 何为 provide/inject provide/inject 是 Vue 在 2.2.0 版本新增的 API，官网介绍如下： > 这对选项需要一起使用，以允许一个祖先组件向其所有子孙后代注入一个依赖，不论组件层次有多深，并在起上下游关系成立的时间里始终生效。如果你熟悉 React，这与 React...
## 聊聊 Vue 中 axios 的封装 axios 是 Vue 官方推荐的一个 HTTP 库，用 axios 官方简介来介绍它，就是： > Axios 是一个基于 promise 的 HTTP 库，可以用在浏览器和 node.js 中。 作为一个优秀的 HTTP 库，axios 打败了曾经由 Vue 官方团队维护的 vue-resource，获得了...
ElementUI 作为当前运用的最广的 Vue PC 端组件库，很多 Vue 组件库的架构都是参照 ElementUI 做的。作为一个有梦想的前端（咸鱼），当然需要好好学习一番这套比较成熟的架构。 ### 目录结构解析 首先，我们先来看看 ElementUI 的目录结构，总体来说，ElementUI 的目录结构与 `vue-cli2` 相差不大： - .github：存放贡献指南以及 issue、PR 模板，这些是一个成熟的开源项目必须具备的。 - build：毫无疑问，看文件夹名称就知道是存放打包工具的配置文件。 - examples：存放 ElementUI 组件示例。 - packages：存放组件源码，也是之后源码分析的主要目标。 -...
### Layout 布局 #### row 布局组件中的父组件，用于控制子组件。很简单的一个布局标签，主要通过 justify 和 align 控制子元素的对齐方式，使用 render 函数通过传入的 tag 属性控制生成的标签。 在这里推荐学习下 render 函数和 JSX 的写法，因为之后比较复杂的组件都是通过 render函数 + JSX 的方式来写的。 ```js // 核心代码 render(h) { return h(this.tag,...
由于之前的 Vue 项目打包成果物一直是嵌入集成平台中，所以一直没有关注过项目的 title。直到最近，突然有个需求，要求点击按钮在集成平台外新开一个页面，此时我才发现，原来我的项目的 title 一直是万年不变的 *vue-project*。理所应当的，这个问题被测试爸爸提了一个大大的缺陷。 犯了错的我赶紧解决这个问题，但是经过一段时间的摸索，我却发现，这一个小小的问题，却有着很多不同的解法。 首先，毫无疑问的是，我们应该使用 `document.title` 方法通过 DOM 操作来修改 title 的值。此时，距离解决问题还差两步： 1. 如何传递 title？ 2. 何时修改 title？ ps：很多人提到过在微信或者一部分 IOS webview （下文一律以微信指代）中无法通过 `document.title` 方法修改 title 的值，这个问题的解决方案在文末的彩蛋中会提及。 ###...