2022 Week 41

也可以在竹白上订阅更新

Tech

Vercel OG Image Generation

Vercel 新出的用来生成 Open Graph Image 的工具，OG Image 就是分享到社交网络时会展示的封面图，就像这样：

要生成这类动态图片，简单粗暴的方法是在 serverless 平台上运行一个 headless chrome，结合 puppet 来给网页截屏，但这样不仅技术栈就复杂，运行慢，还容易出错。Vercel 的新解决方案是用 html 和 css 的书写方式来生成这张图，就像写一个页面模块。

背后通过 Satori 这个引擎来渲染成 SVG，再结合 SVG 转图像技术来最终生成 PNG 图片。

对实现技术感兴趣的，可以看下 Shuding 的这个 Thread。

This page is a truly naked

很有意思的一篇文章，文章内容本身就是源码，甚至连 style 都有显示，其中用到的主要技术是：

  1. 所有元素都设置为 block，这样一些隐式的 tag 也会显示：<style>* {display:block}</style>
  2. 通过 before::, after:: 给标签添加 content，并设置特定的样式：
html::before {content:'<html>'}
html::after {content:'</html>'}
head::before {content:'<head>'}
head::after {content:'</head>'}
/*...*/

*::before,*::after {
  color:rgba(136, 18, 128, 0.5);
  font-weight:100;
  font-size:1.0em
}

A (Mostly) Complete Guide to React Rendering Behavior

非常棒的一篇介绍 React Render 机制的文章，看完之后相信对 React Render 会有更深的了解。下面是我自己整理的精简版本：

render 其实就是调用 component function 的过程（class component 会更直观些，因为有一个 render 方法）。root component 的 render 方法调用结束后，一棵 React element tree 就构建完成了。

那 React 如何知道该去调用 component 了？这就有一个 mark dirty 的过程，当执行 setState 后，该 component 就脏了，react 就知道它需要被 ReRender 了。

那么 react 是在什么时机知道这个 component 脏了呢？是 callback 么？不是，这样的话效率太低了，有几个 setState 就要执行几次。这里用了类似 event loop 的技术，多个 setState 调用会被打包保存到某个检查点，当下一个 loop 开始时，react 会去各个检查点检查是否有任务需要执行。

如果一个 Parent Component 需要 ReRender，那么它的所有 Children 都会 ReRender，不管 props 是否有变化，因为 React 不知道 Component 内部会不会做什么 Side Effect 的事情，如果要告诉 React 自己是一个 Pure Component，同样的 Props 进来一定会有同样的 Result，那么可以用 React.memo 包一下。

当新一轮的 render 调用结束后，会得到另一棵 React element tree，此时就需要跟之前的 tree 去对比，看看哪里变了，然后再将变化应用到真实的 DOM 上，这个过程就是 Reconciliation。

为了将结果呈现在浏览器上，可以想象 React 内部有两个工人，一个负责 Render，一个负责 Commit。前者的目标是拿到两棵 React element tree，然后交给后者，后者在计算出 Diff 后，将这些 Diff Apply 到 DOM 上。

使用 Context 时，当 Context Provider 的 value 改变后（通常由 Parent Component 设置），所有该 Context 的 Consumer（用到 useContext(Ctx) 的 Component）也都会 ReRender。

The future of rendering in React

从用户体验视角，结合关键指标（TTFB，LCP，TTI等等）聊了下 React 的几种渲染模式。

  • CSR（Client Side Rendering），最简单，但 LCP，TTI 和 SEO 都是问题
  • SSR（Server Side Rendering），解决了 LCP 和 SEO 的问题，但 TTI 没有很好地解决，也有可能带来 TTFB 慢的问题（毕竟要先在服务端拿数据再 renderToString，SSG 部分程度解决了这个问题）
  • Stream SSR（The new rendering patterns），hydration 的一个问题是要一整棵树一起 hydrate，一个是可能的性能问题，还有就是会慢，因为要等一棵树的所有内容都加载完。Stream SSR 要达到的目标是可以做到 component 粒度的 hydrate，后端 stream 一个 component 过来，顺手就 hydrate 掉了，这样就能提升 TTI。一些次级内容（如评论）可以包在 Suspense 里，等服务端传来带数据的渲染后的 component 后，再 hydrate。

再细看下，会发现其实不是所有的 component 都需要交互，那些不需要交互的组件并不需要 hydrate，服务端渲染的 html 完全就够了。这也是本文最后提到的方向，比如对于这类 component，可以以 .server.ts/js 来命名。remix 和 fresh 就是按照这个思路来设计的。

A World-Class Code Playground with Sandpack

文章主要介绍了作者使用 Sandpack 作为 Code Playground 的一些感受，以及对 Sandpack 一些自定义配置的介绍，从效果上看还是挺不错的。

如果想用一个更轻量级的 alternative，可以看下 devjar，源码不多，对于理解实现原理挺有帮助的。

General

卢曼卡片盒笔记法介绍 (Introduction to the Zettelkasten Method)

之前有简单了解过 Zettelkasten 笔记法，由于种种原因没有去严格地实践，终于在某一个晚上，再一次在记笔记这件事上受挫后，决定再细致地研究下 ZK。这篇文章 基本把 Zettelkasten 讲清楚了。有这么几个要点：

  • 原子化笔记
  • 用自己的话描述
  • 笔记间建立连接

原子化笔记，就是每条笔记就讲一个点，之后可以被不同的文章引用。就像一个氧原子，既可以跟氢原子结合生成水，也可以跟碳原子结合生成二氧化碳。

然后这个笔记不能单纯的 Quote 书里或文章里的内容，这样就不是你的笔记，印象也不会深刻，要用自己的话来描述，再附上出处（比如书名）。

在这个笔记里要自然地链接其他笔记，也就是通过上下文的方式，而不是在底部附上其他笔记的链接。如果无法自然地链接，说明笔记之间的连接是不紧密的，而且通过反向引用也看不到上下文。

PS: 我用的 App 是 obsidian，刚发布了 1.0 版本，添加了对 Tab 的支持，默认主题也更加简洁了。

EPR佯谬、量子纠缠、贝尔不等式都是啥？2022年诺贝尔物理学奖最硬核解读！

李永乐老师带来的一期视频，讲了这几位获得诺贝尔物理学奖的大师究竟做了什么。对一些听着很深奥的概念有了一些宏观的理解，基本不需要前置知识。

「EPR佯谬」是爱因斯坦和另两位物理学家构思的一个思想实验，用来反击以玻尔为代表的量子力学派。量子力学认为，不能同一时间测得电子在不同方向上的自旋，但这个思想实验，通过量子纠缠的特性表明可以在不同方向上测得电子的自旋方向，因此量子力学不靠谱。

「量子纠缠」大概就是一对粒子有匹配的特性，比如都往一个方向旋转或者一个带正电另一个带负电，通过检测其中一个的状态就能得知另一个。

「贝尔不等式」的高明之处在于提出了一个可以验证以爱因斯坦为首的反量子力学派和以玻尔为首的量子力学派到底谁是对的的一个理论。通过文氏图的几个集合之间的关系得到一个在经典场景下一定会满足的不等式，如果该不等式被推翻了，则量子力学胜，反之则经典力学（一切状态已确定，只是有隐变量还未被发现）胜。

这几位诺贝尔奖得主则将「贝尔不等式」实验化，通过实验来看这个贝尔不等式是不是真的成立。

项塔兰 on Apple TV+

非常喜欢的一本书「项塔兰」要在 Apple TV 上映了，怎么说呢，那是相当期待了！

👍