update readme

fix 52 typo: 查分 -> 差分

readme.md

@@ -6,7 +6,7 @@
 
 前端界的好文精读，每周更新！
 
-最新精读：<a href="./前沿技术/205.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20with%20%E8%AF%AD%E6%B3%95%E3%80%8B.md">205.精读《JS with 语法》</a>
+最新精读：<a href="./前沿技术/211.%E7%B2%BE%E8%AF%BB%E3%80%8AMicrosoft%20Power%20Fx%E3%80%8B.md">211.精读《Microsoft Power Fx》</a>
 
 素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
 
@@ -163,6 +163,12 @@
 - <a href="./前沿技术/202.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%2018%E3%80%8B.md">202.精读《React 18》</a>
 - <a href="./前沿技术/204.%E7%B2%BE%E8%AF%BB%E3%80%8A%E9%BB%98%E8%AE%A4%E3%80%81%E5%91%BD%E5%90%8D%E5%AF%BC%E5%87%BA%E7%9A%84%E5%8C%BA%E5%88%AB%E3%80%8B.md">204.精读《默认、命名导出的区别》</a>
 - <a href="./前沿技术/205.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20with%20%E8%AF%AD%E6%B3%95%E3%80%8B.md">205.精读《JS with 语法》</a>
+- <a href="./前沿技术/206.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%B8%80%E7%A7%8D%20Hooks%20%E6%95%B0%E6%8D%AE%E6%B5%81%E7%AE%A1%E7%90%86%E6%96%B9%E6%A1%88%E3%80%8B.md">206.精读《一种 Hooks 数据流管理方案》</a>
+- <a href="./前沿技术/207.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%20infer%20%E5%85%B3%E9%94%AE%E5%AD%97%E3%80%8B.md">207.精读《Typescript infer 关键字》</a>
+- <a href="./前沿技术/208.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204.4%E3%80%8B.md">208.精读《Typescript 4.4》</a>
+- <a href="./前沿技术/209.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%8D%95%E8%8E%B7%E6%89%80%E6%9C%89%E5%BC%82%E6%AD%A5%20error%E3%80%8B.md">209.精读《捕获所有异步 error》</a>
+- <a href="./前沿技术/210.%E7%B2%BE%E8%AF%BB%E3%80%8Aclass%20static%20block%E3%80%8B.md">210.精读《class static block》</a>
+- <a href="./前沿技术/211.%E7%B2%BE%E8%AF%BB%E3%80%8AMicrosoft%20Power%20Fx%E3%80%8B.md">211.精读《Microsoft Power Fx》</a>
 
 ### 设计模式
 

前沿技术/206.精读《一种 Hooks 数据流管理方案》.md

@@ -0,0 +1,248 @@
+维护大型项目 OR UI 组件模块时，一定会遇到全局数据传递问题。
+
+维护项目时，像全局用户信息、全局项目配置、全局功能配置等等，都是跨模块复用的全局数据。
+
+维护 UI 组件时，调用组件的入口只有一个，但组件内部会继续拆模块，分文件，对于这些组件内模块而言，入口文件的参数也就是全局数据。
+
+这时一般有三种方案：
+
+1. props 透传。
+2. 上下文。
+3. 全局数据流。
+
+props 透传方案，因为任何一个节点掉链子都会导致参数传递失败，因此带来的维护成本与心智负担都特别大。
+
+上下文即 `useContext` 利用上下文共享全局数据，带来的问题是更新粒度太粗，同上下文中任何值的改变都会导致重渲染。有一种较为 Hack 的解决方案 [use-context-selector](https://github.com/dai-shi/use-context-selector)，不过这个和下面说到的全局数据流很像。
+
+全局数据流即利用 `react-redux` 等工具，绕过 React 更新机制进行全局数据传递的方案，这种方案较好解决了项目问题，但很少有组件会使用。以前也有过不少利用 Redux 做局部数据流的方案，但本质上还是全局数据流。现在 `react-redux` 支持了局部作用域方案：
+
+```javascript
+import { shallowEqual, createSelectorHook, createStoreHook } from 'react-redux'
+
+const context = React.createContext(null)
+const useStore = createStoreHook(context)
+const useSelector = createSelectorHook(context)
+const useDispatch = createDispatchHook(context)
+```
+
+因此是机会好好梳理一下数据流管理方案，做一个项目、组件通用的数据流管理方案。
+
+## 精读
+
+对项目、组件来说，数据流包含两种数据：
+
+1. 可变数据。
+2. 不可变数据。
+
+对项目来说，可变数据的来源有：
+
+1. 全局外部参数。
+2. 全局项目自定义变量。
+
+不可变数据来源有：
+
+1. 操作数据或行为的函数方法。
+
+> 全局外部参数指不受项目代码控制的，比如登陆用户信息数据。全局项目自定义变量是由项目代码控制的，比如定义了一些模型数据、状态数据。
+
+对组件来说，可变数据的来源有：
+
+1. 组件被调用时的传参。
+2. 全局组件自定义变量。
+
+不可变数据来源有：
+
+1. 组件被调用时的传参。
+2. 操作数据或行为的函数方法。
+
+对组件来说，被调用时的传参既可能是可变数据，也可能是不可变数据。比如传入的 `props.color` 可能就是可变数据，而 `props.defaultValue`、`props.onChange` 就是不可变数据。
+
+当梳理清楚项目与组件到底有哪些全局数据后，我们就可以按照注册与调用这两步来设计数据流管理规范了。
+
+### 数据流调用
+
+首先来看调用。为了同时保证使用的便捷与应用程序的性能，我们希望使用一个统一的 API `useXXX` 来访问所有全局数据与方法，并满足：
+
+1. `{} = useXXX()` 只能引用到不可变数据，包括变量与方法。
+2. `{ value } = useXXX(state => ({ value: state.value }))` 可以引用到可变数据，但必须通过选择器来调用。
+
+比如一个应用叫 `gaea`，那么 `useGaea` 就是对这个应用全局数据的唯一调用入口，我可以在组件里这么调用数据与方法：
+
+```typescript
+const Panel = () => {
+  // appId 是应用不可变数据，所以即使是变量也可以直接获取，因为它不会变化，也不会导致重渲染
+  // fetchData 是取数函数，内置发送了 appId，所以绑定了一定上下文，也属于不可变数据
+  const { appId, fetchData } = useGaea()
+
+  // 主题色可能在运行时修改，只能通过选择器获取
+  // 此时这个组件会额外在 color 变化时重渲染
+  const { color } = useGaea(state => ({
+    color: state.theme?.color
+  }))
+}
+```
+
+比如一个组件叫 `Menu`，那么 `useMenu` 就是这个组件的全局数据调用入口，可以这么使用：
+
+```typescript
+// SubMenu 是 Menu 组件的子组件，可以直接使用 useMenu
+const SubMenu = () => {
+  // defaultValue 是一次性值，所以处理时做了不可变处理，这里已经是不可变数据了
+  // onMenuClick 是回调函数，不管传参引用如何变化，这里都处理成不可变的引用
+  const { defaultValue, onMenuClick } = useMenu()
+
+  // disabled 是 menu 的参数，需要在变化时立即响应，所以是可变数据
+  const { disabled } = useMenu(state => ({
+    disabled: state.disabled
+  }))
+
+  // selectedMenu 是 Menu 组件的内部状态，也作为可变数据调用
+  const { selectedMenu } = useMenu(state => ({
+    selectedMenu: state.selectedMenu
+  }))
+}
+```
+
+可以发现，在整个应用或者组件的使用 Scope 中，已经做了一层抽象，即不关心数据是怎么来的，只关心数据是否可变。这样对于组件或应用，随时可以将内部状态开放到 API 层，而内部代码完全不用修改。
+
+### 数据流注册
+
+数据流注册的时候，我们只要定义三种参数：
+
+1. `dynamicValue`: 动态参数，通过 `useInput(state => state.xxx)` 才能访问到。
+2. `staticValue`: 静态参数，引用永远不会改变，可以直接通过 `useInput().xxx` 访问到。
+3. 自定义 hooks，入参是 `staticValue` `getState` `setState`，这里可以封装自定义方法，并且定义的方法都必须是静态的，可以直接通过 `useInput().xxx` 访问到。
+
+```typescript
+const { useState: useInput, Provider } = createHookStore<{
+  dynamicValue: {
+    fontSize: number
+  }
+  staticValue: {
+    onChange: (value: number) => void
+  }
+}>(({ staticValue }) => {
+  const onCustomChange = React.useCallback((value: number) => {
+    staticValue.onChange(value + 1)
+  }, [staticValue])
+
+  return React.useMemo(() => ({
+    onCustomChange
+  }), [onCustomChange])
+})
+```
+
+上面的方法暴露了 `Provider` 与 `useInput` 两个对象，我们首先需要在组件里给它传输数据。比如我写的是组件 `Input`，就可以这么调用：
+
+```jsx
+function Input({ onChange, fontSize }) {
+  return (
+    <Provider dynamicValue={{fontSize}} staticValue={{onChange}}>
+      <InputComponent />
+    </Provider>
+  )
+}
+```
+
+如果对于某些动态数据，我们只想赋初值，可以使用 `defaultDynamicValue`：
+
+```jsx
+function Input({ onChange, fontSize }) {
+  return (
+    <Provider dynamicValue={{fontSize}} defaultDynamicValue={{count: 1}}>
+      <InputComponent />
+    </Provider>
+  )
+}
+```
+
+这样 `count` 就是一个动态值，必须通过 `useInput(state => ({ count: state.count }))` 才能取到，但又不会因为外层组件 Rerender 而被重新赋值为 `1`。所有动态值都可以通过 `setState` 来修改，这个后面再说。
+
+这样所有 Input 下的子组件就可以通过 `useInput` 访问到全局数据流的数据啦，我们有三种访问数据的场景。
+
+一：访问传给 `Input` 组件的 `onChange`。
+
+因为 `onChange` 是不可变对象，因此可以通过如下方式访问：
+
+```typescript
+function InputComponent() {
+  const { onChange } = useInput()
+}
+```
+
+二：访问我们自定义的全局 Hooks 函数 `onCustomChange`：
+
+```typescript
+function InputComponent() {
+  const { onCustomChange } = useInput()
+}
+```
+
+三：访问可能变化的数据 `fontSize`。由于我们需要在 `fontSize` 变化时让组件重渲染，又不想让上面两种调用方式受到 `fontSize` 的影响，需要通过如下方式访问：
+
+```typescript
+function InputComponent() {
+  const { fontSize } = useInput(state => ({
+    fontSize: state.fontSize
+  }))
+}
+```
+
+最后在自定义方法中，如果我们想修改可变数据，都要通过 `updateStore` 封装好并暴露给外部，而不能直接调用。具体方式是这样的，举个例子，假设我们需要定义一个应用状态 `status`，其可选值为 `edit` 与 `preview`，那么可以这么去定义：
+
+```jsx
+const { useState: useInput, Provider } = createHookStore<{
+  dynamicValue: {
+    isAdmin: boolean
+    status: 'edit' | 'preview'
+  }
+}>(({ getState, setState }) => {
+  const toggleStatus = React.useCallback(() => {
+    // 管理员才能切换应用状态
+    if (!getState().isAdmin) {
+      return
+    }
+
+    setState(state => ({
+      ...state,
+      status: state.status === 'edit' ? 'preview' : 'edit'
+    }))
+  }, [getState, setState])
+
+  return React.useMemo(() => ({
+    toggleStatus
+  }), [toggleStatus])
+})
+```
+
+下面是调用：
+
+```jsx
+function InputComponent() {
+  const { toggleStatus } = useInput()
+
+  return (
+    <button onClick={toggleStatus} />
+  )
+}
+```
+
+而且整个链路的类型定义也是完全自动推导的，这套数据流管理方案到这里就讲完了。
+
+## 总结
+
+对全局数据的使用，最方便的就是收拢到一个 `useXXX` API，并且还能区分静态、动态值，并在访问静态值时完全不会导致重渲染。
+
+而之所以动态值 `dynamicValue` 需要在 `Provider` 里定义，是因为当动态值变化时，会自动更新数据流中的数据，使整个应用数据与外部动态数据同步。而这个更新步骤就是通过 Redux Store 来完成的。
+
+本文特意没有给出实现源码，感兴趣的同学可以自己实现一个试一试。
+
+> 讨论地址是：[精读《一种 Hooks 数据流管理方案》· Issue #345 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/345)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/207.精读《Typescript infer 关键字》.md

@@ -0,0 +1,115 @@
+Infer 关键字用于条件中的类型推导。
+
+Typescript 官网也拿 `ReturnType` 这一经典例子说明它的作用：
+
+```typescript
+type ReturnType<T> = T extends (...args: any[]) => infer R ? R : any;
+```
+
+理解为：如果 `T` 继承了 `(...args: any[]) => any` 类型，则返回类型 `R`，否则返回 `any`。其中 `R` 是什么呢？`R` 被定义在 `extends (...args: any[]) => infer R` 中，即 R 是从传入参数类型中推导出来的。
+
+## 精读
+
+我们可以从两个视角来理解 `infer`，分别是需求角度与设计角度。
+
+### 需求角度理解 infer
+
+实现 `infer` 这个关键字一定是背后存在需求，这个需求是普通 Typescript 能力无法满足的。
+
+设想这样一个场景：实现一个函数，接收一个数组，返回第一项。
+
+我们无法用泛型来描述这种类型推导，因为泛型类型是一个整体，而我们想要返回的是入参其中某一项，我们并不能通过类似 `T[0]` 的写法拿到第一项类型：
+
+```typescript
+function xxx<T>(...args: T[]): T[0]
+```
+
+而实际上不支持这种写法也是合理的，因为这次是获取第一项类型，如果 `T` 是一个对象，我们想返回其中 `onChange` 这个 Key 的返回值类型，就不知道如何书写了。所以此时必须用一种新的语法实现，就是 `infer`。
+
+### 设计角度理解 infer
+
+从类型推导功能来看，泛型功能非常强大，我们可以用泛型描述调用时才传入的类型，并提前将它描述在类型表达式中：
+
+```typescript
+function xxx<T>(value: T): { result: T }
+```
+
+但我们发现 `T` 这个泛型太整体化了，我们还不具备从中 Pick 子类型的能力。也就是对于 `xxx<{label: string}>` 这个场景，`T = {label: string}`，但我们无法将 `R` 定义为 `{label: R}` 这个位置，因为泛型是一个不可拆分的整体。
+
+而且实际上为了类型安全，我们也不能允许用户描述任意的类型位置，**万一传入的类型结构不是 `{label: xxx}` 而是一个回调 `() => void`，那子类型推导岂不是建立在了错误的环境中。** 所以考虑到想要拿到 `{label: infer R}`，首先参数必须具备 `{label: xxx}` 的结构，所以正好可以将 `infer` 与条件判断 `T extends xxx ? A : B` 结合起来用，即：
+
+```typescript
+type GetLabelTypeFromObject<T> = T extends { label: infer R } ? R : never
+
+type Result = GetLabelTypeFromObject<{ label: string }>;
+// type Result = string
+```
+
+即如果 `T` 遵循 `{ label: any }` 这样一个结构，那么我可以将这个结构中任何变量位置替换为 `infer xxx`，如果传入类型满足这个结构（TS 静态解析环节判断），则可以基于这个结构体继续推导，所以在推导过程中我们就可以使用 `infer xxx` 推断的变量类型。
+
+回过头来看第一个需求，拿到第一个参数类型就可以用 `infer` 实现了：
+
+```typescript
+type GetFirstParamType<T> = T extends (...args: infer R) => any ? R[0] : never
+```
+
+可以理解为，如果此时 `T` 满足 `(...args: any) => any` 这个结构，同时我们用 `infer R` 表示 `R` 这个临时变量指代第一个 `any` 运行时类型，那么整个函数返回的类型就是 `R`。如果 `T` 都不满足 `(...args: any) => any` 这个结构，比如 `GetFirstParamType<number>`，那这种推导根本无从谈起，直接返回 `never` 类型兜底，当然也可以自定义比如 `any` 之类的任何类型。
+
+## 概述
+
+我们理解了 `infer` 含义后，再结合 [conditional infer](https://learntypescript.dev/09/l2-conditional-infer) 这篇文章理解里面的例子，有助于加深记忆。
+
+```typescript
+type ArrayElementType<T> = T extends (infer E)[] ? E : T;
+// type of item1 is `number`
+type item1 = ArrayElementType<number[]>;
+// type of item1 is `{name: string}`
+type item2 = ArrayElementType<{ name: string }>;
+```
+
+可以看到，`ArrayElementType` 利用了条件推断与 `infer`，表示了这样一个逻辑：如果 `T` 类型是一个数组，且我们将数组的每一项定义为 `E` 类型，那么返回类型就为 `E`，否则为 `T` 整体类型本身。
+
+所以对于 `item1` 是满足结构的，所以返回 `number`，而 `item2` 不满足结构，所以返回其类型本身。
+
+特别补充一点，对于下面的例子返回什么呢？
+
+```typescript
+type item3 = ArrayElementType<[number, string]>;
+```
+
+答案是 `number | string`，原因是我们用多个 `infer E`（`(infer E)[]` 相当于 `[infer E, infer E]...` 不就是多个变量指向同一个类型代词 `E` 嘛）同时接收到了 `number` 和 `string`，所以可以理解为 `E` 时而为 `number` 时而为 `string`，所以是或关系，这就是协变。
+
+那如果是函数参数呢？
+
+```typescript
+type Bar<T> = T extends { a: (x: infer U) => void; b: (x: infer U) => void }
+  ? U : never
+type T21 = Bar<{ a: (x: string) => void; b: (x: number) => void }>; // string & number
+```
+
+发现结果是 `string & number`，也就是逆变。但这个例子也是同一个 `U` 时而为 `string` 时而为 `number` 呀，为什么是且的关系，而不是或呢？
+
+其实协变或逆变与 `infer` 参数位置有关。在 TypeScript 中，对象、类、数组和函数的返回值类型都是协变关系，而函数的参数类型是逆变关系，所以 `infer` 位置如果在函数参数上，就会遵循逆变原则。
+
+> 逆变与协变：
+>
+> - 协变(co-variant)：类型收敛。
+> - 逆变(contra-variant)：类型发散。
+
+关于逆变与协变更深入的话题可以再开一篇文章了，这里就不细讲了，对于 `infer` 理解到这里就够啦。
+
+## 总结
+
+`infer` 关键字让我们拥有深入展开泛型的结构，并 Pick 出其中任何位置的类型，并作为临时变量用于最终返回类型的能力。
+
+对于 Typescript 类型编程，最大的问题莫过于希望实现一个效果却不知道用什么语法，`infer` 作为一个强大的类型推导关键字，势必会在大部分复杂类型推导场景下派上用场，所以在遇到困难时，可以想想是不是能用 `infer` 解决问题。
+
+> 讨论地址是：[精读《Typescript infer 关键字》· Issue #346 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/346)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/208.精读《Typescript 4.4》.md

@@ -0,0 +1,275 @@
+Typescript 4.4 正式发布了！距离 Typescript 4.5 发布还有三个月的时间，抓紧上车学习吧！
+
+本周精读的文章：[announcing-typescript-4-4](https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/)
+
+## 概述
+
+### 更智能的自动类型收窄
+
+类型收窄功能非常方便，它可以让 Typescript 尽可能的像 Js 一样自动智能判定类型，从而避免类型定义的工作，让你的 Typescript 写得更像 Js。
+
+其实这个功能早就有了，在我们 [精读《Typescript2.0 - 2.9》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/58.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript2.0%20-%202.9%E3%80%8B.md#%E8%87%AA%E5%8A%A8%E7%B1%BB%E5%9E%8B%E6%8E%A8%E5%AF%BC) 就已经介绍过，当时用的名词是自动类型推导，这次用了更精确的自动类型收窄一词，因为只有类型收窄是安全的，比如：
+
+```typescript
+function foo(arg: unknown) {
+    if (typeof arg === "string") {
+        // We know 'arg' is a string now.
+        console.log(arg.toUpperCase());
+    }
+}
+```
+
+而在 Typescript 4.4 之前的版本，如果我们将这个判定赋值给一个变量，再用到 `if` 分支里，就无法正常收窄类型了：
+
+```typescript
+function foo(arg: unknown) {
+    const argIsString = typeof arg === "string";
+    if (argIsString) {
+        console.log(arg.toUpperCase());
+        //              ~~~~~~~~~~~
+        // Error! Property 'toUpperCase' does not exist on type 'unknown'.
+    }
+}
+```
+
+这个问题在 Typescript 4.4 得到了解决，实际上是把这种类型收窄判断逻辑加深了，即无论这个判断写在哪都可以生效。所以下面这种解构的用法判断也可以推断出类型收窄：
+
+```typescript
+type Shape =
+    | { kind: "circle", radius: number }
+    | { kind: "square", sideLength: number };
+
+function area(shape: Shape): number {
+    // Extract out the 'kind' field first.
+    const { kind } = shape;
+
+    if (kind === "circle") {
+        // We know we have a circle here!
+        return Math.PI * shape.radius ** 2;
+    }
+    else {
+        // We know we're left with a square here!
+        return shape.sideLength ** 2;
+    }
+}
+```
+
+不仅是单一的判断，Typescript 4.4 还支持复合类型推导：
+
+```typescript
+function doSomeChecks(
+    inputA: string | undefined,
+    inputB: string | undefined,
+    shouldDoExtraWork: boolean,
+) {
+    const mustDoWork = inputA && inputB && shouldDoExtraWork;
+    if (mustDoWork) {
+        // We can access 'string' properties on both 'inputA' and 'inputB'!
+        const upperA = inputA.toUpperCase();
+        const upperB = inputB.toUpperCase();
+        // ...
+    }
+}
+```
+
+`mustDoWork` 为 `true` 的分支就意味着 `inputA`、`inputB` 均收窄为 `string` 类型。
+
+这种深层的判定还体现在，一个具备类型判断的变量进行再计算，生成的变量还具有类型判断功能：
+
+```typescript
+function f(x: string | number | boolean) {
+    const isString = typeof x === "string";
+    const isNumber = typeof x === "number";
+    const isStringOrNumber = isString || isNumber;
+    if (isStringOrNumber) {
+        x;  // Type of 'x' is 'string | number'.
+    }
+    else {
+        x;  // Type of 'x' is 'boolean'.
+    }
+}
+```
+
+可以看到，我们几乎可以像写 Js 一样写 Typescript，4.4 支持了大部分符合直觉的推导非常方便。但要注意的是，Typescript
+毕竟不是运行时，无法做到更彻底的自动推断，但足以支持绝大部分场景。
+
+### 下标支持 Symbol 与模版字符串类型判定
+
+原本我们定义一个用下标访问的对象是这样的：
+
+```typescript
+interface Values {
+  [key: string]: number
+}
+```
+
+现在也支持 Symbol 拉：
+
+```typescript
+interface Colors {
+    [sym: symbol]: number;
+}
+
+const red = Symbol("red");
+const green = Symbol("green");
+const blue = Symbol("blue");
+
+let colors: Colors = {};
+
+colors[red] = 255;          // Assignment of a number is allowed
+let redVal = colors[red];   // 'redVal' has the type 'number'
+
+colors[blue] = "da ba dee"; // Error: Type 'string' is not assignable to type 'number'.
+```
+
+而且对于特定的字符串模版也支持类型匹配，比如希望以 `data-` 开头的下标是一种独立类型，可以这么定义：
+
+```typescript
+interface Options {
+    width?: number;
+    height?: number;
+}
+
+let a: Options = {
+    width: 100,
+    height: 100,
+    "data-blah": true, // Error! 'data-blah' wasn't declared in 'Options'.
+};
+
+interface OptionsWithDataProps extends Options {
+    // Permit any property starting with 'data-'.
+    [optName: `data-${string}`]: unknown;
+}
+
+let b: OptionsWithDataProps = {
+    width: 100,
+    height: 100,
+    "data-blah": true,       // Works!
+
+    "unknown-property": true,  // Error! 'unknown-property' wasn't declared in 'OptionsWithDataProps'.
+};
+```
+
+这个对于 HTML 的 `data-` 属性非常有帮助。
+
+同时还支持联合类型定义，下面两种类型定义方式是等价的：
+
+```typescript
+interface Data {
+    [optName: string | symbol]: any;
+}
+
+// Equivalent to
+
+interface Data {
+    [optName: string]: any;
+    [optName: symbol]: any;
+}
+```
+
+### 更严格的错误捕获类型
+
+在 `unknown` 类型出来之前，Typescript 以 `any` 作为抛出错误的默认类型，毕竟谁也不知道抛出错误的类型是什么：
+
+```typescript
+try {
+    // Who knows what this might throw...
+    executeSomeThirdPartyCode();
+}
+catch (err) { // err: any
+    console.error(err.message); // Allowed, because 'any'
+    err.thisWillProbablyFail(); // Allowed, because 'any' :(
+}
+```
+
+Who knows what this might throw... 这句话很有意思，一个函数任何地方都可能出现运行时错误，这根本不是静态分析可以解决的，所以不可能自动推断错误类型，所以只能用 `any`。
+
+在 Typescript 4.4 的 `--useUnknownInCatchVariables` 或 `--strict` 模式下都将以 `unknown` 作为捕获到错误的默认类型。
+
+相比不存在的类型 `never`，`unknown` 仅仅是不知道是什么类型而已，所以不能像 `any` 一样当作任何类型使用，但我们可以将其随意推断为任意类型：
+
+```typescript
+try {
+    executeSomeThirdPartyCode();
+}
+catch (err) { // err: unknown
+    // Error! Property 'message' does not exist on type 'unknown'.
+    console.error(err.message);
+
+    // Works! We can narrow 'err' from 'unknown' to 'Error'.
+    if (err instanceof Error) {
+        console.error(err.message);
+    }
+}
+```
+
+如果觉得这样做麻烦，也可以重新申明类型为 `any`：
+
+```typescript
+try {
+    executeSomeThirdPartyCode();
+}
+catch (err: any) {
+    console.error(err.message); // Works again!
+}
+```
+
+但这样做其实并不合适，因为即便是考虑了运行时因素，理论上还是可能发生意外错误，所以对错误过于自信的类型推断是不太合适的，最好保持其 `unknown` 类型，对所有可能的边界情况做处理。
+
+### 明确的可选属性
+
+对象的可选属性在类型描述时有个含糊不清的地方，比如：
+
+```typescript
+interface Person {
+    name: string,
+    age?: number;
+}
+```
+
+其实 Typescript 对其的类型定义的是：
+
+```typescript
+interface Person {
+    name: string,
+    age?: number | undefined;
+}
+```
+
+为什么要这么定义呢？因为很多情况下，没有这个 key，与这个 key 的值为 `undefined` 的表现是等价的。但比如 `Object.keys` 场景下这两种表现却又不等价，所以理论上对于 `age?: number` 的确切表述是：要么没有 `age`，要么有 `age` 且类型为 `number`，也就是说下面的写法应该是错误的：
+
+```typescript
+// With 'exactOptionalPropertyTypes' on:
+const p: Person = {
+    name: "Daniel",
+    age: undefined, // Error! undefined isn't a number
+};
+```
+
+在 Typescript 4.4 中同时开启 `--exactOptionalPropertyTypes` 与 `--strictNullChecks` 即可生效。
+
+仔细想想这是合理的，既然定义的类型不是 `undefined`，就算对象是可选类型，也不能认为赋值 `undefined` 是合理的，因为 `age?: number` 的心理预期是，要么没有这个 key，要么有但是类型为 `number`，所以当 `Object.keys` 发现 `age` 这个 key 时，值就应该是 `number`。
+
+### 支持 Static Block
+
+Typescript 4.4 支持了 [class static blocks](https://github.com/tc39/proposal-class-static-block#ecmascript-class-static-initialization-blocks)，并且在代码块作用域内可以访问私有变量。
+
+
+还有一些性能提升与体验优化杂项就不一一列举了，感兴趣可以直接看原文档：[perf-improvements](https://devblogs.microsoft.com/typescript/announcing-typescript-4-4/#perf-improvements)。
+
+
+## 总结
+
+从 Typescript 4.4 特性可以看出，Typescript 正在往 “更具备原生 JS 亲和性” 方向作出努力，这无疑会使 Typescript 变得越来越好用。
+
+对更多新特性感兴趣，可以 [查看 Typescript 4.5 版本发布计划](https://github.com/microsoft/TypeScript/issues/45418)。
+
+> 讨论地址是：[精读《Typescript 4.4》· Issue #348 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/348)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/209.精读《捕获所有异步 error》.md

@@ -0,0 +1,255 @@
+成熟的产品都有较高的稳定性要求，仅前端就要做大量监控、错误上报，后端更是如此，一个未考虑的异常可能导致数据错误、服务雪崩、内存溢出等等问题，轻则每天焦头烂额的处理异常，重则引发线上故障。
+
+假设代码逻辑没有错误，那么剩下的就是异常错误了。
+
+由于任何服务、代码都可能存在外部调用，只要外部调用存在不确定性，代码就可能出现异常，所以捕获异常是一个非常重要的基本功。
+
+所以本周就精读 [How to avoid uncaught async errors in Javascript](https://advancedweb.hu/how-to-avoid-uncaught-async-errors-in-javascript/) 这篇文章，看看 JS 如何捕获异步异常错误。
+
+## 概述
+
+之所以要关注异步异常，是因为捕获同步异常非常简单：
+
+```typescript
+try {
+  ;(() => {
+    throw new Error('err')
+  })()
+} catch (e) {
+  console.log(e) // caught
+}
+```
+
+但异步错误却无法被直接捕获，这不太直观：
+
+```typescript
+try {
+  ;(async () => {
+    throw new Error('err') // uncaught
+  })()
+} catch (e) {
+  console.log(e)
+}
+```
+
+原因是异步代码并不在 `try catch` 上下文中执行，唯一的同步逻辑只有创建一个异步函数，所以异步函数内的错误无法被捕获。
+
+要捕获 `async` 函数内的异常，可以调用 `.catch`，因为 `async` 函数返回一个 Promise：
+
+```typescript
+;(async () => {
+  throw new Error('err')
+})().catch((e) => {
+  console.log(e) // caught
+})
+```
+
+当然也可以在函数体内直接用 `try catch`：
+
+```typescript
+;(async () => {
+  try {
+    throw new Error('err')
+  } catch (e) {
+    console.log(e) // caught
+  }
+})()
+```
+
+类似的，如果在循环体里捕获异常，则要使用 `Promise.all`：
+
+```typescript
+try {
+  await Promise.all(
+    [1, 2, 3].map(async () => {
+      throw new Error('err')
+    })
+  )
+} catch (e) {
+  console.log(e) // caught
+}
+```
+
+也就是说 `await` 修饰的 Promise 内抛出的异常，可以被 `try catch` 捕获。
+
+但不是说写了 `await` 就一定能捕获到异常，一种情况是 Promise 内再包含一个异步：
+
+```typescript
+new Promise(() => {
+  setTimeout(() => {
+    throw new Error('err') // uncaught
+  }, 0)
+}).catch((e) => {
+  console.log(e)
+})
+```
+
+这个情况要用 `reject` 方式抛出异常才能被捕获：
+
+```typescript
+new Promise((res, rej) => {
+  setTimeout(() => {
+    rej('err') // caught
+  }, 0)
+}).catch((e) => {
+  console.log(e)
+})
+```
+
+另一种情况是，这个 `await` 没有被执行到：
+
+```typescript
+const wait = (ms) => new Promise((res) => setTimeout(res, ms))
+
+;(async () => {
+  try {
+    const p1 = wait(3000).then(() => {
+      throw new Error('err')
+    }) // uncaught
+    await wait(2000).then(() => {
+      throw new Error('err2')
+    }) // caught
+    await p1
+  } catch (e) {
+    console.log(e)
+  }
+})()
+```
+
+`p1` 等待 3s 后抛出异常，但因为 2s 后抛出了 `err2` 异常，中断了代码执行，所以 `await p1` 不会被执行到，导致这个异常不会被 catch 住。
+
+而且有意思的是，如果换一个场景，提前执行了 `p1`，等 1s 后再 `await p1`，那异常就从无法捕获变成可以捕获了，这样浏览器会怎么处理？
+
+```typescript
+const wait = (ms) => new Promise((res) => setTimeout(res, ms))
+
+;(async () => {
+  try {
+    const p1 = wait(1000).then(() => {
+      throw new Error('err')
+    })
+    await wait(2000)
+    await p1
+  } catch (e) {
+    console.log(e)
+  }
+})()
+```
+
+结论是浏览器 1s 后会抛出一个未捕获异常，但再过 1s 这个未捕获异常就消失了，变成了捕获的异常。
+
+这个行为很奇怪，当程序复杂时很难排查，因为并行的 Promise 建议用 Promise.all 处理：
+
+```typescript
+await Promise.all([
+  wait(1000).then(() => {
+    throw new Error('err')
+  }), // p1
+  wait(2000),
+])
+```
+
+另外 Promise 的错误会随着 Promise 链传递，因此建议把 Promise 内多次异步行为改写为多条链的模式，在最后 `catch` 住错误。
+
+还是之前的例子，Promise 无法捕获内部的异步错误：
+
+```typescript
+new Promise((res, rej) => {
+  setTimeout(() => {
+    throw Error('err')
+  }, 1000) // 1
+}).catch((error) => {
+  console.log(error)
+})
+```
+
+但如果写成 Promise Chain，就可以捕获了：
+
+```typescript
+new Promise((res, rej) => {
+  setTimeout(res, 1000) // 1
+})
+  .then((res, rej) => {
+    throw Error('err')
+  })
+  .catch((error) => {
+    console.log(error)
+  })
+```
+
+原因是，用 Promise Chain 代替了内部多次异步嵌套，这样多个异步行为会被拆解为对应 Promise Chain 的同步行为，Promise 就可以捕获啦。
+
+最后，DOM 事件监听内抛出的错误都无法被捕获：
+
+```typescript
+document.querySelector('button').addEventListener('click', async () => {
+  throw new Error('err') // uncaught
+})
+```
+
+同步也一样：
+
+```typescript
+document.querySelector('button').addEventListener('click', () => {
+  throw new Error('err') // uncaught
+})
+```
+
+只能通过函数体内 `try catch` 来捕获。
+
+## 精读
+
+我们开篇提到了要监控所有异常，仅通过 `try catch`、`then` 捕获同步、异步错误还是不够的，因为这些是局部错误捕获手段，当我们无法保证所有代码都处理了异常时，需要进行全局异常监控，一般有两种方法：
+
+- `window.addEventListener('error')`
+- `window.addEventListener('unhandledrejection')`
+
+`error` 可以监听所有同步、异步的运行时错误，但无法监听语法、接口、资源加载错误。而 `unhandledrejection` 可以监听到 Promise 中抛出的，未被 `.catch` 捕获的错误。
+
+在具体的前端框架中，也可以通过框架提供的错误监听方案解决部分问题，比如 React 的 [Error Boundaries](https://reactjs.org/docs/error-boundaries.html)、Vue 的 [error handler](https://v3.vuejs.org/api/application-config.html#errorhandler)，一个是 UI 组件级别的，一个是全局的。
+
+回过头来看，本身 js 提供的 `try catch` 错误捕获是非常有效的，之所以会遇到无法捕获错误的经常，大多是因为异步导致的。
+
+然而大部分异步错误，都可以通过 `await` 的方式解决，我们唯一要注意的是，`await` 仅支持一层，或者说一条链的错误监听，比如这个例子是可以监听到错误的：
+
+```typescript
+try {
+  await func1()
+} catch (err) {
+  // caught
+}
+
+async function func1() {
+  await func2()
+}
+
+async function func2() {
+  throw Error('error')
+}
+```
+
+也就是说，只要这一条链内都被 `await` 住了，那么最外层的 `try catch` 就能捕获异步错误。但如果有一层异步又脱离了 `await`，那么就无法捕获了：
+
+```typescript
+async function func2() {
+  setTimeout(() => {
+    throw Error('error') // uncaught
+  })
+}
+```
+
+针对这个问题，原文也提供了例如 `Promise.all`、链式 Promise、`.catch` 等方法解决，因此只要编写代码时注意对异步的处理，就可以用 `try catch` 捕获这些异步错误。
+
+## 总结
+
+关于异步错误的处理，如果还有其它未考虑到的情况，欢迎留言补充。
+
+> 讨论地址是：[精读《捕获所有异步 error》· Issue #350 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/350)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/210.精读《class static block》.md

@@ -0,0 +1,142 @@
+[class-static-block](https://github.com/tc39/proposal-class-static-block) 提案于 [2021.9.1](https://github.com/tc39/proposal-class-static-block/commit/c0cabee0aa2d036a8d902fea7bc1d179e3de2477) 进入 stage4，是一个基于 Class 增强的提案。
+
+本周我们结合 [ES2022 feature: class static initialization blocks](https://2ality.com/2021/09/class-static-block.html) 这篇文章一起讨论一下这个特性。
+
+## 概述
+
+为什么我们需要 class static block 这个语法呢？其中一个原因是对 Class 静态变量的灵活赋值需求。以下面为例，我们想在 Class 内部对静态变量做批量初始化，就不得不写一个无用的 `_` 变量用来做初始化的逻辑：
+
+```typescript
+class Translator {
+  static translations = {
+    yes: 'ja',
+    no: 'nein',
+    maybe: 'vielleicht',
+  };
+  static englishWords = [];
+  static germanWords = [];
+  static _ = initializeTranslator( // (A)
+    this.translations, this.englishWords, this.germanWords);
+}
+function initializeTranslator(translations, englishWords, germanWords) {
+  for (const [english, german] of Object.entries(translations)) {
+    englishWords.push(english);
+    germanWords.push(german);
+  }
+}
+```
+
+而且我们为什么把 `initializeTranslator` 写在外面呢？就因为在 Class 内部不能写代码块，但这造成一个严重的问题，是外部函数无法访问 Class 内部属性，所以需要做一堆枯燥的传值。
+
+从这个例子看出，我们为了自定义一段静态变量初始化逻辑，需要做出两个妥协：
+
+1. 在外部定义一个函数，并接受大量 Class 成员变量传参。
+2. 在 Class 内部定义一个无意义的变量 `_` 用来启动这个函数逻辑。
+
+这实在太没有代码追求了，我们在 Class 内部做掉这些逻辑不就简洁了吗？这就是 class static block 特性：
+
+```typescript
+class Translator {
+  static translations = {
+    yes: 'ja',
+    no: 'nein',
+    maybe: 'vielleicht',
+  };
+  static englishWords = [];
+  static germanWords = [];
+  static { // (A)
+    for (const [english, german] of Object.entries(this.translations)) {
+      this.englishWords.push(english);
+      this.germanWords.push(german);
+    }
+  }
+}
+```
+
+可以看到，`static` 关键字后面不跟变量，而是直接跟一个代码块，就是 class static block 语法的特征，在这个代码块内部，可以通过 `this` 访问 Class 所有成员变量，包括 `#` 私有变量。
+
+原文对这个特性使用介绍就结束了，最后还提到一个细节，就是执行顺序。即所有 `static` 变量或区块都按顺序执行，父类优先执行：
+
+```typescript
+class SuperClass {
+  static superField1 = console.log('superField1');
+  static {
+    assert.equal(this, SuperClass);
+    console.log('static block 1 SuperClass');
+  }
+  static superField2 = console.log('superField2');
+  static {
+    console.log('static block 2 SuperClass');
+  }
+}
+
+class SubClass extends SuperClass {
+  static subField1 = console.log('subField1');
+  static {
+    assert.equal(this, SubClass);
+    console.log('static block 1 SubClass');
+  }
+  static subField2 = console.log('subField2');
+  static {
+    console.log('static block 2 SubClass');
+  }
+}
+
+// Output:
+// 'superField1'
+// 'static block 1 SuperClass'
+// 'superField2'
+// 'static block 2 SuperClass'
+// 'subField1'
+// 'static block 1 SubClass'
+// 'subField2'
+// 'static block 2 SubClass'
+```
+
+所以 Class 内允许有多个 class static block，父类和子类也可以有，不同执行顺序结果肯定不同，这个选择权交给了使用者，因为执行顺序和书写顺序一致。
+
+## 精读
+
+结合提案来看，class static block 还有一个动机，就是给了一个访问私有变量的机制：
+
+```typescript
+let getX;
+
+export class C {
+  #x
+  constructor(x) {
+    this.#x = { data: x };
+  }
+
+  static {
+    // getX has privileged access to #x
+    getX = (obj) => obj.#x;
+  }
+}
+
+export function readXData(obj) {
+  return getX(obj).data;
+}
+```
+
+理论上外部无论如何都无法访问 Class 私有变量，但上面例子的 `readXData` 就可以，而且不会运行时报错，原因就是其整个流程都是合法的，最重要的原因是，class static block 可以同时访问私有变量与全局变量，所以可以利用其做一个 “里应外合”。
+
+不过我并不觉得这是一个好点子，反而像一个 "BUG"，因为任何对规定的突破都会为可维护性埋下隐患，除非这个特性用在稳定的工具、框架层，用来做一些便利性工作，最终提升了应用编码的体验，这种用法是可以接受的。
+
+最后要意识到，class static block 本质上并没有增加新功能，我们完全可以用普通静态变量代替，只是写起来很不自然，所以这个特性可以理解为对缺陷的补充，或者是语法完善。
+
+## 总结
+
+总的来说，class static block 在 Class 内创建了一个块状作用域，这个作用域内拥有访问 Class 内部私有变量的特权，且这个块状作用域仅在引擎调用时初始化执行一次，是一个比较方便的语法。
+
+原文下方有一些反对声音，说这是对 JS 的复杂化，也有诸如 JS 越来越像 Java 的声音，不过我更赞同作者的观点，也就是 Js 中 Class 并不是全部，现在越来越多代码使用函数式语法，即便使用了 Class 的场景也会存在大量函数申明，所以 class static block 这个提案对开发者的感知实际上并不大。
+
+> 讨论地址是：[精读《class static block》· Issue #351 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/351)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/211.精读《Microsoft Power Fx》.md

@@ -0,0 +1,122 @@
+Power Fx 是一门语言，虽然它被推荐的场景是低代码，但我们必须以一门语言角度看待它，才能更好的理解。
+
+Power Fx 的创建是为了更好的辅助非专业开发人员，因此这门语言被设计的足够简单，希望这门语言可以同时服务于专业与非专业开发者，这是个非常崇高的理想。
+
+本周我们就随着 [Microsoft Power Fx 概述](https://docs.microsoft.com/zh-cn/power-platform/power-fx/overview) 这篇文章，详细了解一下这门语言是怎么做的。
+
+## 概述
+
+```javascript
+Notify("this is a problem", Error)
+```
+
+这就是 Power Fx 语言的一个例子，乍一看没什么特别的。
+
+Power Fx 描述的是画布应用公式语言，也就是说，这个编程语言是专门为画布引用设计的。
+
+那什么是画布应用呢？低代码、网站搭建、BI、Web Excel 这些统统都是画布应用，所以 Power Fx 其实是一门适应画布场景的语言，直接面向用户。
+
+那这种画布语言应该具备什么特性呢？Power Fx 团队已经有了一些思考：
+
+- 简单：该语言设计本着简介简单的原则，这样才方便非开发人员上手。
+- Excel 一致性：可以帮助 Excel 开发者做知识迁移，一部分是和微软 Excel 太成功了有关，另一方面 Excel 表达式在画布语言领域探索确实深入，有可取性。对不能满足的尝试借鉴 SQL 这种声明性语言。
+- 声明性：这个最重要，即描述做什么，而不是如何或何时做。这个有点像 Jquery 转到 React 模式时，过程式代码与数据驱动代码的区别。
+- 函数式：函数式在灵活性和易用性上有天然优势，且无副作用的特性也利于理解逻辑与编译优化。
+- 组合：即利用函数式这个特性，推荐利用已有函数组合成新功能，而不是将比如 Sort、Filter 等功能在每个组件上重复实现或者重复配置一遍。
+- 强类型：类型对可维护性至关重要，再强大的低代码语言，如果没有类型支持，都不能称为易上手。
+- 类型推理：可以自动推断类型。这个和强类型一样，有点 TS 的感觉，主要方便书写简洁代码。
+- 不推荐面向对象：既然推荐了函数式，当然不推荐面向对象了。
+- 可推展：开发者要拥有拓展函数与组件的能力，还要支持通过 Javascript 来拓展。
+- 对开发人员友好：这门语言还要在与前面原则不冲突的情况下，尽量对开发人员友好。
+- 语言的迭代：即当语法变更时，要帮助用户平滑迁移，毕竟这门语言直接面向普通用户而非专业开发者。Power Fx 提供了这个能力，对每个文档进行版本标记，并在升级后，通过 “兼容转换器” 自动将老语法升级为新语法。
+- 无 undefined 值：为了简化语言带来的理解成本，移除了 undefined 值这个特定。
+
+所以，基于这些考虑的 Power Fx 设计出来是这样的：
+
+1. 实时性
+
+即无论任何 UI 或语法错误，都不会阻塞其它正常节点的工作，同时代码效果与错误信息实时反馈。这保证了在画布应用编写逻辑的良好体验，因为本身画布应用就是实时的，低代码能力本身也要与画布实时性浑然一体。
+
+<img width=500 src="https://z3.ax1x.com/2021/09/25/4sqx1g.gif">
+
+2. 低代码特征
+
+即任何 UI 组件都不需要描述类似 `onChange` 之类的回调，它们只要申明使用的变量，当这些变量变化时，程序会自动、异步、按需的更新使用到的组件。
+
+3. 与无代码结合
+
+所谓无代码，就是通过 UI 表单可视化的对画布应用进行配置。
+
+与无代码的结合方式是，任意属性都可以用低代码，即表达式编写，但也提供了 UI 表单供编辑，其中 UI 表单编辑后，可以用低代码二次加工，而用低代码编辑的属性，表单就无法编辑了，此时点击表单编辑会跳转到低代码编辑框。
+
+## 精读
+
+创建一门不用学习就能上手的编程语言，需要足够简单，即从用户角度来理解事物：比如用户不知道回调函数等概念，那就屏蔽所谓的回调函数概念，让一切都是表达式。
+
+这些表达式看起来很简单，也符合直觉，并且会自动驱动 UI 重绘，即声明式编程。
+
+下面我们来讨论几个有意思的点：
+
+### 为什么不用 Js
+
+大部分画布应用都是指 Web 应用了，即便是 Excel，现在也早已转型到 Web Excel，就微软来说，早早转型到 Office Online 就能看出来。
+
+然而 Js 是浏览器内置支持的脚本语言，且上手成本也比较低，其实很多低代码平台内置的编程语言就是 Js，其好处是实现成本低（沙箱甚至 `new function`），而 Power Fx 在浏览器平台最终也要转换为 Js 执行，费这么大劲创造一门新语言，无非是觉得 Js 不够 “零门槛”。
+
+首先第一点是不符合 Excel 表达式规范，我们不要忘了 Power Fx 也是有小心机的，它想利用 Excel 生态扩大用户群，所以第一目的是兼容 Excel 语法。比如 Excel 使用 & 链接字符串，而 Js 使用 + 连接，虽然我觉得显然 + 号更自然，但微软觉得还是要符合 Excel 用户习惯。说实话在这一点上，撇开 Excel 的语法，我很难看出为什么 & 连接字符串就 “更易上手”，而 + 连接字符串 “更适合程序员使用”。
+
+但有些是认可的，比如移除了 undefined 值，确实让语言更好理解。
+
+也许未来 Power Fx 会更进一步，引入类 SQL 描述性的语法，像写自然语言一样编程，在这种程度上，配合强类型提示，在特定场景会比 Js 更好用。
+
+### 提供内置函数
+
+Js 提供了大量内置函数，这似乎不是 Power Fx 的专利，但 Power Fx 提供了许多 UI 级别的函数，这可比 Js 点到为止的 `alert` 强多了。
+
+Power Fx 提供了 Confirm、Notify 用于弹出提示窗供用户输入，并且就算要形成逻辑，也只需要几乎一行代码：
+
+```text
+If( Confirm( "Are you sure?", {Title: "Delete Confirmation"} ), Remove( ThisItem ) )
+```
+
+可以看到，这里充斥着异步操作：
+
+- 等待用户输入。
+- 删除元素。
+
+但这些内置函数间的组合将异步效果转换为同步写法，这大大降低开发成本。
+
+另一类内置函数则封装了业务属性，比如 `User` 可以获取当前用户信息。本来获取用户信息就需要代码开发，但低代码平台本身就实现了全套账号体系，因此低代码平台可以直接提供如 `User().Email` 函数访问当前用户的邮箱地址。
+
+还有诸如 `Reset` 函数，可以重制控件为默认值，比如 `Reset( TextInput1 )`，这其实是把平台提供的所有上层能力抽象成低代码函数供用户调用，这样用户只要付出一点点学习成本，就可以获得比简单 UI 强大的多的应用编辑能力，这非常值得我们学习。
+
+更多公式函数可以参考 [文档](https://docs.microsoft.com/zh-cn/powerapps/maker/canvas-apps/formula-reference)。
+
+### 提供对表的操作
+
+[对表的操作](https://docs.microsoft.com/zh-cn/power-platform/power-fx/tables) 让应用数据管理可以和 Excel 同一概念来看待了，这个统一方式就是，把数据抽象成表。Power Fx 提供了系列函数用于表处理：
+
+```text
+AddColumns( 
+    Filter( Products, 'Quantity Requested' > 'Quantity Available' ), 
+    "Quantity To Order", 'Quantity Requested' - 'Quantity Available'
+)
+```
+
+这些函数可以跨语言操作 Excel、Sql Server 等数据源的数据，学习成本与 SQL 类似，其实到这一步，对低代码用户的要求也不低，至少和熟练使用计算公式的 Excel 使用者相当。
+
+## 总结
+
+UI 编辑能力局限但易上手，代码能力最强但难上手，Power Fx 给我们提供了一种折中方案，即提供一种 “高度封装的简化代码” 供用户使用。
+
+纵观其它低代码平台，也有一类采用了另一种折中方案，即超强的复杂编辑 UI，登峰造极的产物便是逻辑编排，这个方向在特定领域也是不错的选择，参考： [精读《低代码逻辑编排》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/197.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BD%8E%E4%BB%A3%E7%A0%81%E9%80%BB%E8%BE%91%E7%BC%96%E6%8E%92%E3%80%8B.md)。
+
+> 讨论地址是：[精读《Microsoft Power Fx》· Issue #355 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/355)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/52.精读《图解 ES 模块》.md

@@ -78,7 +78,7 @@ ES 模块需要借助模块加载器来实现这三步。加载器在不同的
 
 这就意味着我们必须一层一层的遍历文件树，转化文件并找出依赖，最后查找并且加载这些依赖。如果主线程正在等待去下载这些文件，那么很多的任务会堆积在队列中。这是因为浏览器环境下下载用了很长时间。
 
-阻塞主线程会导致应用所需的模块变得很慢。将构建过程分片进行实现了在全部下载前进行获取和构建。这种查分构建的方式是 ES 模块和 CJS 模块最本质的不同。
+阻塞主线程会导致应用所需的模块变得很慢。将构建过程分片进行实现了在全部下载前进行获取和构建。这种差分构建的方式是 ES 模块和 CJS 模块最本质的不同。
 
 ![](https://hacks.mozilla.org/files/2018/03/10_construction-500x302.png)