
![bunchee](https://user-images.githubusercontent.com/4800338/98430015-7ce64f00-20e5-11eb-8c64-41addfbd4ede.png)


大约 18 年下旬想要搞一个方便的打包工具，面向的人群是非前端领域，对 JS 没有那么熟悉的做其他方向的 developer 和 research developer。彼时从其他方向 dev 们那听到最多的声音就是关于对各种 JS 语法兼容、语言特性、模块化的疑惑，不像 Java 有很多完整的标准和限制，在工程实践的时候不会有太多不确定的选项。

另一方面，自己组维护的一个很大的核心 library，虽然一直是用 ES6 作为基础语法，但是里面还是掺杂了许多 ES5 甚至跟老的语法。它下面依赖了一些其他组提供的 npm 包，有的是 UMD 有的是 CommonJS；有的全部 dependency 都打包进 dist，有的只打包了自己的 source。在这样百花齐放的情况下我决定做一些简单的 align，让大家尽量使用同一套工具链，减少在这方面花费的经历，让 researcher dev / dev 专注在自己实现的算法和功能上。

### Pick 一套通用的语法集

除了某些很古老的文件还是用了 ES3，大家大多数都在使用 ES6，没有使用到 ES6+ 更多的未完全从 stage x 走到稳定的语法，比如 decorator（因为都不是 react UI 的 lib，基本上都自己写 bind 了）。为减少语言上的心智负担，我采取了下面的措施：

写了一些简单的 codeshift 的脚本，把冗长的老 code 先转化成 ES6（比如用 function 实现 class，用 defineProperties 定义 getter / setter 的 code 都转化成 ES6 class + getter / setter）
限制只使用 ES 在 tc39 进入稳定阶段的语法。因为其实现阶段对我们完全足够，很多算法功能或者实现一些其他非 UI 相关功能的库并用不上太多 fancy 的语法。让非 JS dev（如 research 的，做数据的）可以专注他们要想的事情。
依旧只支持 JS，因为他们没有使用 TS 的打算。[Lea 的这篇文章](https://link.zhihu.com/?target=https%3A//lea.verou.me/2020/05/todays-javascript-from-an-outsiders-perspective/) 更加坚定了我不给其他 dev 提供过多复杂选项的想法

### 选取制作打包工具的库
由于是 browser runtime 的 library 和 npm package 为主，不太存在需要单文件（无依赖）执行或者需要打包成单文件在浏览器跑的 JS。

打包（Bundler）: 决定选用 rollup，剩下的集成和到底打包成什么其他格式，留给应用层的 webpack 去思考。
编译（Compiler）：这个比较有意思，开始选用了 babel v7，但是想来想去如果有人装了 v6 的 babel-core 在外面或者自己配了其他 babel plugin 产生了冲突和 side effects，那么编译出来的东西还是不太好控制。开始我发现了 bublejs ，一个轻量级的 ES6 到 ES5 的编译器，底层也是 acornjs，但支持的显然不是 babel 那么灵活和广泛。
再后来 babel 到 v7 后，由于 buble 本身的一些限制（比如现在还没支持 generator），还是决定切换到 babel。然后又加上了 ts 的支持，让他也可以打包 ts，这样也算解决了很多喜欢使用 ts 语言朋友的问题了。

所以最终的工具链是：rollup + babel (presets + plugins) + ts

### 如何使用
使用方面借鉴了 developit/microbundle 的使用，可以在 package.json 里指定各种 format 的dist file 路径，如 "mian": "dist/bundle.js" 然后用 bunchee 的 CLI 去编译源文件入口就行了。e.g.

```json
{
  "main": "dist/pkg.cjs.js",
  "module": "dist/pkg.esm.js",
  "scripts": {
    "build": "bunchee ./src/index.js"
  }
}
```

但是我只支持在 main 和 module 两个字段，即只支持 ESModule 和 CommonJS。原因是我觉得既然是 library，做成 ESModule 是最有利于 treeshaking 等优化，以及最后的输出形式应该还是在 application 那块控制。module 和 main 是 webpack 可以认的 main fields，其实也可以支持 "browser" field，但是我觉得不应该所以没有支持。browser field 太灵活了，也不知道你文件到底是什么 format，umd/amd/cjs... 我选择迎合了新标准 ESModule，也给提供 CommonJS 的机会。

@尤雨溪 老师最近在做 vite 的过程中应该也遇到了类似的问题，package.json 里 browser field 指向了一个 cjs format 的文件。因为 webpack 能支持的太多了，我们的使用就变得越加地随意

当然也支持你使用 bunchee CLI 直接指定输出形式，这里我选择支持了 UMD，可以和 rollup CLI 一样使用 bunchee --umd -o dist.umd.js 来输出。原因是手动执行有更多的灵活性，并不和 package.json 中的 main fields 字段绑定，你可以拿来做其他的比如在浏览器中运行的测试。

打包出来的文件不需要压缩，如果有压缩混淆需求，还是交给集成 npm package 的 app 来处理。

实现其实很简单，感兴趣的可以看一下 github repo huozhi/bunchee 或者直接用 npm 上下载使用，就不过多介绍。

### 开源相似品对比
开源的其实也有很多 zero-config bundler，比如 parcel 面向的是 application，还有 microbundle 面向的是 library，还有 vercel 的 ncc。

#### microbundle
排除面向 app 的，我觉得没有使用 microbundle 的原因还是因为它做的事情太多了，依赖也很重。里面有 buble 又有 babel，还有 typescript 的支持，甚至默认使用了 terser 做压缩，还有一些给 package.json 加的字段如 source, esmodule, etc. 虽然只是 dev dependecy，但我还是觉得太“重”了，在 zero 的基础上又给了外面用户各种配置的选项，有点不够 zero。当然我很喜欢它，确实十分便利。

#### ncc
ncc 会更加复杂一些，而且 ncc 使用了 webpack 且主要面向 nodejs，我不是很喜欢 webpack 编译出来的语法，感觉为了处理各种 module 的情况做了很多兼容，而且 webpack 很重。对于一般的小 lib，ESModule 完全足够，只支持它也是希望限制大家随意使用包格式。

我个人比较崇尚 minimalist。像做菜使用最灵活的小刀完成各种切割任务，大菜刀对我来说还是有点麻烦，所以还是选择自己做了。

### 自举
在看给 @vercel/ncc 贡献代码的时候无意发现 ncc 是可以自己编译自己的，就想到是不是应该也可以让 bunchee 自己打包自己。最后经过一番折腾，将 bunchee 分成了 bundle core 和 CLI 两部分，CLI 会调用 bundle core 来实现打包，最终完成了自举。最新的 bunchee 也是用上一个版本的 bunchee 自己打包发布的。

大概就是这样。


制作一个简单的 JS/TS 的零配置打包工具


> 「开源」指开放源代码，任何人都可以访问，并根据协议进行不同程度的使用。整个 web 在开源圈一直很活跃 —— 前言

## 介绍一下 ZEIT

说起 zeit（现在叫 vercel）可能很多做 web 的人都听说过，zeit 是一家很小的公司，整个团队只有三十来人，但是却产出了大量优秀的开源作品，他们的各种 js lib 支撑了无数网站和应用。代码精致，小且优美，包括他们简洁的设计在内，很多都像小巧的艺术品。去年在知乎上突然看到了一篇回答，「[zeit.co 是一家怎样的组织？](https://www.zhihu.com/question/59278159/answer/813629215)」，回答者是 @shuding，zeit 目前在中国大陆唯一的员工，这两年一直在 remote 工作。

![image](https://user-images.githubusercontent.com/4800338/87217790-ad102200-c37f-11ea-88a8-36e77540b37f.png)

<sup style='display: block; text-align: center'>zeit github page</sup>

zeit 的平均年龄都很小（感觉很多 20 多岁的人，写这篇文章的时候），成员几乎来自世界各地。远程工作、时差讨论，随意切换工作地点和工作时间。我一直深怀羡慕。去年年底的时候在 github 上关注了他们几乎大半个 team，看了很多人的主页、code 和 design 作品，都是简洁又独特。

## 定义「参与」开源

一次在 twitter 上回复 shuding 的一条技术思考，然后收到了回复（提到了他在做的 swr 这个 lib）和突然的回粉（？？？），算是认识了。
某天突然看到了 zeit 另一个成员 @timneutkens 的一篇采访，他讲了他自己如何从一个大学前的实习状态（好像是荷兰政策的要求）开始给 next.js（zeit 最风靡的作品之一）贡献代码，然后成为核心 contributor 最后加入的经历。他提到最重要的一点就是，从帮助别人开始，哪怕不能修复 bug，回答问题也算是一种宝贵的贡献和帮助。

自己平时喜欢做一些小工具，或者很基础的 js lib 然后挂在 github 上，但基本上全靠野生的 star，所以也一直无人问津。一直只在制造东西但是未曾参与项目的我突然醍醐灌顶，可能对「参与开源」的认识需要变了。开始在 zeit 的各个仓库的 issues 里翻来翻去，最后发现只有 swr 差不多能很快上手帮忙修修 bug，然后在放假的时候搞了一下提了几个 PR。

其实如果放在几年前可能还是没有办法这么做，大家总说得很轻松可以给开源项目贡献 code，但其实对国内的软件工程师真的没那么方便，因为英语确实是一道坎 -_- 。。。现在勉强可以快速能看懂别人的问题，然后解答，或者帮忙修复。慢慢持续了一段时间之后，被 @shuding 拉进了某个聊天组，开始有机会实时交流一些项目上的想法，还有闲聊了很多关于开源和他 remote 工作的经历。甚至还发现我们都曾出现在 hackshanghai (2014 & 2015) 两次活动的现场...

慢慢感受到了，原来还可以这样玩。开源不止是写，还有维护、社区、推广、教学...比我想象的要多的多，社区也比我想象中要更复杂和活跃。收到陌生人提的 issue 或者建议，还有各类问题，评论后等待异步回复的消息，所有人都在跨着时区交流...如果你希望体验一下，找一个你喜欢的仓库，成为一个 contributor 试试看，真的很有趣。

![image](https://user-images.githubusercontent.com/4800338/87217708-e7c58a80-c37e-11ea-8934-bbc0d7c54611.png)

<sup style='display: block; text-align: center'>参与 contribution 的这段时间，star 也涨了好几 k 的样子</sup>

## 他们是独立的

我之前一直觉得有时候关于这些专业、兴趣的交流很少，总感觉很寂寥，没有一个社区或者圈子一直在热火朝天地聊某个事情，所以很多东西才很难做出来。但后来发现，正是在和这些一个个犀利的，又非常独立的工程师交流后，才发现正他们往往都是非常独立的。在现在这个十分内卷的环境里，大家都渴望努力、晋升、赚钱然后做出成绩，而他们很多人并不是这样想的，他们选择了一条很有意思的道路，一路上都在追寻自己喜欢的东西。

有时候我又在想，如果我也像有几个年轻人一样，没有选择去上大学，我会在做什么呢？可能没什么，因为当时的视野太狭小了。而我现在看见他们，羡慕的不是他们的能力或者成绩，而是他们对自己决定的信心，it's cool so let's do it! 离开校园后好像我已经忘记了这种感觉。我也想尝试一下只做自己喜欢的东西，而现在需要再找回「喜欢某件事情」的力气。

可能你在惦记 remote 工作的时候，真正在 remote 的人已经惦记起了独立开发，等到你 remote 的时候你可能又开始羡慕。到底怎样选择才会让自己平静且快乐呢？我想就是一直去探索更多的选择，找回分辨自己厌恶和追求的能力，试一试不一样的生活。

## 小厨房「广告位」

![image](https://user-images.githubusercontent.com/4800338/87222393-d2b02200-c3a5-11ea-8f62-0be74c76d47a.png)

<sup style='display: block; text-align: center'>给小厨房画的 logo</sup>

最近也在找点别的乐趣。在给自己的小厨房开了一个账号，宣传一下 [ins: huozhi.food](https://instagram.com/huozhi.food/)， 欢迎关注 😉




什么才算开源？到底为什么要参与开源？

隔着屏幕的朋友 - 开源参与小记


![image](https://user-images.githubusercontent.com/4800338/80297169-657fee00-87b3-11ea-9efe-9573f3534462.png)

## 用 PPT 也可以画图

我记得那是大二刚开学的时候，科协准备给新生进行简单培训，我被分到讲 PPT 的教学。当时毫无想法，我问 @honka 有什么特别的技巧可以传授，他说只要让大家觉得和基础操作有些不一样就好了。

于是我画了大约一周在晚上空闲时间研究 PPT 能做什么。在发现普通的「直线」可以进行编辑定点的这个功能后，尝试做了一些基础的图形，然后在剩余的时间，用曲线拼凑出了一张「贝吉塔」。从此通过 PPT 打开了新世界的大门。

那几天座位两旁的 @Du 和 @YY 一直在疯狂看 Android，因为马上就要去参加一次 hackathon。准备比较仓促，从图书馆借 Android 的书突击入门。现场手忙的开发后组织决定将最后制作 Slides 的任务交给我，他们俩继续在酒店的小茶几上疯狂学习 Android 小知识。这次我们做了一款「蜂窝输入法」，我们的队名叫 CloseType。（前一阵和 @Du 的聊天提到这次经历，突然十分怀念）

###### 「贝吉塔」和当时 hackathon 的某页 slide「蜂窝输入法」 👇

![image](https://user-images.githubusercontent.com/4800338/80288523-1a41ed00-876b-11ea-8f2c-33e0498026d1.png)

之后在大学的期间我开始大量使用 PPT 作为所有画图的工具。一是当时孱弱的设备只能带得动一些 Windows 上的常规软件，二是当时并没有「UX 设计」概念这回事，对真正的设计工具并不了解。

## Sketch 💎

第一次加入正经的前端 team 是在知乎实习的时候，首次接触设计稿从「中文验证码」的项目开始的。那时候才知道原来从产品概念到 UI 形象，是有另外的设计工具来参与，那就是 Sketch App。Sketch 是一款设计工具，只支持 Mac 且需要付费授权。当时整个设计 team 和前端 team 依靠 sketch 文稿来沟通设计图和细节，Sketch 的付费授权是一次 $99，大约可以撑 2 年左右，设计 + Dev 们人手一个 Sketch 授权还是挺不方便。加上设计稿的版本同步，搭上了 dropbox，google drive 一起操作，还是很麻烦。

后来慢慢地有团队开始迁移到 Zeplin，设计师依然用 Sketch 设计，但上传到 Zeplin，工程师可以通过网页来 inspect UI 细节，比设计稿更贴近代码（因为毕竟不需要工程师修改设计原稿），然后也解决了需要安装授权 Sketch，同步设计稿也变得简单。Zeplin 作为中介，使得工程师或者设计师以外的一方不再需要跟设计工具打交道，只跟「设计交付工具」沟通。

再后来到 Hulu 使用 inVision 查看设计稿，发现和 Zeplin 走的路线也差不多，对外面屏蔽了设计工具的细节。

## Figma 🌈

真正让我开始发愁生产效率的是给自己的博客设计 icon，发现使用 Mac 但没有 Sketch 的话完全没有趁手的工具。但是突然想起来自己的电脑上有 Windows XP 虚拟机，就进去找到了「画图」工具，给自己粗糙的画了第一个 icon。

后来有一次和同事聊天突然说到 google slides 可以画些简单的图，才想起来还有云版 PPT 可以代替，于是开始使用 google slide 代替「windows 画图」进行 icon 编辑。第二版本做完后，发出去后收到 @xinyu 的回复：「可以试试 Figma，免费又好用」。我突然回忆起这个好像被设计师们偶尔谈论过的工具。在打算制作第三版 icon 的时候我终于开始使用它！

###### 从第一版「画图」工具制作到第三版 Figma 制作

![image](https://user-images.githubusercontent.com/4800338/80288995-36935900-876e-11ea-8cea-1fbe58ecf84c.png)


## Daily UI Challenge

看到推上 @shuding 提到了一个 [Daily UI 100](https://www.dailyui.co/) 的挑战，100 天有 100 个设计 idea 让你来做，有的是一些比较零碎的组件，或者只是一个简单的页面，随你发挥。觉得可以帮助自己练习一下使用设计工具，然后果断订阅了这个活动。在每个工作日会收到一封邮件，包含一个 idea，诸如设计一个登录表单，或者一个计算器等。对于如何用 code 实现对自己来说已经不重要了，所以这次只注重在画图和表达出一些特殊的思考在里面。

我会随机选择一些挑战来做，并不会每个作业都完成，可能有想法地或者比较适合练习的就优先进行。设计确实很耗时，且当我制作一个很简单的图稿时，甚至算不上设计的全部流程，只是其中一个很小的阶段。最麻烦的就是你经常会想要修改你的 idea，修饰一下这里优化一下那里，这里调两个颜色那里改三个字号。两周期间在画别的图稿的同时，也来来回回地在修改第一张稿子「登录表单」，下面这张图从左到右见证了它从最初版（左）到最终上传到 dribbble 上（右边）经历的一些变化：

![image](https://user-images.githubusercontent.com/4800338/80288169-b8808380-8768-11ea-8fb5-2445f8daeaef.png)

不停调颜色真的是让人眼瞎的工作。上传结束的那一刻我突然明白了些什么，设计师每次要不停修改不停优化设计稿，甚至要为某个平台上无法实现的效果来裁剪自己的设计时的艰难。有时候灵感不总是在开始才来的，它可能在你做完的几天后才出现，也可能一直不来。也有点像在 code review 时遇到一篇巨大的改动，反复 review 几轮才发现更深入、更需要修改的问题；亦或是产品上线前突然想 polish 一下某个小细节。

## Learning Through Practice

对自己来说这可能只是一个开始，有机会尝试一些一直想尝试的东西。今天恰巧看到了一篇 zeit 成员接受采访的[文章](https://www.welcometothejungle.com/en/articles/btc-interview-tim-neutkens-next)，提到了自己 learning through practice 的经历，觉得这也蛮不错的。我发现我真的很喜欢 zeit 这个团队（现在改叫 vercel），但看他们成员的经历确确实实带给我了一些灵感。

想看其他设计内容，或者想监督我的 Daily UI Challenge 可以去我的 [Dribbble 主页 - huozhi](https://dribbble.com/huozhi) 看我上传的图稿。莫名高兴成为了 Dribbble Player，好像又和世界连接在了一起。

很多技能的入门并不要求你有一份科班的证明，如果想做可以尽快尝试起来。送给所有还在犹豫尝试某件事情或者想学习某个技能的人。



开始 Daily UI 100 Challenge，记录一些尝试使用设计工具画图的感受

UI 设计初体验


## Positioning Problem

You might heard lots of sayings of positioned component, such as popup, tooltip, popover, overlay...
they have the common way that you need to position it when you trigger it.

To generalize the problem, thinking deeper, we can encapsulate the components into 2 things: a trigger which you might press or hover in; and a overlay which positioning relatively to the trigger. it might be a tooltip, a popped dialog.

Since I'm using React.js, so I'm going to design it as a react component to solve my positioning problem, and share it as foundation among the overlay-like components. Pure logic, without any styling.

Then I came out the basic idea of the API. The single child component is the trigger, the we pass the overlay component as a prop to `OverlayTrigger` with the `placement` position in string literal. It will get rendered with accurate position once hover or focus on the button.

```js
<OverlayTrigger
  placement='top'
  events={['hover', 'focus']}
  overlay={<span>tooltip</span>}
>
  <button>hover to trigger tooltip</button>
</OverlayTrigger>
```

The result might look like this

![image](https://user-images.githubusercontent.com/4800338/70851736-eeb51900-1ed3-11ea-8ca6-6eea6fdad10b.png)
## How Gonna It Work?

1. We got the the `trigger` get mounted on the DOM;
2. We mount the `overlay` to DOM when we interact with it (hover or focus)
3. We position get the position & size by `getBoundingClientRect` API of above components, and change the position of overlay to close to trigger with specified placement.

pseudo code like the following

```js
function position(overlay, trigger) {
  // after both get mounted, get the positions and sizes
  overlaySize, overlayPos = getSizeAndPosition(overlay)
  triggerSize, triggerPos = getSizeAndPosition(trigger)

  // move overlay near to the trigger
  rePositionOverlay(...)
}
```

There's might also have a root element which you want to hook your overlay on, by default, it's `document.body`.
Then you can position it with `fixed` or `absolute` layout and the `top`, `left` distance.

Sounds easy, with couples line of the code. Then I tried to integrate it with my app...

## Hover is Not Equal to Mouse Enter 🤦‍♂️

We had the very basic usage of the tooltip, show up when your hover on some icons, dismiss when you hover out. I looks pretty well when I test with the desktop devices. When I open the surface, Oh flicking....

- Can we just disable tooltip when touch screen detected?
- No, we can't, if you want to use `navigator.maxTouchPoints` to detect touch screen, you'll get wrong result on Edge.
- Oh, ok, Edge, alright...

Let's try to solve it by browser events. Back to the topic on my previous blog [Universal Scrubbing Experience on Web](/post/universal-scrubbing-experience-on-web/). In a word, if you try to capture hover actions by **mouseenter** and **mouseleave** events, that's a trap.

Use `PointerEvent` on the browsers supported and use `MouseEvent` on the ones which don't have `PointerEvent`.

The trigger handlers finally become like this

```js
// if `hover` is specified in trigger `events`
onMouseEnter() {
  // match desktop safari behavior
  // mobile safari won't trigger any mouse event while touching
  if (!window.PointerEvent && !window.TouchEvent) {
    this.showOverlay()
  }
  // ...
}

onPointerEnter(event) {
  // match desktop/mobile browsers which support PointerEvent
  if (event.pointerType === 'mouse') {
    this.showOverlay()
  }
}
```

Looks like we're done now? But soon I found there's something wrong...

## Wait, the Size of Trigger and Tooltip Might Change

If just play with hover you won't have this issue, maybe. But triggers' size do change, positioning only on **did mount** phase is not enough, **did update** is required as well.

Then question comes, how do we really know if there's any internal state change happened inside children and overlay components.
If we pass down any prop like `onSizeUpdate`, that's kind of tricky no one knows the root cause of resizing is class name changing or due to DOM tree updates.

#### react-bootstrap \<OverlayTrigger /\>

After checking how the popular UI components library solving this problem, like react-bootstrap, ant-design, I found that react-bootstrap pass down a function prop called `scheduleUpdate` to trigger, that let trigger be able to forcedly enqueue an repositioning task when it's necessary. It's quite convenient, but we need to omit this function prop on trigger when we don't need it or when we spread all props onto it.

That's kind of inconvenient, since there're still few DOM props like `onMouseEnter` and `onClick`, been passed to trigger implicitly.

#### ant-design \<align /\>

Ant design align component use **ResizeObserver** to track trigger size change. Unfortunately **ResizeObserver** is not widely supported. When I write this post, https://caniuse.com/#feat=resizeobserver shows that ResizeObserver is only supported on latest tech preview version and mobile safari doesn't support it. Ant design included a polyfill for it to get rid fo resize observer usage.

If we don' care about the bundle size very much, resize observer polyfill could be a choice. However I do care :) ...

Finally I came out a idea, that we use ResizeObserver when it's available, and fallback to **MutationObserver** on some unsupported browsers. With MutationObserver, the approach is to monitor cache the size and invoke callback when size gets changed.

```js
function createObserver(node, onMeasure) {
  if (window.ResizeObserver) {
    const ro = new ResizeObserver(() => onMeasure())
    ro.observe(node)
    return ro
  } else {
    const cachedSize = {width: 0, height: 0}
    function handleMutate() {
      const {width, height} = node.getBoundingClientRect()
      if (cachedSize.width !== width || cachedSize.height !== height) {
        cachedSize.width = width
        cachedSize.height = height
        onMeasure()
      }
    }
    const mob = new MutationObserver(handleMutate)
    mob.observe(node, mutationObserverOption)
    return mob
  }
}
```

Now, we keep the API as simple as possible, and make the implementation as small as possible. I think we solve the most annoying issue :)

## Repo & Demo

Checkout the source code on https://github.com/huozhi/react-overlay-trigger or use it directly with `npm install --save react-overlay-trigger`.
I also provide a playground that you can try it with different devices/browsers. https://react-overlay-trigger.vercel.app

From [bundlephobia](https://bundlephobia.com/result?p=react-overlay-trigger) we can see it's only 2kb after minimized and gzipped. Small enough, and fit for general situations. Whatever you want to pop with your trigger components.

Hope you'll like it, issues & PRs are welcomed!


Fun journey of building a overlay trigger library with react and how I handle the various scenarios

Positioning Component in React


![IMG_7815](https://user-images.githubusercontent.com/4800338/67867708-c52f7080-fb65-11e9-81fb-c5fbc78fb632.JPG)

## Shun 利开始

故事要从我刚刚走进办公室的第一天早上，9 点在工位上我还很困，一会儿走来了一个穿着衬衫和皮鞋的年轻人，戴着眼镜，气质十分正经，正经到使我突然意识到可能今天都不太适合听任何 rap，我们打了招呼，然后我知道了他叫作 Shun。

彼时「强汉」二人尚未到来，让我以为这里的年轻人都是这样的风格，直到中午全员到齐，我才知道除了穿迷彩服的导演、穿拖鞋的相声表演艺术家等人之外，Shun 有着唯一的皮鞋，表情有些严肃，偶尔推一下眼镜，整个人都像是被 java 编译出来的。充满了学术气息，但笑起来又不失俏皮。

## 午餐

随着交流的增多，我从 Shun 的朋友圈中看到了各种各样的技术分享帖，他的独特之处是经常会自己分享后并加两个「👍」，根据我迟钝的观察，赞也经常使用 QQ 表情，几乎不会选择 emoji。每次看到这里，就觉得 Shun 的皮鞋多了几分光彩。

我常把看美食作家王刚做菜的视频或者链接分享给 Shun，他啧啧称赞点头，似乎觉得这个年轻人很有前途。此后常常很开心的告诉我又用了「宽油」做了晚餐，还注册了川菜馆的会员，Shun 摸着微微隆起的小腹，「似乎该吃沙拉了」。

随着 Shun 成为小组的扛把子也变得越加忙碌，直到有一天我们一同 TB。回来的路上，他伸了个懒腰，皮带和衬衣努力地包裹着腹部，他说：「我们来建一个沙拉群吧」，我擦了擦嘴角的宽油，连连道好伸出二维码。然鹅距离建群不到 24 小时，Shun 将「沙拉群」重新命名为「王刚美食群」。

终于在下周一上班午时，组织了首次沙拉聚餐。Shun 吃了不到十五分钟：「肉我吃完了，菜我吃不下了」。后来就很少看见他在群里出没。我甚至无比怀念那些中午，觉得年轻又有活力，活力到偶尔会发一些自己练习跳舞的视频到微信。Shun 吃沙拉的时候也会看看，说不错不错 rap 跳得很好啊，我说哪里哪里还是得学学篮球，qiang 在一旁眯着眼看着他酒红色的索尼手机，脸上泛滥着成熟的微笑：「你对 Kun kun 很了解啊」。

## 专注

我每次路过他们工位附近都会看见 Shun 拖着下巴，间歇性使用小拇指头摩擦鼻翼两侧，似乎在思衬着数据的流向但又不失划水的随性和信念之坚定。如果你上前打断他问他一些问题，他会以「这个问题非常有趣」开头，通过打开数据查询平台加载卡顿的页面，来为自己的精细分析做出短暂缓冲，在你还没反应过来的恍惚之间他就会为你准备好你可能需要的所有内容。

![IMG_9328](https://user-images.githubusercontent.com/4800338/67868451-f78d9d80-fb66-11e9-8dce-029db83e1aa6.jpg)

Shun 可以解决一切问题，且负责到发指。那次还是我去 US office 出差的时候，晚上十点钟困到电离，准备亲亲白白的小枕头睡觉时，被北京的同事叫起来：「发布出问题了，只能你来搞」。我打开发布平台，看着里面所有字母都认识但一行都看不懂的委婉报错，只得求助 Shun...没想到最后一路折腾到了凌晨两点，倒时差加脑路灼烧已经心力憔憔悴。
组里的同事也安慰说：「实在搞不定就延期一下吧，没事的」，我能想象此刻北京 Shun 在计算机旁用下巴压着比心的食指和拇指做出沉思的样子。
- 我：「Shun，这边 2 点多了我有点扛不住了，要不我明天再看？」
- Shun：「别睡啊，我们来解决它」

他说这句话的时候是不会呐喊的，而是一种责任与信心，就像他在朋友圈分享「干货：老司机的自信，让 CDN 加速」一样，自然流露，虔诚笃定，令人信服。我心怀感恩，彻夜未眠，最终在天亮的时候一起解决了这个问题。我想那晚 Shun 的宽油一定吃得十分香甜。

## 背后有人

Shun：哎，话说你们最近周末在家和男女朋友都玩些什么呢？
- A：喔，就出去逛逛街吧
- B：刷淘宝啊，Shun 你呢？
- Shun：我最近在教妹子写 java
- 我：那你妹子还真是有点硬核啊

你们知道催婚真的很俗，我们能守住节操不去问，对 Shun 则是有人开启了调侃模式就架不住大家起哄。
2017 年的时候，Shun 回了家，说快了快了；
2019 年的时候，Shun 已经不知第几次回了去，说快了快了；

Yicheng 一敲盘子，「怎么，去人家家里面试了那么多轮还没给过啊？」
- Shun：「唉，加面了啊」
- Yicheng：「现在什么进度了？」
- Shun：「快了快了，就快签了」

## 别筵

我又想起了那天在谁的告别晚餐上，大家在疯狂撸串的期间，只有 Shun 在认真阅读「支付宝很工程师谈如何成为一名优秀的程序员」，我说过那不是刻意，而是自然流露。我们给他评论「快喝，赶紧干了」。热闹的点赞里，有人以为这是一篇实时好文，有人是在享受起哄的欢愉，这是我们的自然流露，而 Shun 则一直在专注地思考未来。如果他的手指不在拖着下巴，就马上拖到了下巴。

我不想写太多，可能我也再听不到「这个问题非常有趣」的开头了，大家交杯换盏，神采奕奕但似乎又多了一层下巴。如果说同他学到最多的东西，大概就是温和吧。


名正言 Shun


很久没写过一篇游记了，决定把这半年多除了出差的旅行记录一下。

## 意外的风景

我其实没想到会喜欢上俄罗斯，平时的教育和宣传，以及语言的不通，一直让我认为我肯定不会去这样一个国家。之前总往热的地方跑，渐渐地想干脆去一个冷一点的地方。就这样，本来只认识一个红场和听过列宁格勒保卫战的人稀里糊涂上路了，第一个目的地不是莫斯科，而是圣彼得堡「St Petersburg」。

落地的时候是早晨，拖着疲惫和行李吹着湿润的雨后小风，来到住处并前往了第一家餐厅，「苏维埃 coffee」。

很难忘的应该是潮湿的空气加雨天，还有很多可爱的小肥鸽子，像极了印象中我以为俄罗斯小胖仔的样子。而圣彼得堡还是着装很在线的一个城市，街道两旁的石头盖起的大楼已经比较沧桑，不过还是非常结实地支撑着这个城市大多地标建筑和民宿。刚以为沉浸在年轻的气息里，就被飘来的烟呛到不行，眼睛一眯，远处教堂升起的烟雾仿佛全部来自四周的烟嘴。

超市里的香肠，餐厅里的鸡肝，饭馆里的饺子，带给了我非一般不消化的饱足。擦嘴起身的瞬间，特别想后面连吃几天沙拉救救自己。在这里吃饭是不能点很多的，因为一小碗红菜汤已经满溢着热量，呼吸的时候，放进汤里的酸奶油都能飞起来敷你一张面膜。我决定多花一些时间在寒风里，跟着步行的外卖小哥走过夜色下的繁华街道，让身体多一些消耗，肠胃多一些蠕动的机会。

![image](https://user-images.githubusercontent.com/4800338/61185412-cd819f80-a68b-11e9-9406-eea0a262fadf.png)

我没想到自己文字原来这么匮乏，博客无法把诸多录下的街头表演视频放在这，我很难形容出乐队的精彩，加上主干道上的电车，和乐队身后的教堂，所有时代的影像重合在一起。我很喜欢圣彼得堡的晚上，拿着一把硬币就可以出门听歌，不停地换街口就好了，欣赏不同时段不同的乐队。国内的生活可能更多投射在食物和网络上，几乎忘记原来晚上街头可以这样热闹，我再次燃起了吃完饭出来吹凉风的习惯。

## 教堂礼拜

![image](https://user-images.githubusercontent.com/4800338/61185417-e8541400-a68b-11e9-88c0-1da45c84ae65.png)


对于基督教，在历史中出现了不同衍生，其中一支分支东正教就在俄罗斯分布非常广泛。有很多有点犹太风格的教堂，也有一些约束，比如女生需要戴帽子才能进去。教堂墙壁内仍然是辉煌的壁画，画着圣母和耶稣。我对宗教没有那么浓厚的兴趣，但是这些艺术品依然冲击着我，能让人呼吸到历史，教堂的歌声带着走到完全不同的世界。宗教在我的世界里不是生活的一部分，在这里却是，看到献花和礼拜的人们，回想起晚上街头的乐队，深感自己生活中少了文化的东西，一直在追逐或者被催促，完全忘记了小时候那些愿望。生活变得乏味对很多事情不再感兴趣并不是那些事情真的不重要了，而是真的没时间做了。
六七岁的时候，几个人在泥巴地上拿着一把小刀，划格子扎泥巴也觉得很好玩。我们现在是没有条件了吗？是的，我们连泥巴都没有了。沙包不好玩了，玩沙包的人都不见了。

在满地黄叶子的秋天里，拿着面包喂鸽子真的好快乐，路过一家小学，孩子们戴着同款包头帽子（可能是御寒）踢球，北京哪里有这样的景致啊。和肥鸽子肥鸭子一起，能玩一天。但是真的太冷了，青旅里也没有暖气，大部分时间我还是穿着厚厚的衣服，也没有抵挡住感冒。

在最后一天，在最后一个大教堂顶游览被风吹得手冻僵，下来后喝到一杯热巧克力瞬间温暖全身。那是一年中喝到的最棒的咖啡，即便他生产自街边一个小汽车的后备箱，驱逐了所有寒冷。对圣彼得堡的记忆非常的零散，很快就乘火车离开了这个文化之都。确实也有很多不好的地方，比如多雨潮湿，街上烟味很重，寒冷和油腻的食物交加，但我依然喜欢，因为有充足的乐趣，我失去了很多年的乐趣。

## 一直在螃蟹船上的一天

等到了最冷的时候，选择去热带避开严寒，这次选择了菲律宾。选了一个看起来比较小众的地方，想着国人应该会少一些，也许开发的没那么夸张？当我真的到达了巴拉望爱妮岛的码头，看着无数形色各异的螃蟹船和绿油油的海水，还是免不了有些担心：难道来晚了？已经开发过度了？最后停电停水告诉我们，还没有。

![image](https://user-images.githubusercontent.com/4800338/61185580-99a77980-a68d-11e9-9aad-1e3d6816b107.png)

聒噪的太阳。白天在烈日下行走都会觉得非常头大，即便没有声音你也会觉得很吵，光从视觉杀进听力，灼烧皮肤，墨镜的防御力黯然失色。加上海面反光，其实依然给你非常大的冲击，很痛，但很快乐，因为没有 oncall 就这么简单。

从爱妮岛离开去科隆的一天是真刺激，一直以为可以到跟前买船票过去就好，结果前两天到各个店面询问发现船票已经完全售罄，剩下的只有飞机票，还是价格很贵的小飞机。那边只有一家给码头服务的船运公司，大家都传需要在凌晨四五点去那边排队等到七点开门才能买到票，或者是早上四点去码头看看有没有空下的座位可以直接上船。

出发前一天在凌晨四点空无人烟的街道抵达了码头，发现这里已经很热闹了，大家拖着行李箱排队。遗憾的是2个小时候后船运公司的人来说船不开了，而 waiting list 上已经写满了名字，大家都在等看能不能混上船。很多乘客已经有票也不能上船，大家和船司发生了争执要求退票并吵起来，后来听说真实的原因是船员罢工，已经有人在码头等了五天也没有开成。最终失落的游客有的选择换地方乘飞机回国，因为时间已经完全耗尽；有的选择退票想其他办法去科隆。

幸好最终还是找到了一家可以出发的黑船公司，说第二日早餐开车去另一个小码头，然后开船去科隆，耗时 5 小时。事实证明这个时间是不会靠谱的，下面来细说一下。

次日不到六点来到了出发地点准备上车，车迟到很久后终于在六点多才开出了小镇。快九点时达到了一个断桥的码头，附近只有一个小村子和一些渔船，运输公司老板兼职司机，给所有人分发一箱子金枪鱼面包，看起来比较软甚至略恶心，可是事实证明超级好吃简直可以吊打一些当地饭店的招牌菜。最终九点多一艘螃蟹船来接大家，每四个人乘坐一艘小渔船划到大船上，然后几个小孩来渔船拿行李放到大船上安置。

搞笑的是开船时候我们两边只有一个塑料布遮挡，整个行船过程真的是极为漫长，海上无法预测的风浪击打着船舱里每个人的脸。啃着金枪鱼面包和提前带好的蒜烤面包勉强充饥，脸上的海水滴在包裹着自己的毯子上，体温在逐渐下降，耐心也是。从晴天烈日逐渐暗下里，水手小孩也在船头尾来来回回走了好多趟，我去了一次“厕所”，其实就是船的竹子夹板抠了个洞，然后有一个小隔间。一个歪果仁好心帮我拿着包（因为放座位上可能就掉海里了），说了句 “enjoy” 帮我打开门，相视一笑的尴尬后我看着小洞和下面奔波的海水，就地让体内的水盐回归自然。最终大约晚上八点，我们才抵达了码头，「5 小时」过得还真快。

![image](https://user-images.githubusercontent.com/4800338/61185614-015dc480-a68e-11e9-89dc-332f5a56e9a8.png)

满脸是盐的我痛苦地走下船，可是走别的船或线路，我可能就看不到这样美丽的日落了。能感到海面上水温有升，气温有降，渔船和运船的船员都异常辛苦，也没有进食，但可能已经成为了他们的日常。下船的时候满是疲惫，当地人要这样经常往返，除了赚一些外快之外，还需要打鱼或者交换物资来谋生，简单粗暴，辛酸如常。

## 从摩托上跌落

在科隆当地最后两天，吃烤串时被一个本地大叔建议骑摩托去 marcilla 海滩。次日租赁好电瓶摩托后准备出发，店主再三叮咛那边路很 rocky，但我还是觉得应该不会出问题。导航路线 50 分钟，实际上我骑了一个半小时都还没找到，没有信号完全迷路，微弱的 GPS 显示偏离路线。回到主路后真的只有沙土和石头，完全是工地一样的土地，可能还更糟糕，很多山路之前急转直下。终于在一个急转弯后直接翻车了，好在车倒下去人站了起来没被压住。右腿被石子划了很多血道子，沾满了土，短暂平复后重新上路，最终遇到了当地人说走错了，又遇到第二个当地人骑摩托，这个好心的大叔决定在前面领路让我跟着他。其实还是有点害怕的，毕竟已经完全没信号了，全是山路陡坡，有点担心被拐卖之类的。但我完全低估了菲律宾当地人的好心热心程度，大叔明明可以按他自己的速度骑到海滩的村里，但一直停下来等无法开快的我，因为土地实在太滑了。最终在长达两个半小时的摩托路线后到达了海滩旁边的村庄。
然后遇到了一个便利店的大姐，说可以在她小卖部里洗手，还顺便买了两瓶水。然后问路去海滩的时候，一个村友大叔发现了腿上的伤，决定给我消毒包扎，然后召集了几个村友说可以帮忙载我们回去。真的是感动炸了，由于看他们完全没有要钱的意思，而且感觉很正常，看着我伤口滴上酒精呲牙咧嘴的表情后，他们还开心大笑且大叔的老婆出来拿手机拍我各种哀嚎的表情。他们说可以帮我骑摩托，然后用三轮车载我们回镇子上。最后我实在不好意思问了一下价格，大叔随便说了一个价格说逛完海滩就可以送我们上路了。

![image](https://user-images.githubusercontent.com/4800338/61186130-64eaf080-a694-11e9-859f-50a5ff382e13.png)

最终还是来到了静谧的海滩，一个人都没有。觉得逛得差不多后，跟着大叔一行人坐着三轮车愉快地回旅店。他们可能是赶集或者其他行程，但我真的被上了一课，可能如果我不问，他们甚至就免费把我送回来了。我一直想给一些钱给包扎我的大叔，毕竟他用掉了自己的消毒水和纱布，但他一直不肯要，他说没关系经常骑摩托去镇上，我只好尽量演绎表情包让他们稍微在无聊的包扎中多一些笑容。他们的家也很朴素，就是一个竹子搭建的房子，离地有一段距离，竹房下面还有一群小鸡 🐥，异常富有生活气息。

回到镇上，在小卖部里才听老奶奶说那边经常有人出事故，道路十分危险，所以很少有人去那个海滩附近。吓得不禁胆寒，拖着腿上楼梯回到旅店的房间，听着旁边十几只公鸡的嚎叫，跟“店小二”学习使用当地的咖啡粉和糖泡制最简单的咖啡。

## 远东滨城失踪的手机

那几天尤为短暂，前往俄罗斯的东边海参崴。其实城市并没有给我留下太深的印象，唯一的印象是坐公交去景点，因为没有报站而坐错后，遇到了好心的会英语的大叔开车送我们到了景点。也是土路颠簸，好在车好技术好，老司机吃着甜筒唱着歌还是送到了。尴尬的是我们其中一个手机落在了上面。此时着急的用英语到处问路，结果那个景点的当地人却很少有说英语的，可是很意外的大家都想帮我们回去，最终使用谷歌翻译勉强说清了地点，因为我根本不知道我上车的地方叫啥只知道有个小卖部，然后在大家的交谈中我学到了俄语商店叫 магазин（发音很像英语的杂志，念 magazin）。司机大叔很热情，虽然车前挡风玻璃碎了，但依然单手开车另一手拿着谷歌翻译语音对话和我聊天，手还要伸到后排把手机递给我，笑了一路到了那个商店，已经感动的不会说话了。

商店附近的小孩会说一点英语，大约一群初中生模样的孩子上来想帮助我，但是由于没人认识第一个开车带我们走的大叔，大家也没有任何线索。小卖部的老奶奶听我们说英语表达了极度的不高兴觉得我们影响生意，把我们和小孩赶到了门外。小孩的头领一直想帮助我们询问丢失细节，但大家语言都不通实在太着急，勉强把英语翻译成俄语后他们还是放弃了。一个小孩一直在用很重的俄语口音说：“give me yao （your） mani （money） I will hilp（help） you”，没三十秒重复一遍，领头的小孩说：”sorry he's stupid“，着急的我笑瘫在地上。

好在我在车上录下了大叔吃冰淇淋开车的欢乐小视频，然后给了商店的店员看，他们认出了大叔，然后最终找到了大叔电话，并帮忙拨通电话。大叔表示并不知道手机，看后座好像没有，说如果找到一定会告诉我。难过的挂了电话。但是想起来有 find my iphone 的功能，定位后发现手机在市区离旅店很近的位置，虽然我的 sim 卡不能打电话，但是依靠 imessage 发消息给大叔，大叔表示自己就在那个位置！约好了晚上找他去寻找手机下落。

晚上大叔开车到了旅店门口，我激动得上车，找了半天也没发现，然后使用 find iphone 的响铃功能，最终在车后座最里面的地上找到了手机，怪不得大叔在车后座什么都没找到。。。这次再次想表达感谢，问大叔回国后可以给他寄一些礼物，他表示不用不用 no problem，灵光一现对我说那我们合个影吧。然后他开着他帅气的车离开回家。我整个人都被原地升华了。

这些道理，不管是帮助别人还是要努力享受生活，坚守自己的爱好，我都在书上看了无数遍，作文里写到烂，力透纸背。可最终新闻里还是有碰瓷老人、各种令人沮丧愤怒的新闻，可是印象最深的教育却来自旅行，来自别的国家的一个个普通人，用他们的真诚给我上了课。我那一瞬间都在怀疑自己这么多年生活的意义，我好像已经完全忘记了这些信条。餐桌上只剩下食物，网络上只存在娱乐，我都忘记了没有地铁怎么出行和游览，我都忘了原来还有那么多时间可以不要在荧光屏前度过。

## 尾声

圣彼得堡地铁上的年轻人在地铁上看书，着装优雅美丽或帅气，那个时刻和国内的地铁很不一样；
教堂里有很多老人在礼拜，他们非常安静，有人闭着眼有人低下头，有人带着鲜花，像一个国内已经失落的时代；
运输船上的小孩，他们每天看的就是海，可能我们像那个年纪还坐在电脑前打游戏，他们要讨生活；
一群俄罗斯大叔和一群科隆大叔的好心，让我重新认识了慷慨和助人这两个词，希望自己能有机会传递下去；
圣彼得堡街头的年轻人组成的乐队，收集者每个人投来一两卢布的硬币，激情地领着人群唱着他们自己耳熟的歌；

我们的生活是完全不一样的，每个地方有着剧烈的差异，却依然有些地方保留着单纯的生活方式，让我觉得自己遥遥不及，只好祝福他们快乐，希望自己也能因此改变。


从大教堂到螃蟹船


![image](https://user-images.githubusercontent.com/4800338/58635624-eecb3e00-8320-11e9-9b94-9319fd778aef.png)

I was surprised that the first touch device hard to deal with is Edge browser on Windows tablet. I though it was just like chrome. It had been years that the only touch events I had to handle is `TouchEvent`. Most web applications have simple interactions: just click. If you can click with mouse, you can navigate, trigger popup or submit forms. 

Think about it, while you're watching a video on tablet, or with your cell phone, you want to jump further seconds but there is only clicks can be achieved, will you feel disappoint? To protect user experience such as scrubbing the timeline or playhead (indicator) for seeking the position, we need scrub.

## Ahhhh...Cross Browser?

Click is across browser, browser doesn't care about your mouse, but screen does care about your finger. Usually in the devices supporting touch events, it has `touchstart`, `touchmove`, `touchend` and `touchcancel`. But after chrome introducing [pointer events](https://developers.google.com/web/updates/2016/10/pointer-events), dev noticed that there were still ways to handle similar stuff like mouse events.

just change all mouse events prefix to `pointer`, you'll get `pointerup`, `pointermove`, etc. Also, with the ability to detect is fired by finger, mouse or a pen.

Some of our requirements have different behavior of scrubs on player timeline:

- when you do touch scrub, the indicator on timeline move, but mouse doesn't
- when you do mouse hover and keep moving, the indicator move as well

Hover vs touch scrubs. Here we gotta detect the type of input. How?

## First Failed Try

According to the [spec of pointer events on w3c](https://www.w3.org/TR/pointerevents/#releasing-pointer-capture):

You can see a ordered sequence of events firing. For example, when you do click, then following events got fired.

```
mousemove
pointerover
pointerenter
mouseover
mouseenter
pointerdown
mousedown
Zero or more pointermove and mousemove events, depending on movement of the pointer
pointerup
mouseup
click
pointerout
pointerleave
mouseout
mouseleave
```

Observing that the corresponding pointer events are fired before mouse events, every event starts with a `mouseover`. I want to handle all events inside one function so we decided that maintain the continuous pointer type during an finger/mouse interaction. 
Since Safari doesn't have pointer events, I decided to use `TouchEvent` as replacement. The we could just listen to mouse events, every mouse event instance expect first one will be set with a attribute `pointerType` to tell you the input source.

Actually, the idea that setting event with `pointerType` is came from *Netflix*'s website. I reversed engineering some compressed js code (not fully mangled) I found the solution.

But finally i realize that won't work, 'cause mouse events are not always fired on touch devices.
Netflix use native controls in Safari if watching a content without login. (I don't know what it will change if you login, but I guess it won't change too much? the code is there). They use a product level solution to resolve this friction.

Smart approach I'd say so, but my product didn't tell me to enable native video controls while user watching on our site. So I tested on different devices/browsers and made a list of status of events support. See:

|Browser & Action| PointerEvent | MouseEvent | TouchEvent |
|:---:|:---:|:---:|:---:|
| chrome + touch | ✅ | ✅ | ✅ |
| edge + touch | ✅ | ✅ | ❌ |
| safari + touch | ❌ | ❌ | ✅ |
| chrome + mouse | ✅ | ✅ | ❌ |
| edge + mouse | ✅ | ✅ | ❌ |
| safari + mouse | ❌ | ✅ | ❌ |

Is there any way to handle all these stuffs universally?

### Cross Browser Scrub Solution

Scrubs have there types:

- scrub with finger touch
- scrub with mouse drag
- mouse over and move on

One behavior may happen on these two composed from three scenarios above , or event only one.
Our approaching is to separate these actions by configurations, make them independent.

### What Developer Needs?

Usually we only care about the triggered callbacks, start / move / end are enough. They could be designed as events or handlers.

### How to Separate These Actions?

Let's go through the movements:

- Hovering elements with mouse: enter, move, leave
- Scrubbing through: pointer down / move / pointer up

that's it. Due to different status of events support, we need to handle them in proper way. The handlers may receive event which is instance of `PointerEvent`, `MouseEvent` or `TouchEvent`.


## Show Code

If you want to see the details of implementation check [huozhi/fpoint](https://github.com/huozhi/fpoint). The API is pretty simple and easy to get started. You can also check the [demo](https://react-fpoint.vercel.app) on different browsers/devices.

Feel free to submit issues or questions on the repo. :)





cross browser/devices solution for scrubbing element by mouse or finger

Universal Web Scrubbing Experience


## How Story Began

Every story begin with a bug...

While I was enjoying the mangle-props bring us almost 40% compression ratio, using the way I mentioned in my last [blog post](/post/battle-with-mangle-property-compression-plus-babel-compile), everything goes well.

One day we decide to move our new UI components to React.js, I realize that I need to compile the JSX syntax before feeding them into compressor, Terser. Terser won't handle the JSX syntax minification, it's impossible for it to do so. Even you use babel-minify + syntax-jsx plugin has [bug](https://github.com/babel/minify/issues/948) though.

I felt tired to apply this build process to our web apps. Sharing the build process as a tool or package is strange 'cause people its job it's much too unusual.

> Babel (special syntaxes, e.g. JSX) --> Compress (terser-js) --> Babel (rest plugins)

You want above thing to become your bundler / build tool? I guess not.

### Comparing Solutions

Basically there are several choices for us to transpile from ES6+ to ES5:

* Closure compiler
* Acorn
* Babel
* Typescript compiler (tsc)
* Bublé
* ... (there are more, but maybe not that popular)

Let's check them one by one

1. Closure Compiler

heavy Java Dependencies. mangle-props supported, good but I got terser already.
We want the easy way, without huge dependency, so goodbye to closure compiler first...

2. Acorn

That's too raw, a parser. we need to write transform logic with `acorn-walk`, babel already did transform work right? And babel learned from acorn, supported jsx, sounds not bad? Next move to babel.

### Let's Really Try Them

Babel, Typescript and Buble sounds easy, they got their plugins for bundler (rollup / webpack loader) or they're configurable (ts and buble). We're easily to hack into that.

#### Babel

Let's express in brief what's the problem for babel. Example below is pretty simple:

ES6 syntax 1: class
ES6 syntax 2: property accessor / mutator

```js
class A {
  method() {
    console.log('method');
  }

  get x() { return 1 }
}

const B = {
  get x() { return 2 }
}
```

We expected that transpiler convert them into pure ES5 code as simple as possible. The following snippet are the result from babel transpiler with ES2015 preset in loose mode.

```js
var A =
  /*#__PURE__*/
  (function() {
    function A() {}

    var _proto = A.prototype;

    _proto.method = function method() {
      console.log("method");
    };

    _createClass(A, [
      {
        key: "x",
        get: function get() {
          return 1;
        }
      }
    ]);

    return A;
  })();

var B = {
  get x() {
    return 2;
  }
};
```

Problem 1: cannot transpile the getters of object literal.
Problem 2: getter is quoted by babel in `_createClass` helper, which means terser-js (mangle-props enabled) will end up with bug in that case.

For **Problem 1**: we could solve it with plugin [@babel/plugin-transform-property-mutators](https://babeljs.io/docs/en/babel-plugin-transform-property-mutators) which is not hard.

For **Problem 2**: How to hack the `_createClass` helper stuff? Could we hack it before class transformed? Maybe!

Thoughts here: if we could move the setter / getter logic out of the `_createClass` function, defined them in other ways like (Object.defineProperty), terser-js will whitelist these expression and won't mangle their names. Sounds good!

Can we do the similar stuff with any plugin? No. OK, let me write one.

I spent some time writing a babel plugin for solving **Problem 2**, finally I made [babel-plugin-transform-class-property-mutators](https://github.com/huozhi/babel-plugin-transform-class-property-mutators)

With these plugins, the input like this

```js
class A {
  get x() {
    return this._x || 1
  }
}
```

will output right this way

```js
Object.defineProperties(A, {
  x: {
    get: function () {
      return A._x || 1;
    },
    configurable: true,
    enumerable: true
  }
})
```

See? getter / setter are defined in Object.defineProperties expression now, and it's ES5.
Looks good? No, probably not.

Hey let's think about what we could do inside the class methods and property mutators? Class can derive from
parent, don't forget there is a keyword called `super` and `super.xxx` could be invoked inside setter / getter.

Then we need to compile the class derivation first! But plugins have order, if you do transform-class first, every thing is done then you won't have chance to run your plugin to hack anything.

Sad story, let's end with babel.

#### Typescript

Will ts become our preference? Typescript got really simple output with class transform, I made an example with both getter/setter and derivation. Here is the input:

##### example code

```js
class P {
  f() {
    return 1
  }
}

class Child extends P {
  constructor() {
    super()
  }
  get value() {
    return super.f()
  }
}

let instance = new Child()
console.log(instance.value)
```

The output look like this:

```js
var __extends = (this && this.__extends) || (function () {
    var extendStatics = function (d, b) {
        extendStatics = Object.setPrototypeOf ||
            ({ __proto__: [] } instanceof Array && function (d, b) { d.__proto__ = b; }) ||
            function (d, b) { for (var p in b) if (b.hasOwnProperty(p)) d[p] = b[p]; };
        return extendStatics(d, b);
    };
    return function (d, b) {
        extendStatics(d, b);
        function __() { this.constructor = d; }
        d.prototype = b === null ? Object.create(b) : (__.prototype = b.prototype, new __());
    };
})();
var P = /** @class */ (function () {
    function P() {
    }
    P.prototype.f = function () {
        return 1;
    };
    return P;
}());
var Child = /** @class */ (function (_super) {
    __extends(Child, _super);
    function Child() {
        return _super.call(this) || this;
    }
    Object.defineProperty(Child.prototype, "value", {
        get: function () {
            return _super.prototype.f.call(this);
        },
        enumerable: true,
        configurable: true
    });
    return Child;
}(P));
var instance = new Child();
console.log(instance.value);
```

Looks great, that's perfect almost what we need! Almost? Not the exactly? Will tell you later...

Good news that I found some typescript plugins for rollup:

1. https://github.com/ezolenko/rollup-plugin-typescript2
2. https://github.com/rollup/rollup-plugin-typescript

And I integrate rollup-plugin-typescript2 with rollup, configure it for javascript files as well, turn off some specific options only for ts files (like generating types declaration, forcedly check typings...).

But later when I come to the config of them, found that they're almost only for typescript files. Not only because of some default configs.

```js
// default config
{
  include: ["*.ts+(|x)", "**/*.ts+(|x)"],
  // ...
}
```

Developer will also be curious and confused that why something is just partially supported typescript, not fully set. Your install whole typescript package and just want it help you compile ES6 js to ES5. Is that over-designed?

I uninstalled typescript, during watching the Microsoft copyright in the generated compiled files.

### Bublé

With our example code, checkout what will Bublé deal with it. You can play with it on the online repl web app: https://buble.surge.sh

Here we go

```js
var P = function P () {};

P.prototype.f = function f () {
  return 1
};

var Child = (function (P) {
  function Child() {
    P.call(this)
  }

  if ( P ) Child.__proto__ = P;
  Child.prototype = Object.create( P && P.prototype );
  Child.prototype.constructor = Child;

  var prototypeAccessors = { value: { configurable: true } };
  prototypeAccessors.value.get = function () {
    return P.prototype.f.call(this)
  };

  Object.defineProperties( Child.prototype, prototypeAccessors );

  return Child;
}(P));

var instance = new Child()
console.log(instance.value)
```

First: No string properties, everything defined on prototype or created by `definedProperties`, great
Second: The generated code of class is really simple and short enough, I love the `prototypeAccessors`

Didn't see any issues here, the derivation is handled properly, the ES5 class is thin as well.
I think that's the final choice.

## Story Closed

Finally I ended up with leveraging buble as one of my rollup plugins, while building my bundler.

Unlike [microbundle](https://github.com/developit/microbundle), I switched off the danger transforms of buble, just don't want to break any code while chasing the performance.

You can checkout the source code of bundler here: https://github.com/huozhi/bunchee.



comparing among different transpilers and later optimization

JS Compilers Comparison


![image](https://user-images.githubusercontent.com/4800338/53287024-6ed98900-37b1-11e9-90d2-0a8c1ad3791c.png)

2 ~ 3 years ago, it’s commonly that we use google closure compiler to handle javascript code compression process. once you got enabled advance compression, that will bring a lot breaks on production code. people are careful on maintaining the whitelist for all the keys you wouldn’t want to be mangled. like native APIs, some properties from response result, etc.

today UglifyJS is welcomed, (even the maintainer gave up the work on it right now) more frameworks and libraries are mixed up, network traffic get better, developers don’t want to handle that stuff again. now more developers choose to use ordinary compression on their code, things work fine. However, sometimes you got to hide the implementation details, that you have to compress it more. then we back to the old school: enable mangle property options.

### Why Mangling Properties May Break Your Code?

Emmmm… JavaScript is never a static language from the birthday till now, maybe ever. and it’s too dynamic that compiler is hard to guess the full structure during the parsing work. Define a method on a class could be dynamic, add a property to a class is the same. That’s too hard for compiler - “I can’t dope out everything!”.

Let’s take an example. a very simple class Apple with 1 getter and 1 prototype method, then invoke the method and getter in a closure. simple, right? name it _demo.js_

```js
(function () {
  class Apple {
    get val() { return 1 }
    mycall() { return 'method' }
  }

var instance = new Apple()
  console.log(instance.val)
  console.log(instance.mycall())
})()
```

See what we got after babel’s compilation with fully transform to es5 (I ignored the \_createClass helper part). name it _demo.es5.js_

```js
(function() {
  var Apple = (function() {
    function Apple() {
      _classCallCheck(this, Apple);
    }

    _createClass(Apple, [
      {
        key: "mycall",
        value: function mycall() { return "method"; }
      },
      {
        key: "val",
        get: function get() { return 1; }
      }
    ]);

  return Apple;
})();

var instance = new Apple();
  console.log(instance.val);
  console.log(instance.mycall());
})();
```

Let’s see how uglifyJS (here I choose uglify-es package, which could handle part of es6+ syntax. I’ll tell you why I choose it later)

enable **mangle**, and **mangle-props** option! See we what we got now. We name it _demo.min.js_

```js
(function () {
  class e {
    get t() {
      return 1;
    }
    l() {
      return "method";
    }
  }
  var n = new e();
  n.t;
  n.l();
})();
```

Successful and nothing wrong right? Now we know how babel and advanced compress process do, let’s figure out how are they working with webpack together?

### Compilation and Compression Process on Webpack

Usually we configure babel compilation with _babel-loader_ and compression with _uglifyjs-webpack-plugin_.

Loaders apply on single module, when a JS file need to compile, it passed loaders first then bundled into modules.

Plugins are more complex, they’ve got life cycle. (checkout [https://github.com/webpack/docs/wiki/plugins](https://github.com/webpack/docs/wiki/plugins))

Webpack gave an example for how to make a customized plugin as following.

_In the compilation phase, modules are_ **_loaded_**_,_ **_sealed_**_,_ **_optimized_**_,_ **_chunked_**_,_ **_hashed_** _and_ **_restored_**_, etc. This would be the main lifecycle of any operations of the compilation._

```js
// MyPlugin.js

function MyPlugin(options) {
  // Configure your plugin with options...
}

MyPlugin.prototype.apply = function(compiler) {
  compiler.plugin("**compile**", function(params) {
    console.log("The compiler is starting to compile...");
  });

  compiler.plugin("**compilation**", function(compilation) {
    compilation.plugin("**optimize**", function() {});
    compilation.plugin("**optimize-chunk-assets**", function(chunks, callback) {});
    compiler.plugin("**emit**", function(compilation, callback) {
    console.log("The compilation is going to emit files...");
    callback();
  });
};

module.exports = MyPlugin;
```

This may be outdated, since webpack 4 brought tab API on plugins. But we learn that are phases and stages plugins could take effects.

UglifyJS’s compression require a context of your code. Making it as a plugin, is not only for saving time when patching bundle, it’s mean to save more bytes of output. Let me gave an example,

```js
// a.js
exports.HelloMyWorldHeyHowAreYouWorldPlzSayHelloBack = () => console.log('hello')

// main.js
import {HelloMyWorldHeyHowAreYouWorldPlzSayHelloBack} from './a'

HelloMyWorldHeyHowAreYouWorldPlzSayHelloBack()
```

If the context is just a module, like a.js, how can compression save your bytes?It had to make sure exports won’t be broken, so it will keep the name. besides it, no more other work to do in this example. Can’t save too much thing if we only know a snippet, a module, a file.

If you need to mangle the name, you get to **change all but align them**. So UglifyJS plugin consume the input from the bundled module, not the original source file. Then the task order in webpack is babel first, then uglify. Now problems come.

### Why Code Not Work When Mangle-Props Is On?

Now we uglify _demo.es5.js_ by uglify with mangle-props on. Finally we have _demo.es5.min.js._

```js
(function () {
  var e = function () {
    function e() {
      _classCallCheck(this, e);
    }
    _createClass(e, [{
      key: "mycall",
      value: function e() { return "method"; }
    }, {
      key: "val",
      get: function e() { return 1; }
    }]);
    return e;
  }();
  var n = new e();
  console.log(n.s);
  console.log(n.l());
})();
```

Run it? you’ll get error. See babel class definition, method _mycall_ and getter _val_ still not change, but the invocation are mangled. Here is the issue of dynamic, when define prototypes by some functions, parser cannot predict all the full shape of class when settle down. it doesn’t know the class will get a method called _mycall_ on it after _\_createClass_ executed.

If you just use Object.defineProperties or Object.defineProperty on prototype chain class, it will work. UglifyJS can avoid mangling these native APIs only on explicit invocations. Or maybe we can change the createClass template in _babel-runtime_?

UglifyJS generate AST by parsing code with its own parser, which called [_parse-js_](https://github.com/mishoo/UglifyJS2/blob/master/lib/parse.js) (modified from es3 parser).  even it supports parsing by acorn-js, you can only deal it in executable binary, not API.

Now, look back to the all tools we’re using to parse JavaScript file.

webpack — acorn-js;

babel — it’s own parser;

uglify — parse-js, its own parser, modified from es3 support;

(bwt, we also got esprima.js as syntax parser used in some other repos)

Everyone got their own parser with different support level, so we run into troubles if use some special feature maintainer has already warned us. 🙈

**_It might probably break your code!_** but still a lot of merits!

### How We Solve This

The solution might not be difficult, just uglify first then babel it, problem disappeared.

But before the terser-js came out, we’re figuring out a way to work with uglify-es and babel together. ’cause uglify-js cannot consume es6+ syntax at all, and uglify-es have bugs.

Example of computed-props. we got _computed-props.js_ as below.

```js
var a = {
  b: {
    w: 'w',
    x: 'x',
    y: 'y'
  }
}

var props = a.b
var c = {
  [props.w]: 1,
  [props.x]: 2,
  [props.y]: 3,
}

uglify it with mangle props, then we got _computed-props.es5.js_, it looks like this.

var a = {
  b: {
    w: "w",
    x: "x",
    y: "y"
  }
};

var props = a.b;

var c = {
  p: 1,
  p: 2,
  p: 3
};
```

look at variable _c_, every key is compressed as a same one. nested properties had been mangled in wrong way.

Then? What we do is compiling it first with only couples of es6+ plugins like transform-computed-props. we don’t transform classes at the beginning.

Once we got partial es6+ code, uglify-es could mangle it correctly without brokens.

After uglify’s own part is down, webpack will feed assets to another plugin, babel plugin. This guy will apply all presets and plugins we specified in babelrc on the output. We’re done!

#### Simpler Solution

uglify-js@3 only support es5.

At around Aug 2018, uglify’s job pass to another successor. Since maintainer decide not to maintain uglifyjs anymore, [terser-js](https://github.com/terser-js/terser) came out. you may regard it as the new uglify-es.

Leverage terser-js will make that process easier, terser first then babel.

### Future of Minify

Babel has published its own minifier called babel-minify, without support mangling props yet. Will it finally adopt this feature? Don’t know.

Mangling props has its shortcut. you have to keep some properties in string format. and non-key properties cannot be invoked in computed format, like obj\[‘prefix’ + someValue\].

Community has brought a cool thing, prettier, for auto formatting your code. Unfortunately, prettier will wipe out the quotes on string format key. I cannot tell everyone, please comment /\* prettier ignore \*/ on every object with string format properties, that’s not cool.

Frameworks like react, publishing lots of CLI tools to setup a application fast. the compression strategy, is not to mangle the properties, it will be easy for developers to focus on creating phase, not optimizing one.

We’re working on an application with some core libraries inside it now. What I’m thinking is to keep the excessive strategy for core libs but not the top level of application. You need to separate the two parts, ’cause:

1.  application usually grow faster than core libs.
2.  hiding implementation and extreme optimization is no need for top level but core libs.

maintaining an excessive strategy for whole codebase is really suffered. Some new hires may even not heard about such closure-compiler, mangling-properties stuff. It’s like people resource management. someone focus on surface and someone goes deeper.

That’s it. if you figure out any incorrect description and mistakes in this article please contact to fix them and I’ll appreciate.

_Code example:_ [_https://github.com/huozhi/minifyjs-test/_](https://github.com/huozhi/minifyjs-test/)

[twins link on my medium](https://medium.com/@huozhi/battle-with-mangle-property-minify-and-babel-compile-e8fa3be99f17)


encounter some issues during playing with babel + uglifyjs mangle properties

Mangle Properties Compression Traps


- Log, when
- Log, six

这是最近每三个月早上到办公室后的第一句招呼，如果来得比鲁哥晚，碰到鲁哥拿杯子去接水

## 划水入门 🏊

由于真正的 mentor 突然转行了，被迫突然成为了 mentor，并认识了鲁哥。由于鲁哥在 team 里最年轻（95 年），所以会称呼其他人为 Log（老哥）。

每当我和他解决了一些奇怪的问题后，鲁哥会说：「Log，when」（老哥，稳），有时候是「Log，six」，我只好回 Triple six

鲁哥参与了 player 组漂流的 TB，还没来得及入门工作就开始在怀柔山上「划水」。去时的路上，我们各自买了两个 subway 为午时充饥，moshu 来接我们的时候指着车上几袋子零食说随便吃。鲁哥特别开心，念了两句诗：「太好了」和「这哪儿够啊」

## Happy Hour 🎱

我们组座位紧靠着 game room，是距离台球桌最近的组。

随着涛哥的加入，「一股麻香」和「jack in the box」也跟着变成了黑话，因为店门口经常有说 rap 的流浪汉对着电线杆或者马路疯狂地 battle，手势和着装都非常嘻哈。
且随着实习工作的开始，两位 java 选手被迫搞起了 nodejs。并在不知不觉中，逐渐占据了台球桌的高地。甚至有时他们还会戴上台球手套，情怀武装。

由于我只会打乒乓球，每天和涛哥打几局，运动后下午都非常精神。涛哥拿出茶壶，鲁哥在杯子里放两粒枸杞，说：走，去排练吧。在茶香四溢中两个台球青年拿着保温杯走向了会议室。

后来才知道是因为他们在 new hire talent show 上要排一段舞蹈。鲁哥说：「Log，记得帮我录像」，他坚持如果表演成功就当天下午就出道。

突然有一天，看见涛哥打台球，后半场十分顺利，一杆清了好几个球，和台下的鲁哥友好握手结束了当轮比赛后，并说了句友谊第一，然后问我：「come on ping pong？」。我问涛哥说台球打得这么厉害怎么不多打几局，涛哥说：「太简单了，没意思」。拿擦台球杆的壳粉抹了抹拍子，说了声「开始吧」

当月的 Happy Hour 上，新入职的朋友们上来表演，鲁哥 C 位和涛哥表演了舞蹈后，大喊出「我实习期间的目标是打败 uncle gang」，要知道，uncle gang 可是台球桌叱咤风云的选手，经常严厉地告诉其他选手「放学别走」。后来鲁哥放学再也没有回过家。

## 沉迷工作 🍻

经常 8 点多吃完晚饭，鲁哥发来一个 PR 链接，「Log，别忘了帮我 review」，我说好，一定，然后打开了 12 年买的 thinkpad，双击了「尤里的复仇」。

鲁哥其实是一个非常热爱 coding 的人，可能年轻人都这样。不过逐渐地，经常写到下午五点就会忍不住和隔壁组去台球桌大战一局。虽然我看不太懂，但是他们每次击球之前都会大喊「好球！」。我问鲁哥为什么要把板寸弄成棕黄色，他说中学的班主任也不信他没染发，在办公室就给剪了，后来每天看着的头发一点一点长出来，反射出的棕黄色光辉在发间交相辉映。话语间，打进中袋的白球熠熠生辉。

涛哥介绍他和鲁哥求学关系时，说你想图书馆里我和他就坐对面儿，然后现在实习还坐对面儿，后面还要一起租房，都快看腻了...唉地一声叹息。鲁哥说哎嗨，你饺子还吃吗我尝一个？

早上站会的时候，突然找不到鲁哥和涛哥，一时间陷入了僵局。直到吃完饭回来，我们才看到了他俩，端着小米粥，咸鸭蛋。后来才知道，是前一天晚上出去浪喝大了，早上没有醒来。鲁哥说话已经不利索，大家约法三章：喝题不刷酒，刷酒不喝题。

## 尾声

其实有很多聊天，为了解决鲁哥对各种 library 和 tool 的好奇，开了很多小灶。从此他听着 youtube 音乐，写着微信，聊着代码的欢快生活雷打不动。当大家驻足在涛哥刷题的屏幕前，指着 `)` 和 `{` 中间缺少的间隙，鲁哥都非常淡定地带着耳机，吃着枸杞听着歌儿，丝毫不为所动，完全忘记了自己作为一名 java 刷题选手昔日的荣耀。

毕竟他们还有一个多学期，还有大把的时间可以刷题，在台球与酒水的浇灌下，在 java 的基础上还熟练掌握了 script，直到最后再也不会 new ArrayList。

我一直以为，到了这样一家比较安逸的地方，就会看见更多的人准时下班，准时上班，恍惚见仿佛有了朝九晚五的影子。但新鲜的血液总会让你明白，其实几点下班和在哪里没有关系，因为六点的钟声敲响后，等着他们的还有台球和夕阳。

相信一定是因为大家有趣的经历，才会相聚在这个地方。在历史的时间线上，人们曾以不同的时间点穿插在 Santa Monica 的某个角落，有人在 jack in the box 吃着薯饼，有人在图书馆喝着咖啡写大作业，有人去往一号公路的路上飙车。

可能你 2014 年 hackathon 通了一把宵，也有人在熬着几天夜写教授布置的大作业，也有人十二点半在宿舍刚起床对舍友说哎你也没去上课舍友说我上完都回来了

我有时候很喜欢工作，因为觉得一起工作的人特别活泼，足够欢乐。一起去茶餐厅吃顿烧腊饭，点杯奶茶，不用担心有没有人把你的车一波带走开到墨西哥，你也不用太担心晚上十点打完台球出来方圆一公里如果看见人一定要撒腿就跑。

但工作后生活里也多了一些东西，多了一些上学的时候没惦记过的烦恼，这就是我们虽然完全同样的年纪却难以挂着相同的笑容。青春期应是一个很长的周期，与你的心情成正比。心态足够好，保温杯就追不上你的脚步。

最后，希望 Log 们 six，祝学业顺利，一切都好。


Log when，Log six


If you feel it's too long to read, here's the repo: https://github.com/huozhi/html2any

## Inspiration

There was a task, to create a FAQ site, which is fully functional to provide user with help information.

Designer: First we have a search bar 🔍, able to retrieve every index page. pages are in rich text.
Dev: Yep, sounds good, not difficult. (I guess markdown can handle all)
Designer: Rich text is required to support videos, gif, inline images, block images blablabla...we hope it could be aligned with our main site, all the theme, animations are same.
Dev: Emmm...this is a new fresh project, can we just use the default video controls?
Designer: The vidos/gif need to be same with main site, the basic controls is not enough for user.
Dev: And where are these contents from?
Designer: Maybe an editor in CMS to publish new pages?
Dev: Hurry?
Designer: Yep! hope be ready soon!

** WHAT THE HELLLLL... **

![WHAT??](https://img.moegirl.org/common/thumb/4/41/Nicky.jpg/250px-Nicky.jpg)

Looks impossible to finish this work in a such short time with markdown. However it's insane to hard code all static pages within react or other js code. The point is, the `RichText` component in existing project is not able to easily migrate now, and they still have other logics to handle text collapse / metrics collecting...which we don't really need.

For us, **we just want a static page**. That's it.

What I can only decouple from existing project are: Video, Image and Gif components. CMS will always provide me with a HTML string for the rich text content. I have to figure out a way to replace the native image/videoes tag with customized react components.

## Editor & RichText

While you typing stuff in rich text editor, making them bold / italic, inserting some images, you've already finished once rich text editing. Since these content are not only pure text to display, they need more complicated composing with HTML and CSS, even JavaScript to perform an interaction.

There are kinds of editors:

1. stateful editor: such as draftjs, slate.They all convert HTML to a middle state, then serialize from state to final HTML
2. non-stateful editor: doesn't need state, maybe only rely on contenteditable, encapsulate on the top, such as Medium.js

Saving editing content has 2 usual thoughts:

1. Use stateful editor, sync state to database. Recover from state in database when you display. Feel natural.
2. Use any editor you like. Communicate by HTML between client and storage.

Saving state may bring potential traps. For example you want to migrate from google closure editor to draftjs. There isn't any state before, the new comer breaks rules. Make you hard to handle the previous way. Migration takes effort and risks.

If you saving HTML string with stateful editor, you have to write your own serializer + deserializer state converter. Draft requires lib like draft-convert, slate has built-in serializer and deserializer with convenient usage.

## Went So Far. Anything Related to Our Stuff?

First tasting on slate editor I felt free because of its [HTML convert](https://docs.slatejs.org/walkthroughs/saving-and-loading-HTML-content.html)

```js
const rules = [
  {
    deserialize(el, next) {
      if (el.tagName.toLowerCase() == 'p') {
        return {
          kind: 'block',
          type: 'paragraph',
          nodes: next(el.childNodes)
        }
      }
    },
    // Add a serializing function property to our rule...
    serialize(object, children) {
      if (object.kind == 'block' && object.type == 'paragraph') {
        return <p>{children}</p>
      }
    }
  }
]

import { Html } from 'slate'

// Create a new serializer instance with our `rules` from above.
const html = new Html({ rules })

state = {
  state: html.deserialize(htmlString),
}

const htmlString = html.serialize(someState)
```

Isn't it interesting? Enjoy state and HTML switching after you just defined a de/serialization rule. COOL!

When you reach here, got it? What we need is a thing, without any editor functions, be capable to convert HTML into and from structural state. To help us display complicated state visualization.

## LETS DOT IT

Still remember the principle of compiler? The process of consuming code string and output as machine code:

- tokenizer: extract special tokens
- parse: build tokes to AST
- transform: transform AST to dest code

Now the same, our HTML and state are totally like this process. dest code is our final visual form. It could be a component or a HTML string, even a JSON object, whatever.

What we're going to do are following 3 steps:

1. Tokenize HTML into proper HTML tags
2. Build a tree, each node is a HTML tag containing its information and children
3. Traverse this tree with replacing the node into your own

## Introduce you html2any

Checkout my final implementation: https://github.com/huozhi/html2any

### Run on React Native

Check the presentation on [React Native](https://github.com/huozhi/html2any-rn-demo):

A paragraph containing bold fonts and images was converted to the react native form. Here's the screenshot on iOS:

![rn-demo](https://raw.githubusercontent.com/huozhi/html2any-rn-demo/master/public/html2any-rn-demo.png)

Of course the component nested rules on React Native is much restrict, e.g. Text need sit under View with size specified. Text under Text doesn't inherit styles, which unlike CSS.

### Run on Web with React

[Click Here!](https://huozhi.github.io/html2any-web-demo/)

I made a simple transform rule for web:

1. br to hr tag
2. replace gif with a gif player including loading phase
3. Native video tag change to react video player

Want more? you can design more complicated rule function, then left it to html2any to handle.

## Reference and Comparison

Actually we have lots of HTML parser in community. The most familiar ones are parse5 and HTMLparser2. Even cheerio is using HTMLparser2, why create the wheel again?

My reasons are:

1. html2any is really small enough. It's worth to try if you want to show any content generated from slate or dratjs.
2. many parsers are in sax form, parsing top to down. Creating a few API to handle the middle processing phase. For usage like ours, we don't need that much. And they do much compatible work for unreachable cases.
3. The most important reason —— more parsers are for web specially. Their outputs may be DOM tree, that's not our desired dest code. See the examples above right? Our doing is Universal HTML! Render Everywhere! Haha

My [slide](https://docs.google.com/presentation/d/1GDrZ1dZ8xeCPyy0FSy9lS0KFHhztM2LOlt5pjzvuOs8)


Parse HTML to AST then transform it to customized structure

Convert HTML to Anything You Want!


[Slides](https://speakerdeck.com/huozhi/about-compilation)

## Talk About Compilation

Building a hello world C program may be the first time for us to hear about Compiling. After we have known deeper about a sort of the conception, compiling became much more `unapproachable`. Only nerds understand what does a compiler do during compilation.
When I was senior grade in college, the course `fundamentals of compiling` did frightened me a lot.

Recently, I found the project called [the-super-tiny-compiler](https://github.com/thejameskyle/the-super-tiny-compiler). That's so
awesome that it telling you the basic concept and steps of compiler stuff.

## Structure of Compiler

Having a look of the picture below, these parts forms a compiler: the front-end such as tokenizer,the middle state AST, the backend which responses for syntax analysis and code generation.

![compiler-construction](https://user-images.githubusercontent.com/4800338/50723993-a9fbfc00-1120-11e9-8f54-d50f04da1497.png)

`the-super-tiny-compiler` has four functions.

1. parse the source code from string format into tokens.
2. parse from tokens into AST structure.
3. transform AST. (code generation preparing)
4. generate the final code.

you can easily know about steps during the compilation by reading its source code, with well explaining comments.

If you have developed front-end apps around year 2016, you may know `babel` well. Babel is a famous compiler for JavaScript, which support multiple features to let you parse es6, jsx, flow syntax like code. And it will do the code transform to ensure the final code could be working in environment you're expected.

## Let's Talk About Babel

Babel has a large ecosystem providing syntax presets, specific transforming plugins and also the parser for users. [babylon](https://github.com/babel/babylon) is the basic parser working background of babel. You can access the AST of the code by parsing it through babylon. That is really easy, just follow the tutorial in [babel-plugin-handbook](https://github.com/thejameskyle/babel-handbook/blob/master/translations/en/plugin-handbook.md).

The most mysterious thing is what does AST look like. For babylon syntax tree format. A simple function like

```js
function square(n) { return n * n }
```

will just be parsed as:

```
- FunctionDeclaration:
  - id:
    - Identifier:
      - name: square
  - params [1]
    - Identifier
      - name: n
  - body:
    - BlockStatement
      - body [1]
        - ReturnStatement
          - argument
            - BinaryExpression
              - operator: *
              - left
                - Identifier
                  - name: n
              - right
                - Identifier
                  - name: n
```

See it? It's easy. A huge object that you could traverse it by `depth-first-traversal` method. It's just a tree, representing the priority of each node been parsed. Same level nodes have same priority and deeper get smaller priority.

What about the whole compilation steps? I wrote a demo.

```js
// babel tool set
const babylon = require('babylon')
const t = require('babel-types')
const traverse = require('babel-traverse').default
const generate = require('babel-generator').default

// source code
const jsxCode = `
<div>
  <img src="a.jpg" />
  <span>hello</span>
</div>
`

// parse ast
const ast = babylon.parse(jsxCode, {plugins: ['jsx']})

// traversal transform
traverse(ast, {
  enter(path) {
    const {node} = path
    if (node.type === 'JSXIdentifier') {
      if (node.name === 'div') {
        node.name = 'View'
      } else if (['span', 'p', 'h1', 'h2', 'h3'].includes(node.name)) {
        node.name = 'Text'
      }
    }
  }
})

// code generation
const gened = generate(ast, null, jsxCode)

// result
console.log(gened.code)
```

What I want to do is transforming a simple ReactJS code into ReactNative like code. But without replacing the keywords manually, I would like to use babel toolset. Let's begin.

For above you could see that I gave the source JSX code and I wanna parse it into babylon AST, finally I generate the code with babel itself.

The work including four parts:

1. Use `babel-types` to access the specific nodes you would like to do transformation.
2. Use `babylon` to parse code int AST.
3. Use `babel-traverse` to traversal whole AST and do some transformation.
4. Output final code with `babel-generator`.

These libraries are famous in babel ecosystem. They are your armory and weapons the split code structurely.
If you want to learn more, just have a deep look at `babel-handbook` repo.

Fow now, you just finished the same work that "the-super-tiny-compiler" had done. Parsing, Travsal, Transforming, Generating. I like it very much 'cause it's been much easier for me to understand the problem since I learned how to compiling a C++ program. No more asm middle state code, just from input to output.

## Extensions

After reading this post and the source code of tiny compiler, you might have many ideas to do transforming in your field. Let me give an example, I'm now a front-end developer. I write advanced CSS very day. People may say out some key words like "SASS, PostCSS", the tools to let people write less vanilla CSS. How does it work? From recognize the complex syntax then output the pure css code.

Think above. You'll find out the same routine to get the shit work. Advanced CSS mean another syntax of CSS, like es6 to es5. What you need is a syntax parser with ability to construct CSS like syntax AST, and generate code from the rules given.

### Let's see an example.

Given a CSS source code below, written in vanilla CSS syntax. What about translating it into ReactNative stylesheets, Ha?

```css
/* ItemActions */
.action {
  margin-top: 10px;
  margin-right: -25px;
  color: #8e8e8e;
}

.button {
  margin-right: 25px;
}

.icon {
  margin-left: -3px;
  fill: rgb(192, 192, 192);
}

.number {
  margin-left: -.3em;
}
```

We depend on a parser module called `css`, you can find it on npm.

```js
const fs = require('fs')
const {parse} = require('css')
const log = console.log

const cssFilename = process.argv[2]

const css = fs.readFileSync(cssFilename, 'utf8')

// parse content to AST, including tokenizer
const ast = parse(css)

const rules = ast.stylesheet.rules.filter(rule => rule.type === 'rule')

function camelCase(str) {
  return str.replace(/-([a-z])/g, (match, p1) => p1.toUpperCase())
}

function letterCase(str) {
  const camel = camelCase(str)
  return camel[0].toUpperCase() + camel.slice(1)
}

function renameSelectorToKey(selector) {
  return letterCase(selector.replace(/\.|#/g, ''))
}

function transformValue(value) {
  if (/^-?(0?\.)?[0-9]+/.test(value)) {
    const matches = /(-?(0?\.)?\d+)(px|em)/g.exec(value)
    return parseFloat(matches[0])
  }
  return value
}

const ruleMap = rules.map(rule => {
  return {
    name: renameSelectorToKey(rule.selectors[0]),
    declarations: rule.declarations.reduce((m, declare) => {
      m[camelCase(declare.property)] = transformValue(declare.value)
      return m
    }, {}),
  }
})

// transform AST

const styleSheet = ruleMap.reduce((m, rule) => {
  m[rule.name] = Object.assign({}, rule.declarations)
  return m
}, {})

// Code Generation

const styleTemplate = (styleSheet) => {
  const content = JSON.stringify(styleSheet, null, 2)
    .replace(/\"([^(\")"]+)\":/g,"$1:")
    .replace(/\"/g, '\'')
  return `module.exports = require(\'react-native\').StyleSheet.create(${content})`
}

log(styleTemplate(styleSheet))
```

finally we got

```js
module.exports = require('react-native').StyleSheet.create({
  action: {...},
  button: {...},
  icon: {...},
})
```

That is what we expected after a compilation progress.

### Conclusion

You may know a little more about compilation after the two examples of compiling JSX and CSS. The concept could just be used everywhere. Human use complied code to talk with machines, write easier code, and so on. Just keep the knowledge, it may helps you a lot. :)


Understand compiler construction, stood on the shoulder of babel

About Compilation


[Slide](https://speakerdeck.com/huozhi/cool-staff-of-svg)

### Before the Plan Starts

I had seen tons of loading effects like spinkit, loader.css, spin.js. Using kinds of divs and positioning them in the grid in certain size. Then define different animations upon the components.
Some using js, e.g. spin.js, applies computed animation on html by inserting dynamic styles into dom.
Candidates like loader.css, hard code the width / position / color / etc. parameters with weak expansibility.

I was just coming up an idea, why not doing loading animation components (will call them spinner in the following content) with dynamic react props?

We can control count, size, gap, color, animation time these attributes, to map the sub-blocks like this.
HTML + CSS? Maybe not.

### SVG + React

SVG has long history since 2003, with wild basic components like：Rectangles, Circle, Ellipse, Line, Polyline, Polygon, Path. Easy to build. e.g. Circle is equal to `div + border-radius`, but better for read.

![respinner demo](https://raw.githubusercontent.com/huozhi/respinner/master/docs/demo.gif)

I provide few pretty respinners, to let you set your own props and attributes to controls size and animation.

### Another Approach of SVG Animation

[animateTransform](https://developer.mozilla.org/en/docs/Web/SVG/Element/animateTransform) helps svg animate. example:

```html
<polygon points="60,30 90,90 30,90">
  <animateTransform attributeName="transform"
                    attributeType="XML"
                    type="rotate"
                    from="0 60 70"
                    to="360 60 70"
                    dur="10s"
                    repeatCount="indefinite"/>
</polygon>
```

It works but harder than CSS animation, and require more code. Some fancy animations can be hard to build. Finally I choose CSS.

That's it! What are you waiting for? Try it now! :)


Doing some funny loading stuff with react and svg

SVG + React: Birth of respinner


### 开始讨论

晚上，群里的设计师然提出了一个问题：为什么 React Native 使用 JS 来做样式，而不是使用 CSS？
因为 React.js 开发 Web 的时候，是可以使用 className 的，我们可以使用 CSS 的类来为各个组件、模块定义样式。但 React Native 只能使用 JS Object，我发现自己好像没有完全注意过这个问题（可能是因为没写过 RN）..

决定看看到底是为什么。Google 了一把之后找到了[这个页面](https://facebook.github.io/react-native/docs/style.html)，里面说明了一些原因。最先映入眼帘的就是 “React Native doesn't implement CSS...”。Cool，看来 React 在浏览器中的 CSS Parsing 过程没有办法直接搬到移动端上，所以 RN 只保留了 React 的 JS Object Style 特性。

下面是一个 slides，是 Facebook 的 frontend infrastructure 工程师 Christoper Chedeau (他的 id 叫 vjeux) 对这个有争议决定的解释，到底是因为为什么 FB 决定在 React 上使用 CSS in JS 形式的 Style。

在规模性使用 CSS 的时候，主要会遇到以下 7 大问题：

以开发一个 button 的样式举例，`.button`，和被按下后的状态 `.button-depressed`

#### 1. 全局命名空间

我们开发了两个 CSS 类，会产生两个全局的 CSS 变量（就是全局的两个类），我们在 JS 中已经了解到全局变量的坏处（如可能被覆盖值、被重定义），但在 CSS 的大陆上我们依旧在使用他们。

在 Facebook，工程师们使用了一种叫 cx（CSS Extension）的工具，为 CSS 提供命名空间，使用如下


```css
/* button.css */
.button/container {
  padding: 5px;
}
```

相应的，在 jsx/js 中

```js
/* button.js */
<div className={cx("button/container")}>
```

#### 2. CSS 文件之间可能存在依赖

长久以来。。我们一直告诫开发者每次要用什么样式，就要通过 requireCSS 将 CSS 文件引入。不过一个问题来了，有的时候有其他的文件已经 require 了一些 CSS 但你却忘了，不过依旧能正常运行（这其实很不安全不是么？！万一哪天 break down 了很难找问题）。

cx 可以支持一些静态分析，帮助你避免这类问题，所以 issue 2，我们也算解决了。

#### 3. 消除 Dead Code

如果你使用了 cx，那么 css 和 className 中使用的类名都一致了！如果什么时候 className 不再使用了，同时干掉 css 里的就好了。（vjeux 在这里的解释还是关于 cx 的，感觉这个似乎没什么重要，还是手动删除）

#### 4. 压缩

cx 会对类名替换，酷，这样你连 CSS 的名字都猜不出来了

#### 5. CSS 与 JS 共享变量

这个问题非常有趣，而且也很常见。是 CSS 之间共享变量吗？我们说的并不是 less、sass 那种变量的定义，而是 JS 和 CSS 之间 share 变量。
vjeux 的栗子并不好吃，我举个栗子吧：
假设你需要使用 JS 动态创建一些图形，如圆点（为什么是圆点？...好吧其实随便是什么都可以），然后你要计算点击区域的左右上下边界，怎么办呢？当然要知道他的半径或者宽高啊。有人说可以使用 JS 获取宽高，如果我设置的是 borderWidth 之类的呢，或者还有 padding？你打算全部获取到然后计算一把吗？呵呵当然不是。最简单的当然是直接写一个常量来代表半径、宽高这类值了。
然后突然有一天 designer 找到你，我们的小圆点好丑啊，我希望把它改成大圆盘，半径从 0.5px 变成 50px。这时候你要改的就不仅仅是 CSS 了，还有一堆隐藏在 JS 中的常量值。你要去 grep 他们的名字吗？

Facebook 又想到了一个方法，叫 "CSS Variable"，通过一个 php 文件把 CSS 里的常量导出为一个 array，为 JS 暴露一个叫 cssVar 的函数来调用。


```css
.button/container {
  padding: var(button-padding);
}
```

```php
/* CSSVar.php */
$CSSVar = array(
  'button-padding' => 5
);
```

```js
var buttonPadding = cssVar('button-padding');
```

酷，可以让 CSS 和 JS 共享变量了

以上的 5 个问题，其实我们（FB）现有的工具都可以 handle，那么下面两个问题，就不那么好解决了。

#### 6. **非确定性的样式**

在一个 CSS 文件中，如果你对某一个样式（一个选择器的样式）定义了多次，属性有重复，后者就会覆盖前者 (the last one in the file wins)。

```css
.small { font-size: 12px; }
html { font-size: 12px; }
.small { font-size: 22px; }
```

以上，最后 `.small` 是 22px，很简单，因为它在后面...这个方法也常用于自定义样式框架，比如我们基于 bootstrap 做一些修改、定制，用自己的文件 concat 在最后，借以覆盖 bs 某些选择器原有的样式。

但是这还有个问题，不是所有情况下，CSS 文件都只有一个的。如果某一个样式写在不同的文件中，而这些样式文件是异步加载的（因为这样可以快起来啊），浏览器接收到同一选择器不同样式的顺序就不一定了，那用户到底应该看到什么样子？谁来决定呢？

我们先放着这个问题不管，来看下一个

#### 7. **隔离**

假设我们的 designer 非常赞，设计了一套基础的 UI 库，可以给大家用，可能包含 dropdown、menu 等，花了很大精力设计了一套可以兼容各种场景的 API。不过当设计和开发希望加入一些新特性的时候，我们可能需要跟各个 team 的维护者聊一聊，看看到底怎样做比较合适，能适应他们目前的代码设计。（天呐真是太麻烦了）

酷，最后终于搞定了！开发者写了一些奇怪的 trick 的语法来兼容我们各个团队的需求，然后奇妙的事情发生了，页面全挂了~！...当然这可能是比较糟糕的预期，情况是我们可能很容易破坏各个选择器直接的隔离性，因为新的 CSS Selector 可能影响组件内的许多东西

```js
<Menu className={cx("menu")}>
  <MenuList order="1" />
  <MenuList order="2" />
  <ButtonGroups />
</Menu>
```

```css
.menu > a {
  /* blablabla... */
}
```

当我们改动了 menu 这个样式，谁知道会发生什么呢？`<a>` 最终影响的到底是 list 呢还是 button group 呢？如果我们的 dom 结构再变化，还会影响什么呢？要靠猜的吧！哈哈


### CSS in JS

我们解决了 7 个问题中的 5 个，6 和 7 则难得不行。继续引入 CSS，反而可能会让这些问题更复杂。我们不可能再所有地方，大规模、小规模都完美使用 CSS，毕竟不是每个写 React 都是专业的前端工程师不是吗？

来疯狂一把，为什么不试试 JS 呢？！下面是一段 inline style 的 React 样式。（等等你说 inline style？那不是 Web 开发中不推荐的方法吗？）

```js
var styles = {
  container: {
    padding: 2,
    backgroundColor: '#eee',
  },
  depressed: {
    borderRadius: 2,
  }
}

<div style={styles.container}></div>
```

我就写短一点，你们感受一下就好了。除了结构化的 JS 对象，以及 CSS 属性变成了驼峰命名，px 值变成了数字，inline style 好像没那么糟糕了，不是吗？因为这里的 inline，并不是变成了 `style="a:1; b:2; c:3;"` 这样难以辨认的字符串，而是让你用 js 的对象来定义，只在 React 组件的 style 属性那里传入一下样式的引用。JS 对象，就好像映射了一个个 CSS 的 class，而 inline style refer，就是一个隔离的好办法。

当引入 JS 后，玩法就更多了。我们甚至可以加入逻辑，比如函数、条件等等

```js
propTypes: {
  isDpressed: React.PropTypes.bool
}

<div style={Object.assign(
  styles.container,
  this.props.isDpressed && styles.depressed
)}>
</div>
```

用以上的代码，我们已经完成了一个样式根据状态的变化：当变成 isDepressed (被按下) 的状态，就应用 depressed 的样式。

### 尾声

我觉得综上所述，你可以理解为，FB 发现 CSS 不好解决的问题可以通过 JS 来解决，所以用了 JS。而不是强行必须照搬 Web 开发原有的一套。React 在 Web 端其实还是可以使用 CSS 的，用 className 的话。但 React Native 就不行了，但有了这样的样式设计，无论是为了解决问题，还是减少 RN 实现复杂度，都有极大的帮助，所以 RN 最后的官方 doc 说的是压根没实现 CSS。(我并不知道他们以后打不打算实现 CSS)

...

如果你有兴趣追根溯源，请继续看

下面这篇是 vjeux 发表在 speakerdeck 上的 slide，解释了 React 使用 JavaScript 代替 CSS 来创建样式的初衷。

<script async class="speakerdeck-embed" data-id="2e15908049bb013230960224c1b4b8bd" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


解释 React 为什么会采用 JavaScript Inline Style 的方式来定义组件样式

制作一个简单的 JS/TS 的零配置打包工具2020-11

隔着屏幕的朋友 - 开源参与小记2020-07

UI 设计初体验2020-04

Positioning Component in React2019-12

名正言 Shun2019-10

从大教堂到螃蟹船2019-07

Universal Web Scrubbing Experience2019-05

JS Compilers Comparison2019-04

Mangle Properties Compression Traps2019-02

Log when，Log six2018-08

Convert HTML to Anything You Want!2017-08

About Compilation2017-02

SVG + React: Birth of respinner2016-10

关于 React 为什么使用 JS Object 代替 CSS 来创建样式2016-05