最近工作比较忙，有想写的博客，但是一直没有下笔，想来也是有点懒了，还是要拔拔草。正值金三银四的，面试别人也以 Vue 源码居多，想要还是有必要学习一下插槽相关的内容。 这次的 bug 私以为还是 Vue 本身的问题，先看看一下代码：

// App.js
export default {
  components: {
    ChildContainer: ChildContainer,
  },
  data() {

5 月天空最蓝的时候就想要学习 Vue3 的内容，只是耐心被炎热的夏天打散，代码久久都没有看一行。在工作和发呆中，深圳的秋天好像也来，官网落幕后的国庆，大家都回去团聚的时候，提笔回顾一下 Vue3 的内容，也顺便更新一下博客，算是除除草？今年其实更想的去其他深水区探索一下，只是从去年探索到今年，最后，还是回来看 Vue3 了，也是一种无奈吧。

Vue3

以前的 Vue 像一个黑匣子的，对于开发者而言只是用 sfc 写 template 就足够了，最多偶尔写写 render 函数，灵活度是远远没有 React 方便的。（惭愧，刚没有写几行，国庆又出去玩了，再次提笔已经是 7 号了。。。惭愧）。这次的 Vue3 可以说做的非常彻底，基本把所有 api 都提供出来了，你甚至可以自己写 compile 好的函数。

炎热的七月，透着一点雨水，就这么来临。半年就如此过去了，看了不少内容，但是想写成博客的却越来越少，可能是人懒了。 最近不少工程化的新秀如后浪般出现，虽然不至于动摇 webpack 这个巨浪，只是对行业也有很深刻的影响，觉得蛮有意思，这里介绍一下：

esbuild

esbuild 做的事情很简单，打包压缩，没有其他的复杂功能，目前也没有其他的插件系统，倒是 esbuild 本身更像一个插件，有点像 webpack 刚出来那会的情况。

esbuild 最大特点就是快，飞快，其本身采用 Go 语言实现，加上高并发的特色，在打包压缩的路上，一骑绝尘。官方数据，和正常的 webpack 相比，在打包方面提高了 100+ 倍以上，这对于需要代码更新后立刻发版到线上的项目而言，超级有意义，这不就是大家一直追求的快速构建嘛。

春节呆在家里不能外出，假期又特别长，刚好在学习 nest，于是就看了一遍源码。nest 是用 typescript 写得，用法自然也是基于 typescript，其源码用 vscode 阅读非常方便，基本上是读过里面最流畅的了，只是一个初始化过程，其涉及的操作非常多，逻辑上还是需要捋一捋。直接用 nest 仓库代码阅读调试会发现调试的时候，部分代码引入采用类似下面的方式：

// 在 core 目录下的 nest-application.ts
import { Logger } from "@nestjs/common/services/logger.service";

最近为了新版官网，一直在学习 iphone 11 的效果图，结果越研究发现其复杂度实在远超想象，还要支持各种兼容问题。而我们这次的官网则是要向其学习，其中类似 apple 的翻页的布局是结构的重中之重。

sticky 的翻页效果

苹果官网上采用的是 sticky 的效果，就是 position: sticky 这个属性的兼容性比较一般，基本只有现代浏览器都支持。只是 apple 都用了，其在 ie 等浏览器也做了兼容处理，那为什么我们不试一试翻页效果呢？

没有找到合适的第三方库，于是采用自己摸索的方式，按照苹果的方式按葫芦画瓢，具体的结构大致如下

记得刚做前端，接手移动端 H5 的时候，特别想要将应用优化到极致，想要达到秒开，流畅接近原生的效果，只是业务需求下一直没有时间去做这样或者那样的优化。这次自己接手一个 hybrid H5 项目，做完业务之后，一直想要优化，刚好又是我一个人负责前端，于是将平时的想法收集起来，周六加班做了个深入的优化（可惜才过了四天，就被通知项目要移交到其他团队）。避免涉密，后面的数据，都做了稍微修改。

初始问题

这个项目是基于百度地图做了一个应用，开始存在两个问题，一个是首屏白屏问题；从点击进入到开始到有内容的阶段，有个明显白屏的时间，这个时间是包含 webview 初始化，以及首屏渲染的时间。该首屏渲染的时间，FP 的时间在 Fast 3G 下，大概为 9000+ ms。原本的系统，其实已经做了路由的懒加载了。另外一个百度地图渲染漂移问题。

中后台近几年的发展，已经不满足于简单的手脚架，比如 vue-cli 和 create-react-app，从 ant-design-pro 到 vue-element-admin，提供了各种开箱即用的体验。这些方案可以直接套用，自己需要做的只是写业务代码就可以了，其他的整体架构，包括菜单和权限都帮你搞定了，甚至还有很多很多可以选择的业务模板，一顿微调，一个中后台系统就有模有样了。全套下来比自己从头开始搭质量要高很多，而且至少可以节省一两天开发成本，后期的扩展维护也很方便。

到如今这些开箱即用的解决方案已经显得有些不够用了，中后台的前端，大部分都不需要和移动端一样有严格的 GUI，布局，更多的是日常业务，而这些业务写多了以后，就变成一个个表单，一个个列表，一个个图表，写来写去，给人一种搬砖的感觉，重复劳动，成就感低。

前言

继续前面两篇 react 的分析。提到 react 16，除了 fiber 机制之外，还有其调度机制。这里就不得不提 requestIdleCallback 了，react 采用了 requestIdleCallback 的思想来实现调度，为什么说思想呢，因为 requestIdleCallback 是新出的 api，兼容性差，很多现代浏览器都不支持。于是 react 团队就写了一个 ployfill。

前言

前文提到了一个简单的 react 例子，结构如下所示

ReactDOM.render(
  <h1>Hello World!</h1>,
  document.getElementById('container')
);

只是实在简单呀，缺少 state，缺少状态的变化，于是用另外一个例子来继续研究：

前言

续网络请求后，学习 HTTP/2。HTTP/2 的主要协议 RFC 7540 出来已经三年多了，HTTP/2 的应用也越来越多。几年前还在为 HTTPS 响应速度慢，能不上 HTTPS 就不上，结果现在基本成为标配了。对于大型系统，HTTP/2 也会是这样，毕竟知乎都是 HTTP 2 了。

HTTP/1.1

从 HTTP/1.1 诞生至今，互联网已经走过了十几个年头，当初的 HTTP/1.1 协议出现了不少缺陷，其中管线化，就是其中一个突出问题。

前言

一直好奇网络请求具现出来是什么样子的。从面试官的一个问题，在浏览器输入网址之后，到页面生成，中间会发生什么。为了这个问题，看了《计算机网络:自顶向下》，《图解HTTP》，学习了 node.js 中关于网络部分的源码，结果却还是自认为相差甚远，直到接触了路由表，才开始所有感觉，觉得补上缺失的一脚。

网络结构

OSI 7 层模型定义了一个规范概念，而 TCP/IP 的4 层结构则给出了实现。两者的比较，网上多有资源，这里不做对比了，结合发快递的过程来说说吧：

1. 第七层，应用层，常见协议 Http、Https、DNS、FTP。作用是为应用程序接口提供网络，直白来讲，就是提供请求/响应数据服务。数据也叫做应用层数据 Application Data；在快递上，就是你自己把要发的快递准备好，包括目的地 url 等。

概论

不可变结构是一种很便利的函数式编程的数据结构，也是现代语言标准库如 Clojure 和 Scala 的一部分。其相同的部分是基于有固定数量的子节点的多阶树，允许快速查询和更新操作。在本文中我们采用了一种新的潜在的 vector 结构 Relaxed Radix Balanced Trees（RRB-Trees）。并展示了这种数据结构在 O(logN) 的时间里进行不可变数据 vector 的串联，插入和分割操作，同时维持着和原始 vector 数据结构的查询、更新和迭代接近的速度。

前言

前文《初识immutable》介绍 immutable 的一些基本操作和特色，但是其重点部分结构共享，即数据结构留在了这里。这不是平时接触到的简单的数组、对象亦或则字典的形式，而是 tree ！日常开发基本就遇不到树结构，再复杂一个字典表就可以搞定了，于是乎 immutable.js 提供了一次很好的学习数据结构，学习算法的体验。

共享结构

共享结构还是比较简单的。对于已有的数据结构，若需要更新其中的某个节点（中间节点或则子叶），并不会把整个数据结构都拷贝一份，再修改该节点并返回新的数据结构。immutable.js 里面会采用路径修改的方式来实现更新。

前言

Immutable.js 出来已经有很长一段时间了，只是日常项目中一直用不上。一个是平时没有怎么接触，不了解，另外一个是团队的开发节奏和习惯已经稳定下来了，要改变也不容易。当然了解一下也不差。

不可变的数据一旦生成，就无法被改变，这就要求数据可持久化。可是日常中的引用类型的数据，一旦改变了，就改变了，谈什么持久化数据结构呢？

接触immutable

感受一下immutable的不同：

// 原本写法：
let a = [1, 2];

前言

最近我司要上线一个 Hybird 上的 SPA，17 年年底的时候已经写过 demo 给产品和 leader 看了，近期准备要上线。问题在于，当时准备仓促，又想要玩一玩 react，导致了用的版本是比较成熟的，嗯。。。。意思就是比较老的版本，react-router 是 3.x 版本，而 react 也只是 16.0 而已。对于有追求的我而言，升级势在必行。

问题所在

在 Vue 应用里面用 Vue-router 就是一个 routes 的事情，甚至连 routes 都可以不是嵌套解构，直接一维路由，毕竟业务少。到了之前写的 react 也是采用了这种方式，如下：

前言

前面介绍到 diff 方法，但是我们只是从简单的例子开始的，并没有用到组件，而组件才是最重要的部分，毕竟一切的一切可以是组件。

组件 Component

先看看 Preact 输出的 Component 长什么样子：

export function Component(props, context) {
  this._dirty = true;
  this.context = context;
  this.props = props;

前言

每次看到有人谈起 React 的 diff 机制的时候，总觉得很厉害的样子，所以自然这里也是立马就想介绍 diff 机制。

diff 机制

以下面为例子来介绍：

import { h, render } from 'preact';

render((
  <div id="foo">

前言

在工作上开始用 React 开发已经有四个多月了，不禁想看看 React 和 Vue 本质上有什么区别。当然一个是 jsx 文件，一个是 vue 文件，两个处理起来肯定是不一样的。想了想以后项目发展越来越大，肯定是要以 React 为主体的，深入了解 React 是必须的，尤其是 React 已经发展到 React 16 了，新特性都不晓得怎么用呢。为了减少初学习 React 源码的陡度，想着还是从 Preact 开始好了，毕竟后者声称兼容 React 而且，关键是体积小！

前言

先吐槽。 金三银四，最近来我司计划招聘两名前端工程师，一名初级，一名中级，结果前来面试的人络绎不绝，让我也当面试官，结果呢。前来的有一两年工作经验的初级工程师，都是渣渣，不是基础差，就是广度不够，连笔试题目都做不出来，尤其是算法题目，简单的排序都做不出来。给我的感觉，连刚参加工作的我都不如。而后面试的两个中级工程师，面试后感觉也就比我差点，工作经验比我长点，可是这个期望薪水，是不是有点高呀。只是排序算法题大多用的是冒泡法，作为工程师不应该开口闭口都是快排吗。嗯，只是忽然想想自己也只是知道快排的思想，具体怎么实现，就懵逼了，于是才有了这篇博客。

前言

项目中经常用 Jenkins 构建项目，只要点击构建，服务端就会按照指令，重新拉取数据构建，这是很好的，只是久而久之发现一个问题：项目的构建时间从之前的飞快，到现在龟速。等待构建开发时间长是一个问题，更重要的是如果项目继续发展壮大呢？现在的 antd-pro 项目也就十来个页面，一点也不多，但是测试服构建起来，时间将近4分钟，特别吃内存。如果以后页面多很多呢？五六十个页面呢？那岂不是要二十来分钟的构建时间？内存呢，难道最后要溢出？这是难以置信的。

初探问题

春节期间前有空，上网查了一下方法，webpack.optimize.UglifyJsPlugin 几乎是千夫所指的，自带的代码丑化基本就是鸡肋，用上其他丑化插件，打包时间可以节省上30%，甚至更多，只是 antd-pro 用的是 roadhog.js，是一款接近于 create-react-app 的基础工具，能自己编写的配置参数少之又少，更不要提随意运用 webpack 的插件了。只是想要试探性的玩一下，于是在本地的 node_modules 里面修改了 roadhog 关于 webpack 的 UglifyJsPlugin 插件，结果一试，速度 duang 的一下就上来了。后来由于工作忙就没有怎么 care 构建问题。

前言

几个月前碰巧遇到人生第一个安全问题，在负责的输入部分没有做非法字符验证，于是随便写了个alert('hahaha')，导致保存后再次查看输入详情时，立马弹出对话框。究其缘由，是前端没有做字符验证，服务端也没有做验证，最后输入端采用jsp的后端渲染方式，于是一点开详情，就爆炸了。春节前有空就看了看《白帽子讲web安全》。

XSS跨站脚本攻击

XSS攻击，通常指黑客通过“HTML注入”篡改网页，插入恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。重点就是篡改网页。

前言

项目中遇到的文件下载，上传基本上最常见的事情了。大概半年前，需要实现某表单的查询下载功能，查询还好，只要后端返回数据，我负责展示就好了，但是下载要如何实现呢？用axios的GET请求返回的数据，不忍直视，根本就下载不了。一顿百度谷歌之后，哦，原来这么简单，只要一个window.location.href=url就搞定了，是不是很简单~

文件下载

后来的文件下载我都统统用这种方式，只是下载提示不够明显，后来改为window.open打开个新的tag页，然后自动关闭，明显点下载。好像到这里就已经很完美，一切交给浏览器解决。

前言

这是初识系列的第一篇：stream可读流。刚接触stream的时候有点难以理解，在客户端开发，基本接触不到stream，顶多也就是文档下载的时候，后端返回文件流，这个和stream沾边的东西。如此神秘，自然成为了首个研究的对象。nodejs对象里面有可读流，可写流，还有可读可写流，像HTTP响应Response对象就是可读流，而服务端的是可写流，下面介绍一下可读流Readable。

基本

常见用到可读流的情景是用fs.createReadStream(path[, options])，并通过监听可读流的data与end事件来操作，或则是用pipe方法将可读流的数据流到可写流里面。

前言

前文分析了Vue-router，感觉后劲十足，于是开始分析Vuex。在项目上，Vuex也是常客。它可以很好的管理状态，尤其是跨组件的时候，Vue的单向数据流使得子组件无法修改prop，经常用$emit和$on的话组件是要多难看就多难看。当组件切换，数据需要缓存总不能一直依赖于向上级组件emit传递数据吧？如果要更好的管理状态，Vuex是个很好的选择。Vuex代码量较Vue-router少了很多，而且也没有flow的校验机制，看起来更加习惯了。这里介绍的Vuex版本号为2.4.1。

前言

用了Vue快一年多了(虽然中间间断好长时间)，就越发的对其周边的生态感兴趣，尤其是对Vue-router和Vuex，Vue-router是单页面应用的核心部件，基本上的路由跳转都依赖它，项目上用的比较多的Vonic也是基于于Vue-router的；而Vuex只是在状态变化较多，需要store的时候才用上。本文先介绍Vue-router(2.7.0)，有时间再介绍Vuex；

从示例开始

下面是官方给出的示例basic，清晰的介绍了VueRouter最基本使用方法：

前言

一直想知道Node.js是如何作为一个用js语言写的后端平台。这个设定很是奇怪，前端开始涉足后端了？刚开始用api实现通信的时候，蛮简单的，框架都不用到，简单几句就能实现通信，于是借此机会研究一下Node.js的通信。

从net模块出发

看一个简单的例子

require('http').createServer((req, res) => {
    res.end('hello world');
}).listen(8181);

void 0

最近在backbone的源码(两年前就研究过underscore的源码，现在才看backbone是不是有点那个)，发现里面用到了void 0，这是什么鬼？void居然出现在JavaScript里面，敢情以前用的ES是假的....这么基础的东西，瞟一眼MDN文档，还果然有:

void: 运算符 对给定的表达式进行求值，然后返回 undefined。

So, void 0就是返回undefined了，这不是多此一举？直接用undefined来判断，不就完事了，何必用上void 0，这种云里雾里的操作？

前言

每次用Vue-cli的时候，都会觉得配置的nodejs服务器很是让人省心，几个项目下来，都只用关心工程前端部分，用久了便想探其究竟。后来才发现原理用了express框架，代码也挺简单的，但是里面用的一个中间件webpack-dev-middleware，刚开始看的时候却不知有何用处？既然是express框架，又用的是SPA，路由不需要express来分发，那webpack-dev-middleware有何用处？抱着这样的疑问，看源码去吧

思路

一般express中间件的结构如下所示：

App.use((req, res, next) => {