精讀《Suspense 改變開發方式》

1 引言

不少人都用過 React Suspense，但若是你認爲它只是配合 React.lazy 實現異步加載的蒙層，就理解的太淺了。實際上，React Suspense 改變了開發規則，要理解這一點，須要做出思想上的改變。

咱們結合 Why React Suspense Will Be a Game Changer 這篇文章，帶你從新認識 React Suspense。

2 概述

異步加載是前端開發的重要環節，也是一直以來樣板代碼最嚴重的場景之一，原文經過三種取數方案的對比，逐漸找到一種最佳的異步取數方式。

在講解這三種取數方案以前，首先經過下面這張圖說明了 Suspense 的功能：

從上圖能夠看出，子元素在異步取數時會阻塞父組件渲染，並一直冒泡到最外層第一個 Suspense，此時 Suspense 不會渲染子組件，而是渲染 fallback，當全部子組件異步阻塞取消後纔會正常渲染。

下面介紹文中給出的三種取數方式，首先是最原始的本地狀態管理方案。

本地異步狀態管理，直白但不利於維護

在 Suspense 方案出來以前，咱們通常都在代碼中利用本地狀態管理異步數據。

即使代碼作了必定抽象，那也只是把邏輯從一個文件移到了另外一個問題，可維護性與可拓展性都沒有本質的改變，所以基本能夠用下面的結構說明：

class DynamicData extends Component {
  state = {
    loading: true,
    error: null,
    data: null
  };

  componentDidMount() {
    fetchData(this.props.id)
      .then(data => {
        this.setState({
          loading: false,
          data
        });
      })
      .catch(error => {
        this.setState({
          loading: false,
          error: error.message
        });
      });
  }

  componentDidUpdate(prevProps) {
    if (this.props.id !== prevProps.id) {
      this.setState({ loading: true }, () => {
        fetchData(this.props.id)
          .then(data => {
            this.setState({
              loading: false,
              data
            });
          })
          .catch(error => {
            this.setState({
              loading: false,
              error: error.message
            });
          });
      });
    }
  }

  render() {
    const { loading, error, data } = this.state;
    return loading ? (
      <p>Loading...</p>
    ) : error ? (
      <p>Error: {error}</p>
    ) : (
      <p>Data loaded ?</p>
    );
  }
}
複製代碼

如上所述，首先申明本地狀態管理至少三種數據：異步狀態、異步結果與異步錯誤，其次在不一樣的生命週期中處理初始化發請求與從新發請求的問題，最後在渲染函數中根據不一樣的狀態渲染不一樣的結果，因此實際上咱們寫了三個渲染組件。

從下面幾個角度對上述代碼進行評價：

• 冗餘的三種狀態 - 糟糕的開發體驗
  • 很明顯，存儲了三套數據，渲染三種結果，不利於開發維護。
• 冗餘的樣板代碼 - 糟糕的開發體驗
  • 爲了管理異步狀態，上述代碼很是冗長，顯然這個問題是存在的。
• 數據與狀態封閉性 - 糟糕的用戶體驗 + 開發體驗
  • 全部數據與狀態管理都存儲在每個這種組件中，將取數狀態與組件綁定的結果就是，咱們只能忍受組件獨立運行的 Loading 邏輯，而沒法對他們進行統一管理。
• 從新取數 - 糟糕的開發體驗
  • 須要在另外一個生命週期中申明從新取數，很明顯是個麻煩的行爲。
• 一閃而過的短暫 Loading - 糟糕的用戶體驗
  • 若是用戶網速足夠快，則 Loading 時間會很是短，此時一閃而過的 Loading 反而比沒有 Loading 更煩人，咱們應該在用戶感知到卡的時候再出現 Loading 狀態。

Context 管理狀態，有進步但問題依然不少

若是利用 Context 作狀態共享，咱們將取數的數據管理與邏輯代碼寫在父組件，子組件專心用於展現，效果會好一些，代碼以下：

const DataContext = React.createContext();

class DataContextProvider extends Component {
  // We want to be able to store multiple sources in the provider,
  // so we store an object with unique keys for each data set +
  // loading state
  state = {
    data: {},
    fetch: this.fetch.bind(this)
  };

  fetch(key) {
    if (this.state[key] && (this.state[key].data || this.state[key].loading)) {
      // Data is either already loaded or loading, so no need to fetch!
      return;
    }

    this.setState(
      {
        [key]: {
          loading: true,
          error: null,
          data: null
        }
      },
      () => {
        fetchData(key)
          .then(data => {
            this.setState({
              [key]: {
                loading: false,
                data
              }
            });
          })
          .catch(e => {
            this.setState({
              [key]: {
                loading: false,
                error: e.message
              }
            });
          });
      }
    );
  }

  render() {
    return <DataContext.Provider value={this.state} {...this.props} />; } } class DynamicData extends Component { static contextType = DataContext; componentDidMount() { this.context.fetch(this.props.id); } componentDidUpdate(prevProps) { if (this.props.id !== prevProps.id) { this.context.fetch(this.props.id); } } render() { const { id } = this.props; const { data } = this.context; const idData = data[id]; return idData.loading ? ( <p>Loading...</p> ) : idData.error ? ( <p>Error: {idData.error}</p> ) : ( <p>Data loaded ?</p> ); } } 複製代碼

DataContextProvider 組件承擔了狀態管理與異步邏輯工做，而 DynamicData 組件只須要從 Context 獲取異步狀態渲染便可，這樣來看至少解決了一部分問題，咱們仍是從以前的角度進行評價：

• 冗餘的三種狀態 - 糟糕的開發體驗
  • 問題依然存在，只不過代碼的位置轉移了一部分到父組件。
• 冗餘的樣板代碼 - 糟糕的開發體驗
  • 將展現與邏輯分離，成功下降了樣板代碼數量，至少當一個異步數據複用於多個組件時，不須要寫多份樣板代碼了。
• 數據與狀態封閉性 - 糟糕的用戶體驗 + 開發體驗
  • 這個問題獲得必定程度解決，可是引入了新問題，即這個子組件僅在特定環境下能夠正常運行。但在一個良好的設計下，組件運行不該該依賴於它所處的位置。
• 從新取數 - 糟糕的開發體驗
  • 問題依然存在。
• 一閃而過的短暫 Loading - 糟糕的用戶體驗
  • 問題依然存在。

Suspense 管理狀態，最棒的方案

利用 Suspense 進行異步處理，代碼處理大概是這樣的：

import createResource from "./magical-cache-provider";
const dataResource = createResource(id => fetchData(id));

class DynamicData extends Component {
  render() {
    const data = dataResource.read(this.props.id);
    return <p>Data loaded ?</p>;
  }
}

class App extends Component {
  render() {
    return (
      <Suspense fallback={<p>Loading...</p>}> <DeepNesting> <DynamicData /> </DeepNesting> </Suspense>
    );
  }
}
複製代碼

在原文寫做的時候，Suspense 僅能對 React.lazy 生效，但如今已經能夠對任何異步狀態生效了，只要符合 Pending 中 throw promise 的規則。

咱們再審視一下上面的代碼，能夠發現代碼量減小了不少，其中和轉換成 Function Component 的寫法也有關係。

最後仍是從以下幾個角度進行評價：

• 冗餘的三種狀態 - 糟糕的開發體驗 - ⭐️
  • 能夠看到，組件只要處理成功獲得數據的狀態便可，三種狀態合併成了一種狀態。
• 冗餘的樣板代碼 - 糟糕的開發體驗 - ⭐️
  • 展現與邏輯徹底分離，展現只要拿到數據展現 UI 便可。
• 數據與狀態封閉性 - 糟糕的用戶體驗 + 開發體驗 - ⭐️
  • 這個問題獲得了完美的解決，具體看下面詳細介紹。
• 從新取數 - 糟糕的開發體驗 - ⭐️
  • 不須要關心什麼時候須要從新取數，當數據變化時會自動執行。
• 一閃而過的短暫 Loading - 糟糕的用戶體驗
  • 問題依然存在。

爲了進一步說明 Suspense 的魔力，筆者特地把這段代碼單獨拿出來講明：

class App extends Component {
  render() {
    return (
      <Suspense fallback={<p>Loading...</p>}> <DeepNesting> <MaybeSomeAsycComponent /> <Suspense fallback={<p>Loading content...</p>}> <ThereMightBeSeveralAsyncComponentsHere /> </Suspense> <Suspense fallback={<p>Loading footer...</p>}> <DeeplyNestedFooterTree /> </Suspense> </DeepNesting> </Suspense>
    );
  }
}
複製代碼

上面代碼代表了邏輯與展現的完美分離。

從代碼結構上來看，咱們能夠在任何須要異步取數的組件父級添加 Suspense 達到 Loading 的效果，也就是說，若是隻在最外層加一個 Suspense，那麼整個應用全部 Loading 都結束後纔會渲染，然而咱們也能爲所欲爲的在任何層級繼續添加 Suspense，那麼對應做用域內的 Loading 就會首先執行完畢，並由當前的 Suspense 控制。

這意味着咱們能夠自由決定 Loading 狀態的範圍組合。 試想當 Loading 狀態交由組件控制的方案一與方案二，是不可能作到合併 Loading 時機的，而 Suspense 方案作到了將 Loading 狀態與 UI 分離，咱們能夠經過添加 Suspense 自由控制 Loading 的粒度。

3 精讀

Suspense 對全部子組件異步均可以做用，所以不管是 React.lazy 仍是異步取數，均可以經過 Suspense 進行 Pending。

異步時機被 Suspense pending 須要遵循必定規則，這個規則在以前的 精讀《Hooks 取數 - swr 源碼》 有介紹過，即 Suspense 要求代碼 suspended，即拋出一個能夠被捕獲的 Promise 異常，在這個 Promise 結束後再渲染組件，所以取數函數須要在 Pending 狀態時拋出一個 Promise，使其能夠被 Suspense 捕獲到。

另外，關於文中提到的 fallback 最小出現時間的保護間隔，目前仍是一個 Open Issue，也許有一天 React 官方會提供支持。

不過即使官方不支持，咱們也有方式實現，即讓這個邏輯由 fallback 組件實現：

<Suspense fallback={MyFallback} />;

const MyFallback = () => {
  // 計時器，200 ms 之內 return null，200 ms 後 return <Spin />
};
複製代碼

4 總結

之因此說 Suspense 開發方式改變了開發規則，是由於它作到了將異步的狀態管理與 UI 組件分離，全部 UI 組件都無需關心 Pending 狀態，而是看成同步去執行，這自己就是一個巨大的改變。

另外因爲狀態的分離，咱們能夠利用純 UI 組件拼裝任意粒度的 Pending 行爲，以整個 App 做爲一個大的 Suspense 做爲兜底，這樣 UI 完全與異步解耦，哪裏 Loading，什麼範圍內 Loading，徹底由 Suspense 組合方式決定，這樣的代碼顯然具有了更強的可拓展性。

討論地址是：精讀《Suspense 改變開發方式》 · Issue #238 · dt-fe/weekly

若是你想參與討論，請 點擊這裏，每週都有新的主題，週末或週一發佈。前端精讀 - 幫你篩選靠譜的內容。

關注 前端精讀微信公衆號

版權聲明：自由轉載-非商用-非衍生-保持署名（創意共享 3.0 許可證）