Merge branch 'v2' of https://github.com/dt-fe/weekly into v2

Update 148. 精读《React Error Boundaries》.md

148. 精读《React Error Boundaries》.md

@@ -112,7 +112,7 @@ const Child = (props) => {
 
 > componentDidCatch and getDerivedStateFromError: There are no Hook equivalents for these methods yet, but they will be added soon.
 
-所以这里的理解要注意一下，另外 React 官方文档 [Hooks FQA](https://reactjs.org/docs/hooks-faq.html#how-do-lifecycle-methods-correspond-to-hooks) 有很多宝藏，建议抽时间逐条阅读。
+所以这里的理解要注意一下，另外 React 官方文档 [Hooks FAQ](https://reactjs.org/docs/hooks-faq.html#how-do-lifecycle-methods-correspond-to-hooks) 有很多宝藏，建议抽时间逐条阅读。
 
 ## 4 总结
 

150. 精读《Deno 1.0 你需要了解的》.md

@@ -240,7 +240,7 @@ Deno 通过内置一套工具链的方式解决这个问题，包括：
 
 最后，让我们站在一个预言者角度思考一下 Deno 到底会不会火吧：
 
-Deno 做的初心是做一个更好的 Node，但很不信，对于这种级别的生态底层工具来说，重新做一个并重新火起来的难度，不亚于重新做一个阿里巴巴并取代现在阿里的难度。也就是不同的时间点做同一件事，哪怕后者可以吸取教训，大概率也无法复制以前成功的路线。
+Deno 做的初心是做一个更好的 Node，但很不幸，对于这种级别的生态底层工具来说，重新做一个并重新火起来的难度，不亚于重新做一个阿里巴巴并取代现在阿里的难度。也就是不同的时间点做同一件事，哪怕后者可以吸取教训，大概率也无法复制以前成功的路线。
 
 从 Deno 的功能来看，解决了 Node 很多痛点，其中就包括去中心化管理，有点云开发的意思，但在 2020 年，基于 Nodejs 和 Webpack 的云开发都搞出来了，说实话是没有 Deno 什么空间的。从功能上来看，开篇就说了 Deno 基于 V8 解析 Javascript，对于性能和功能都没有革命性提升，从技术上作出突破也几乎不可能了。
 

151. 精读《@umijs use-request》源码.md

@@ -0,0 +1,453 @@
+## 1 引言
+
+与组件生命周期绑定的 Utils 非常适合基于 React Hooks 来做，比如可以将 “发请求” 这个功能与组件生命周期绑定，实现一些便捷的功能。
+
+这次以 [@umijs/use-request](https://hooks.umijs.org/zh-CN/hooks/async) 为例子，分析其功能思路与源码。
+
+## 2 简介
+
+[@umijs/use-request](https://hooks.umijs.org/zh-CN/hooks/async) 支持以下功能：
+
+- 默认自动请求：在组件初次加载时自动触发请求函数，并自动管理 `loading`, `data` , `error` 状态。
+- 手动触发请求：设置 `options.manual = true` , 则手动调用 `run` 时才会取数。
+- 轮询请求：设置 `options.pollingInterval` 则进入轮询模式，可通过 `run` / `cancel` 开始与停止轮询。
+- 并行请求：设置 `options.fetchKey` 可以对请求状态隔离，通过 `fetches` 拿到所有请求状态。
+- 请求防抖：设置 `options.debounceInterval` 开启防抖。
+- 请求节流：设置 `options.throttleInterval` 开启节流。
+- 请求缓存 & SWR：设置 `options.cacheKey` 后开启对请求结果缓存机制，下次请求前会优先返回缓存并在后台重新取数。
+- 请求预加载：由于 `options.cacheKey` 全局共享，可以提前执行 `run` 实现预加载效果。
+- 屏幕聚焦重新请求：设置 `options.refreshOnWindowFocus = true` 在浏览器 `refocus` 与 `revisible` 时重新请求。
+- 请求结果突变：可以通过 `mutate` 直接修改取数结果。
+- 加载延迟：设置 `options.loadingDelay` 可以延迟 `loading` 变成 `true` 的时间，有效防止闪烁。
+- 自定义请求依赖：设置 `options.refreshDeps` 可以在依赖变动时重新触发请求。
+- 分页：设置 `options.paginated` 可支持翻页场景。
+- 加载更多：设置 `options.loadMore` 可支持加载更多场景。
+
+一切 Hooks 的功能拓展都要基于 React Hooks 生命周期，我们可以利用 Hooks 做下面几件与组件相关的事：
+
+1. 存储与当前组件实例绑定的 mutable、immutable 数据。
+2. 主动触发调用组件 rerender。
+3. 访问到组件初始化、销毁时机的钩子。
+
+上面这些功能就可以基于这些基础能力拓展了：
+
+**默认自动请求**
+
+在组件初始时机取数。由于和组件生命周期绑定，可以很方便实现各组件相互隔离的取数顺序强保证：可以利用取数闭包存储 requestIndex，取数结果返回后与当前最新 requestIndex 进行比对，丢弃不一致的取数结果。
+
+**手动触发请求**
+
+将触发取数的函数抽象出来并在 CustomHook 中 return。
+
+**轮询请求**
+
+在取数结束后设定 `setTimeout` 重新触发下一轮取数。
+
+**并行请求**
+
+每次取数时先获取当前请求唯一标识 `fetchKey`，仅更新这个 key 下的状态。
+
+**请求防抖、请求节流**
+
+这个实现方式可以挺通用化，即取数调用函数处替换为对应 `debounce` 或 `throttle` 函数。
+
+**请求预加载**
+
+这个功能只要实现全局缓存就自然支持了。
+
+**屏幕聚焦重新请求**
+
+这个可以统一监听 window action 事件，并触发对应组件取数。可以全局统一监听，也可以每个组件分别监听。
+
+**请求结果突变**
+
+由于取数结果存储在 CustomHook 中，直接修改数据 data 值即可。
+
+**加载延迟**
+
+有加载延迟时，可以先将 `loading` 设置为 `false`，等延迟到了再设置为 `true`，如果此时取数提前完毕则销毁定时器，实现无 loading 取数。
+
+**自定义请求依赖**
+
+利用 `useEffect` 和自带的 deps 即可。
+
+**分页**
+
+基于通用取数 Hook 封装，本质上是多带了一些取数参数与返回值参数，并遵循 Antd Table 的 API。
+
+**加载更多**
+
+和分页类似，区别是加载更多不会清空已有数据，并且需要根据约定返回结构 `noMore` 判断是否能继续加载。
+
+## 3 精读
+
+接下来是源码分析。
+
+首先定义了一个类 `Fetch`，这是因为一个 `useRequest` 的 `fetchKey` 特性可以通过多实例解决。
+
+Class 的生命周期不依赖 React Hooks，所以将不依赖生命周期的操作收敛到 Class 中，不仅提升了代码抽象程度，也提升了可维护性。
+
+```tsx
+class Fetch<R, P extends any[]> {
+  // ...
+  // 取数状态存储处
+  state: FetchResult<R, P> = {
+    loading: false,
+    params: [] as any,
+    data: undefined,
+    error: undefined,
+    run: this.run.bind(this.that),
+    mutate: this.mutate.bind(this.that),
+    refresh: this.refresh.bind(this.that),
+    cancel: this.cancel.bind(this.that),
+    unmount: this.unmount.bind(this.that),
+  };
+
+  constructor(
+    service: Service<R, P>,
+    config: FetchConfig<R, P>,
+    // 外部通过这个回调订阅 state 变化
+    subscribe: Subscribe<R, P>,
+    initState?: { data?: any; error?: any; params?: any; loading?: any }
+  ) {}
+
+  // 此 setState 非彼 setState，作用是更新 state 并通知订阅
+  setState(s = {}) {
+    this.state = {
+      ...this.state,
+      ...s,
+    };
+    this.subscribe(this.state);
+  }
+
+  // 实际取数函数，但下划线命名的带有一些历史气息啊
+  _run(...args: P) {}
+
+  // 对外暴露的取数函数，对防抖和节流做了分发处理
+  run(...args: P) {
+    if (this.debounceRun) {
+      // return ..
+    }
+    if (this.throttleRun) {
+      // return ..
+    }
+    return this._run(...args);
+  }
+
+  // 取消取数，考虑到了防抖、节流兼容性
+  cancel() {}
+
+  // 以上次取数参数重新取数
+  refresh() {}
+
+  // 轮询 starter
+  rePolling() {}
+
+  // 对应 mutate 函数
+  mutate(data: any) {}
+
+  // 销毁订阅
+  unmount() {}
+}
+```
+
+**默认自动请求**
+
+通过 `useEffect` 零依赖实现，需要：
+
+1. 有缓存则不需响应，当对应缓存结束后会通知，同时也支持了请求预加载功能。
+2. 为支持并行请求，所有请求都通过 `fetches` 独立管理。
+
+```tsx
+// 第一次默认执行
+useEffect(() => {
+  if (!manual) {
+    // 如果有缓存
+    if (Object.keys(fetches).length > 0) {
+      /* 重新执行所有的 */
+      Object.values(fetches).forEach((f) => {
+        f.refresh();
+      });
+    } else {
+      // 第一次默认执行，可以通过 defaultParams 设置参数
+      run(...(defaultParams as any));
+    }
+  }
+}, []);
+```
+
+默认执行第 11 行，并根据当前的 `fetchKey` 生成对应 `fetches`，如果初始化已经存在 `fetches`，则行为改为重新执行所有 **已存在的** 并行请求。
+
+**手动触发请求**
+
+上一节已经在初始请求时禁用了 `manual` 开启时的默认取数。下一步只要将封装的取数函数 `run` 定义出来并暴露给用户：
+
+```tsx
+const run = useCallback(
+  (...args: P) => {
+    if (fetchKeyPersist) {
+      const key = fetchKeyPersist(...args);
+      newstFetchKey.current = key === undefined ? DEFAULT_KEY : key;
+    }
+    const currentFetchKey = newstFetchKey.current;
+    // 这里必须用 fetchsRef，而不能用 fetches。
+    // 否则在 reset 完，立即 run 的时候，这里拿到的 fetches 是旧的。
+    let currentFetch = fetchesRef.current[currentFetchKey];
+    if (!currentFetch) {
+      const newFetch = new Fetch(
+        servicePersist,
+        config,
+        subscribe.bind(null, currentFetchKey),
+        {
+          data: initialData,
+        }
+      );
+      currentFetch = newFetch.state;
+      setFeches((s) => {
+        // eslint-disable-next-line no-param-reassign
+        s[currentFetchKey] = currentFetch;
+        return { ...s };
+      });
+    }
+    return currentFetch.run(...args);
+  },
+  [fetchKey, subscribe]
+);
+```
+
+主动取数函数与内部取数函数共享一个，所以 `run` 函数要考虑多种情况，其中之一就是并行取数的情况，因此需要拿到当前取数的 `fetchKey`，并创建一个 `Fetch` 的实例，最终调用 `Fetch` 实例的 `run` 函数取数。
+
+**轮询请求**
+
+轮询取数在 `Fetch` 实际取数函数 `_fetch` 中定义，当取数函数 `fetchService`（对多种形态的取数方法进行封装后）执行完后，无论正常还是报错，都要进行轮询逻辑，因此在 `.finally` 时机里判断：
+
+```tsx
+fetchService.then().finally(() => {
+  if (!this.unmountedFlag && currentCount === this.count) {
+    if (this.config.pollingInterval) {
+      // 如果屏幕隐藏，并且 !pollingWhenHidden, 则停止轮询，并记录 flag，等 visible 时，继续轮询
+      if (!isDocumentVisible() && !this.config.pollingWhenHidden) {
+        this.pollingWhenVisibleFlag = true;
+        return;
+      }
+      this.pollingTimer = setTimeout(() => {
+        this._run(...args);
+      }, this.config.pollingInterval);
+    }
+  }
+});
+```
+
+轮询还要考虑到屏幕是否隐藏，如果可以触发轮询则触发定时器再次调用 `_run`，注意这个定时器需要正常销毁。
+
+**并行请求**
+
+每个 `fetchKey` 对应一个 `Fetch` 实例，这个逻辑在 **手动触发请求** 介绍的 `run` 函数中已经实现。
+
+这块的封装思路可以品味一下，从外到内分别是 React Hooks 的 fetch -> Fetch 类的 run -> Fetch 类的 \_run，并行请求做在 React Hooks 这一层。
+
+**请求防抖、请求节流**
+
+这个实现就在 Fetch 类的 `run` 函数中：
+
+```tsx
+function run(...args: P) {
+  if (this.debounceRun) {
+    this.debounceRun(...args);
+    return Promise.resolve(null as any);
+  }
+  if (this.throttleRun) {
+    this.throttleRun(...args);
+    return Promise.resolve(null as any);
+  }
+  return this._run(...args);
+}
+```
+
+由于防抖和节流是 React 无关的，也不是最终取数无关的，因此实现在 `run` 这个夹层函数进行分发。
+
+这里实现的比较简化，防抖后 `run` 拿到的 Promise 不再是有效的取数结果了，其实这块还是可以进一步对 Promise 进行封装，无论在防抖还是正常取数的场景都返回 Promise，只需 resolve 的时机由 `Fetch` 这个类灵活把控即可。
+
+**请求预加载**
+
+预加载就是缓存机制，首先利用 `useEffect` 同步缓存：
+
+```tsx
+// cache
+useEffect(() => {
+  if (cacheKey) {
+    setCache(cacheKey, {
+      fetches,
+      newstFetchKey: newstFetchKey.current,
+    });
+  }
+}, [cacheKey, fetches]);
+```
+
+在初始化 `Fetch` 实例时优先采用缓存：
+
+```tsx
+const [fetches, setFeches] = useState<Fetches<U, P>>(() => {
+  // 如果有 缓存，则从缓存中读数据
+  if (cacheKey) {
+    const cache = getCache(cacheKey);
+    if (cache) {
+      newstFetchKey.current = cache.newstFetchKey;
+      /* 使用 initState, 重新 new Fetch */
+      const newFetches: any = {};
+      Object.keys(cache.fetches).forEach((key) => {
+        const cacheFetch = cache.fetches[key];
+        const newFetch = new Fetch();
+        // ...
+        newFetches[key] = newFetch.state;
+      });
+      return newFetches;
+    }
+  }
+  return [];
+});
+```
+
+**屏幕聚焦重新请求**
+
+在 `Fetch` 构造函数实现监听并调用 `refresh` 即可，源码里采取全局统一监听的方式：
+
+```tsx
+function subscribe(listener: () => void) {
+  listeners.push(listener);
+  return function unsubscribe() {
+    const index = listeners.indexOf(listener);
+    listeners.splice(index, 1);
+  };
+}
+
+let eventsBinded = false;
+if (typeof window !== "undefined" && window.addEventListener && !eventsBinded) {
+  const revalidate = () => {
+    if (!isDocumentVisible()) return;
+    for (let i = 0; i < listeners.length; i++) {
+      // dispatch 每个 listener
+      const listener = listeners[i];
+      listener();
+    }
+  };
+  window.addEventListener("visibilitychange", revalidate, false);
+  // only bind the events once
+  eventsBinded = true;
+}
+```
+
+在 `Fetch` 构造函数里注册：
+
+```tsx
+this.limitRefresh = limit(this.refresh.bind(this), this.config.focusTimespan);
+
+if (this.config.pollingInterval) {
+  this.unsubscribe.push(subscribeVisible(this.rePolling.bind(this)));
+}
+```
+
+并通过 `limit` 封装控制调用频率，并 push 到 `unsubscribe` 数组，一边监听可以随组件一起销毁。
+
+**请求结果突变**
+
+这个函数只要更新 `data` 数据结果即可：
+
+```tsx
+function mutate(data: any) {
+  if (typeof data === "function") {
+    this.setState({
+      data: data(this.state.data) || {},
+    });
+  } else {
+    this.setState({
+      data,
+    });
+  }
+}
+```
+
+值得注意的是，`cancel`、`refresh`、`mutate` 都必须在初次请求完成后才有意义，所以初次返回的函数是一个抛错：
+
+```tsx
+const noReady = useCallback(
+  (name: string) => () => {
+    throw new Error(`Cannot call ${name} when service not executed once.`);
+  },
+  []
+);
+
+return {
+  loading: !manual || defaultLoading,
+  data: initialData,
+  error: undefined,
+  params: [],
+  cancel: noReady("cancel"),
+  refresh: noReady("refresh"),
+  mutate: noReady("mutate"),
+  ...(fetches[newstFetchKey.current] || {}),
+} as BaseResult<U, P>;
+```
+
+等取数完成后会被 `...(fetches[newstFetchKey.current] || {})` 这一段覆盖为正常函数。
+
+**加载延迟**
+
+如果设置了加载延迟，请求发动时就不应该立即设置为 loading，这个逻辑写在 `_run` 函数中：
+
+```tsx
+function _run(...args: P) {
+  // 取消 loadingDelayTimer
+  if (this.loadingDelayTimer) {
+    clearTimeout(this.loadingDelayTimer);
+  }
+  this.setState({
+    loading: !this.config.loadingDelay,
+    params: args,
+  });
+
+  if (this.config.loadingDelay) {
+    this.loadingDelayTimer = setTimeout(() => {
+      this.setState({
+        loading: true,
+      });
+    }, this.config.loadingDelay);
+  }
+}
+```
+
+启动一个 `setTimeout` 将 loading 设为 `true` 即可，这个 timeout 在下次执行 `_run` 时被 `clearTimeout` 清空。
+
+**自定义请求依赖**
+
+最明智的做法是利用 `useEffect` 实现，实际代码做了组件 unmount 保护：
+
+```tsx
+//  refreshDeps 变化，重新执行所有请求
+useUpdateEffect(() => {
+  if (!manual) {
+    /* 全部重新执行 */
+    Object.values(fetchesRef.current).forEach((f) => {
+      f.refresh();
+    });
+  }
+}, [...refreshDeps]);
+```
+
+非手动条件下，依赖变化所有已存在的 `fetche` 执行 `refresh` 即可。
+
+分页和加载更多就不解析了，原理是在 `useAsync` 这个基础请求 Hook 基础上再包一层 Hook，拓展取数参数与返回结果。
+
+## 4 总结
+
+目前还有 错误重试、请求超时管理、Suspense 没有支持，看完这篇精读后，相信你已经可以提 PR 了。
+
+> 讨论地址是：[精读《@umijs/use-request》源码 · Issue #249 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/249)
+
+**如果你想参与讨论，请 [点击这里](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)）

152. 精读《recoil》.md

@@ -0,0 +1,284 @@
+## 1 引言
+
+[Recoil](https://recoiljs.org/) 是 Facebook 公司出的数据流管理方案，有一定思考的价值。
+
+Recoil 是基于 Immutable 的数据流管理方案，这也是它值得被拿出来看的最重要原因，如果要用 Mutable 方式管理 React 数据流，直接看 [mobx-react](https://github.com/mobxjs/mobx-react) 就足够了。
+
+然而 React Immutable 特性带来的可预测性非常利于调试和维护：
+
+1. 断点调试时变量的值与当前执行位置无关，已创建过的值不会突然 Mutable 突变，非常可预测。
+2. 在 React 框架下组件更新机制单一，只有引用变化才触发重渲染，而没有 Mutable 模式下 ForceUpdate 的心智负担。
+
+当然 Immutable 模式下存在一定编码心智负担，所以各有优劣。
+
+> 但 Recoil 和 Redux 一样，并不代表 React 官方数据流管理方案，因此不用带着官方光环去看它。
+
+## 2 简介
+
+Recoil 解决 React 全局数据流管理的问题，采用分散管理原子状态的设计模式，支持派生数据与异步查询，在基本功能上可以覆盖 Redux。
+
+### 状态作用域
+
+和 Redux 一样，全局数据流管理需要存在作用域 `RecoilRoot`：
+
+```jsx
+import React from "react";
+import { RecoilRoot } from "recoil";
+
+function App() {
+  return (
+    <RecoilRoot>
+      <CharacterCounter />
+    </RecoilRoot>
+  );
+}
+```
+
+`RecoilRoot` 在被嵌套时，最内层的 `RecoilRoot` 会覆盖外层的配置及状态值。
+
+### 定义数据
+
+与 Redux 集中定义 `initState` 不同，Recoil 采用 `atom` 以分散方式定义数据：
+
+```jsx
+const textState = atom({
+  key: "textState",
+  default: "",
+});
+```
+
+其中 `key` 必须在 `RecoilRoot` 作用域内唯一，也可以认为是 state 树打平时 key 必须唯一的要求。
+
+`default` 定义默认值，既然数据定义分散了，默认值定义也是分散的。
+
+### 读取数据
+
+与 Redux 的 Connect 或 useSelector 类似，Recoil 采用 Hooks 方式读取数据：
+
+```jsx
+import { useRecoilValue } from "recoil";
+
+function App() {
+  const text = useRecoilValue(textState);
+}
+```
+
+`useRecoilValue` 与 `useSetRecoilState` 都可以获取数据，区别是 `useRecoilState` 还可以获取写数据的函数：
+
+```jsx
+import { useRecoilState } from "recoil";
+
+function App() {
+  const [text, setText] = useRecoilValue(useRecoilState);
+}
+```
+
+### 修改数据
+
+与 Redux 集中定义纯函数 `reducer` 修改数据不同，Recoil 采用 Hooks 方式写数据。
+
+除了上面提到的 `useRecoilState` 之外，还有一个 `useSetRecoilState` 可以仅获取写函数：
+
+```jsx
+import { useSetRecoilState } from "recoil";
+
+function App() {
+  const setText = useSetRecoilValue(useRecoilState);
+}
+```
+
+`useSetRecoilState` 与 `useRecoilState`、`useRecoilValue` 的不同之处在于，数据流的变化不会导致组件 Rerender，因为 `useSetRecoilState` 仅写不读。
+
+这也导致 Recoil API 偏多被诟病，这也是 Immutable 模式下存的编码心智负担，虽然很好理解，但也只有 `useSelector` 或 Recoil 这样拆分 API 的方式可以解决。
+
+> 另外还提供了 `useResetRecoilState` 重置到默认值并读取。
+
+### 仅读不订阅
+
+与 ReactRedux 的 `useStore` 类似，Recoil 提供了 `useRecoilCallback` 用于只读不订阅场景：
+
+```jsx
+import { atom, useRecoilCallback } from "recoil";
+
+const itemsInCart = atom({
+  key: "itemsInCart",
+  default: 0,
+});
+
+function CartInfoDebug() {
+  const logCartItems = useRecoilCallback(async ({ getPromise }) => {
+    const numItemsInCart = await getPromise(itemsInCart);
+
+    console.log("Items in cart: ", numItemsInCart);
+  });
+}
+```
+
+`useRecoilCallback` 通过回调方式定义要读取的数据，这个数据变化也不会导致当前组件重渲染。
+
+### 派生值
+
+与 Mobx `computed` 类似，recoil 提供了 `selector` 支持派生值，这是比较有特色的功能:
+
+```jsx
+import { atom, selector, useRecoilState } from "recoil";
+
+const tempFahrenheit = atom({
+  key: "tempFahrenheit",
+  default: 32,
+});
+
+const tempCelcius = selector({
+  key: "tempCelcius",
+  get: ({ get }) => ((get(tempFahrenheit) - 32) * 5) / 9,
+  set: ({ set }, newValue) => set(tempFahrenheit, (newValue * 9) / 5 + 32),
+});
+
+function TempCelcius() {
+  const [tempF, setTempF] = useRecoilState(tempFahrenheit);
+  const [tempC, setTempC] = useRecoilState(tempCelcius);
+}
+```
+
+`selector` 提供了 `get`、`set` 分别定义如何赋值与取值，所以其与 `atom` 定义一样可以被 `useRecoilState` 等三套 API 操作，这里甚至不用看源码就能猜到，`atom` 应该是基于 `selector` 的一个特定封装。
+
+### 异步读取
+
+基于 `selector` 可以实现异步数据读取，只要将 `get` 函数写成异步即可：
+
+```jsx
+const currentUserNameQuery = selector({
+  key: "CurrentUserName",
+  get: async ({ get }) => {
+    const response = await myDBQuery({
+      userID: get(currentUserIDState),
+    });
+    if (response.error) {
+      throw response.error;
+    }
+    return response.name;
+  },
+});
+
+function CurrentUserInfo() {
+  const userName = useRecoilValue(currentUserNameQuery);
+  return <div>{userName}</div>;
+}
+
+function MyApp() {
+  return (
+    <RecoilRoot>
+      <ErrorBoundary>
+        <React.Suspense fallback={<div>Loading...</div>}>
+          <CurrentUserInfo />
+        </React.Suspense>
+      </ErrorBoundary>
+    </RecoilRoot>
+  );
+}
+```
+
+1. 异步状态可以被 `Suspense` 捕获。
+2. 异步过程报错可以被 `ErrorBoundary` 捕获。
+
+如果不想用 `Suspense` 阻塞异步，可以换 `useRecoilValueLoadable` 这个 API 在当前组件内管理异步状态：
+
+```jsx
+function UserInfo({ userID }) {
+  const userNameLoadable = useRecoilValueLoadable(userNameQuery(userID));
+  switch (userNameLoadable.state) {
+    case "hasValue":
+      return <div>{userNameLoadable.contents}</div>;
+    case "loading":
+      return <div>Loading...</div>;
+    case "hasError":
+      throw userNameLoadable.contents;
+  }
+}
+```
+
+### 依赖外部变量
+
+与 `reselect` 一样，Recoil 也面临状态管理不纯粹的问题，即数据读取依赖外部变量，这样会面临较为复杂的缓存计算问题，甚至还出现了 `re-reselect` 库。
+
+因为 Recoil 本身是原子化状态管理的，所以这个问题相对好解决：
+
+```jsx
+const myMultipliedState = selectorFamily({
+  key: "MyMultipliedNumber",
+  get: (multiplier) => ({ get }) => {
+    return get(myNumberState) * multiplier;
+  },
+});
+
+function MyComponent() {
+  const number = useRecoilValue(myMultipliedState(100));
+}
+```
+
+当外部传参 `multiplier` 与依赖值 `myNumberState` 不变时，就不会重新计算。
+
+Recoil 在 `get` 与 `set` 函数定义 `Atom` 时，内部会自动生成依赖，这个部分做的比较好。
+
+> 依赖外部变量使用了 Family 后缀，比如 selector -> selectorFamily；atom -> atomFamily。
+
+## 3 精读
+
+Recoil 以原子化方式对状态进行分离管理，确实比较契合 Immutable 的编程模式，尤其在缓存处理时非常亮眼，但编程领域中，优势换一个角度看往往就变成了劣势，我们还是要客观评价一下 Recoil。
+
+### Immutable 心智负担
+
+API 较多，在简介中也提到了，这可能是 Immutable 自带的硬伤，而不仅仅是 Recoil 的问题。
+
+Immutable 模式中，对数据流只有读与写两种诉求，**而申明式编程讲究的是数据变化后 UI 自动 Rerender，那么对数据的读自然而然就被赋予了订阅其变化后触发 Rerender 的期待**，但是写与读不同，为什么 `setState` 强调用回调方式写数据？因为回调方式的写不依赖读，有写诉求的组件没必要与读挂上钩，也就是写组件的地方不一定要订阅对应数据。
+
+Recoil 提供了 `useRecoilState` 作为读写双重 API，仅在既读又写的场景使用，而 `useRecoilValue` 仅仅是为了简化 API，替换为 `useRecoilState` 不会有性能损失，而 `useSetRecoilValue` 则必须认真对待，在仅写不读的场景必须严格使用这个 API。
+
+那 `useState` 为什么默认是读写的？因为 `useState` 是单组件状态管理的场景，一个定义在组件内的状态不可能只写不读，但 Recoil 是全局状态解决方案，读写分离的场景下，对于只写的组件很有必要脱离对数据的订阅实现性能最大化。
+
+### 条件访问数据
+
+这也是 Hooks 的通病，由于 Hooks 不能写在条件语句中，因此要利用 Hooks 获取一个带有条件判断的数据时，必须回到 `selector` 模式：
+
+```jsx
+const articleOrReply = selectorFamily({
+  key: "articleOrReply",
+  get: ({ isArticle, id }) => ({ get }) => {
+    if (isArticle) {
+      return get(article(id));
+    }
+
+    return get(reply(id));
+  },
+});
+```
+
+这样的代码其实挺冗余的，其实在 Mutable 模式下可以 `isArticle ? store.articles[id] : store.replies[id]` 就能搞定的模式，必须单独抽一个 `selector` 出来写上头十行代码，显得非常繁琐。
+
+### Recoil 的本质
+
+从 Hooks API 到派生值，这两个核心特点恰巧是对 Context 与 useMemo 的封装。
+
+首先基于 Hooks 的 `useContext` 已经足够轻量易用，可以认为 `atom` 与 `useRecoilState`、`useRecoilValue`、`useSetRecoilValue` 分别对应封装后的 `createContext` 与 `useContext`。
+
+再看 `useMemo`，大部分情况我们可以利用 `useMemo` 造出派生值，这对应了 Recoil 的 `selector` 和 `selectorFamily`。
+
+所以 Recoil 本质更像一个模式化封装库，针对数据驱动易于数据原子化管理的场景，并做到高性能。
+
+## 3 总结
+
+无论你用不用 Recoil，我们都可以从 Recoil 这儿学到 React 状态管理的基本功：
+
+1. 对象的读与写分离，做到最优按需渲染。
+2. 派生的值必须严格缓存，并在命中缓存时引用保证严格相等。
+3. 原子存储的数据相互无关联，所有关联的数据都使用派生值方式推导。
+
+> 讨论地址是：[精读《recoil》· Issue #251 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/251)
+
+**如果你想参与讨论，请 [点击这里](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)）