在 webworker 中运行 react virtual dom
在一次内部分享会中,我表达了可以把 react 的 virtual dom 那一套全部放到 webworker 中,这样就可以避免在主线程进行计算量很大的 diff 操作,一方面节省主线程的计算消耗提升性能,另一方面也不需要再去构建 react 的 scheduler 做那么复杂的协程工程。大致意思就是,在主线程只做 DOM 操作,而 DOM 的操作,全部由 worker 线程发送消息到主线程完成。在 worker 中计算得到 patches,发送到主线程,由主线程的程序完成 patch,也就是在主线程中,只存在 DOM 操作,不存在计算过程。其中比较重要的一点,是事件响应问题。当用户在界面上做了一次点击后,需要发送一个 event 消息到 worker 中,然后由 worker 中构建的一套事件处理系统完成事件响应和接下来的 diff,将最终的 patch 发送回主线程。
之后,在同事的推荐和自己的寻找下,找到两个项目:
- web-perf/react-worker-dom: Experiments to see the advantages of using Web Workers to Render React Virtual DOM (github.com)
- dai-shi/react-worker-components: React Worker Components simplify using Web Workers (github.com)
- ampproject/worker-dom: The same DOM API and Frameworks you know, but in a Web Worker. (github.com)
前一个项目比较老了,感觉正好符合我的想法。后一个项目受最近 server components 的启发才出来,也是非常有意思。
在深入想想。既然我们可以把计算过程放到 worker 中,也可以放到 wasm 中去。我们可以用 rust 重写 virtual dom 的实现,并像上面 worker 中的处理方式,放到 wasm 中,通过接口传递数据,完成计算后再回调方法,最终实现这个效果。
而以上这套思路,还有点像小程序的思路,但最终还是不大相同。
有些东西坚持很久,东西本身可能无所谓,但坚持这件事很有意义
今天QQ音乐推荐了我的个人播客节目《Robust》。
虽然是由于腾讯内的同事在帮忙推,但是也是一件很开心的事情。做《Robust》是圆自己一个电台梦,可以有一方自己的王国,想说什么就说什么,其他人只能听。但是我是一个很淡然的人,我见到一些朋友做播客喜欢走极端路线,比如一些同性恋节目、离婚、一个事情是不是犯法等等,我觉得都太功利目的了,都想通过内容主题来吸引听众。我做的内容,完完全全不是要吸引听众,就跟我写博客一样,更多是一种表达的方式,把自己的知识或感悟积累成为可以用语言表达的有框架的知识体系。所以,有网友说我一个人讲太无聊了,要是两个人讲就轻松一些。因为我讲的东西偏技术,有的甚至讲技术细节,所以听起来肯定很枯燥,但是并不影响听众打发时间。枯燥是枯燥,但是我还是希望尽可能沉淀东西进去,很久以后回来听,也不会太过时。
我的计划是最少要做100期,我现在做了3年,做了25期,也就是说还要9年才能做满100期,那时我正好40岁,还真是有仪式感的一段岁月。
我写博客也写了马上10年,博客的内容有的时候也是很糙,但是,就像我标题说的,其实,内容本身可能无所谓,因为现在写的东西,过一两年就过时了,甚至是错误的,内容即使在当下很超前很硬,但也有过时的一天。而写博客这件事本身,却伴随了我整整10年,对我来说,是一件了不起的事情。一件事如果能坚持10年,就是了不起,又有谁太在意它的内容本身呢?
-
给你点个赞 (。>∀<。)
-
加油#1031 1188 2021-04-20 09:34
-
谢谢支持!#1032 回复给#1031 否子戈 2021-04-20 10:49
-
谢谢哦#1033 回复给#1030 否子戈 2021-04-20 10:49
腾讯3年可以申请更换设备,虽然大家都说Mac好,但是我还是申请更换了一台windows,因为已经有一台iMac,所以打算留一台windows以备不时之需。以前用windows最大的问题是开发环境不好搭,在morningstar的时候,自己装了个vmware跑Ubuntu,但是性能很不爽。而如今windows直接上WSL,在系统底层跑linux子系统,性能和直接用windows没差,简直飞起。而且由于linux子系统和windows主系统共享文件系统和网络,在linux里面跑的服务,直接可以在windows上访问,减少了各种配置工作。而且说实话,windows上的软件,虽然界面确实没有mac好看,但是从功能完整性讲,绝对比mac好很多,在加上winget,总之,现在我已经有点享受windows上开发的乐趣了。
-
WSL简直太棒了, 有时候在win上装node的package必须要linux环境,现在直接用vscode一键wsl搞定, 配合自家的vscode用起来简直不要太爽了,完全就是为开发者准备的.#1029 maoa mao 2021-04-17 02:29
JS 糟粕之全局变量和引用
JS的全局变量是排第一的糟粕。比如:
const a = 1
function get() {
retun a
}
函数内可以直接使用一个函数外的变量,而且可以层层往上引用。如果这个变量还是对象的话,还可以修改对象。例如:
const o = { count: 0 }
function set(count) {
o.count = count
}
这种写法,由于我们写JS写的久了,觉得天经地义,而且还是个与其他语言不同的特性(优点),殊不知,这种东西,害人害己。
全局变量的设计,会使得内存引用及其复杂,且导致内存溢出。虽然js是自动回收垃圾,但是实际上很多情况下开发者需要自己手动释放,而且由于全局变量这个特性,根本释放不了。
如果要改进这门语言,我觉得可以学习rust,去掉全局变量这种东西。
const a = 1
function get(&a) {
return a
}
const b = get(a) // b === a === 1
let b = a // a === null, b === 1
// ---------------
mut o = { count: 1 }
function set(mut &o, int count) {
o.count = count
}
function clone(o) {
return o
}
const n = clone(o)
虽然这使得这门语言麻烦很多,理解起来更复杂,但是可以避免很多问题。
react jsx编译后中文乱码问题
在一次开发中,我发现,构建出来的react应用出现中文乱码现象。于是我很自觉的,在html头部添加 <meta charset="utf-8" />,然后问题解决了。但是作为资深搬砖人,必须得搞清楚,为啥会乱码。
于是我打开了构建后的文件,发现里面中文被转码为unicode了。
这就尴尬了,但是经过观察之后,我又发现,只有createElement的部分被转码,其他部分的中文还是中文。
于是我想,肯定是编译工具在搞鬼,我得找到是哪个地方的问题,把这个转译给关闭。要么是webpack,要么是babel jsx。
于是还是用bing进行中文搜索,没有一个结果指向这个问题。再用英文搜,也没有找到相关解决办法。最后只能请出google大神,找到这个栈漏答案,找到了相关资料。兜兜转转一大圈,发现这是react自己埋的坑,跟编译工具无关(也有关),总之就是关不掉,只能这样,放弃挣扎。
-
之前也有遇到这情况, 想改个项目里的标题, 搜中文搜不到, 结果发现是unicode#1015 ID_1188 2021-03-02 16:29
我时常有一些执念,以至于有的时候不合群。我遇到无法修改react传入的props的情况,我大概知道在react源码里面干了些坏事,但是我想确认这一点,于是我在bing搜索相关问题。大部分的答案,无非是和react单向数据流相关的一些废话,谁不知道这些原则,我现在就是想打破这些原则,而我打破不了,你只告诉我原则就是根源,我呸!然后我找了很久,在漏栈上找到一个答案 https://stackoverflow.com/questions/26089532/why-cant-i-update-props-in-react-js 这个答案获得了20个反对票,最主要的原因在于,他指出只有通过修改react核心代码才能实现,于是被一路狂喷。我……我被气炸了!这个回答直指问题本质,就是react中使用Object.freeze(element.props)导致我们修改props会报错。我tm不懂,为啥真正指出问题所在的答案被驳20次,而千篇一律的讲废话的答案得到大量赞同。真是只要主义,不要实际!
-
因为 react 社区动辄喜欢谈设计理念,原则之类的,不考虑实际使用者的场景
-
有的时候爱,有的时候恨,选择太少了#1007 回复给#1006 否子戈 2021-02-05 19:52
-
没,有时候吾辈反而觉得前端选择太多了,各种乱七八糟的工具链和层出不穷的类似的轮子,上层应用的基础变化太快了。。。
-
有趣的例子.#1009 ID_1188 2021-02-09 15:40