精讀《React 八種條件渲染》

Rainie 發布于2019-08-22 18:07 / 2248人閱讀

摘要：引言本期精讀的文章是介紹了八種條件渲染方式。此時小王接到了需求，終于維護了一個大項目。更多討論討論地址是精讀八種條件渲染如果你想參與討論，請點擊這里，每周都有新的主題，周末或周一發布。

1 引言

本期精讀的文章是：8 React conditional rendering methods

介紹了八種 React 條件渲染方式。

模版條件渲染非常常見，遇到的時候往往會隨機選擇一種方式使用，那么怎么寫會有較好的維護性呢？先一起了解下有哪八種條件渲染方式吧！

2 概述 IF/ELSE

既然 JSX 支持 js 與 html 混寫，那么交替使用就能解決條件渲染的問題：

function render() {
  if (renderComponent1) {
    return ;
  } else {
    return ;
  }
}

return null

如果不想渲染空元素，最好使用 null 代替空的 div：

function render() {
  if (renderComponent1) {
    return ;
  } else {
    return null;
  }
}

這樣對 React 渲染效率有提升。

組件變量

將組件賦值到變量，就可以在 return 前任意修改它了。

function render() {
  let component = null;

  if (renderComponent1) {
    component = ;
  }

  return component;
}

三元運算符

三元運算符的語法如下：

condition ? expr_if_true : expr_if_false

用在 JSX 上也很方便：

function render() {
  return renderComponent1 ?  : null;
}

但三元運算符產生嵌套時，理解成本會變得很高。

這個是最常用了，因為代碼量最少。

function render() {
  return renderComponent1 && ;
}

IIFE

IIFE 含義是立即執行函數，也就是如下代碼：

(function myFunction(/* arguments */) {
  // ...
})(/* arguments */);

當深陷 JSX 代碼中，又想寫一大塊邏輯時，除了回到上方，還可以使用 IIFE：

function render() {
  return (
    
      {(() => {
        if (renderComponent1) {
          return ;
        } else {
          return ;
        }
      })()}
    
  );
}

子組件

這是 IIFE 的變種，也就是把這段立即執行函數替換成一個普通函數：

function render() {
  return (
    
      
    
  );
}

function SubRender() {
  if (renderComponent1) {
    return ;
  } else {
    return ;
  }
}

IF 組件

做一個條件渲染組件 IF 代替 js 函數的 if：

Hi!

這個組件實現也很簡單

const If = props => {
  const condition = props.condition || false;
  const positive = props.then || null;
  const negative = props.else || null;

  return condition ? positive : negative;
};

高階組件

高階組件，就是返回一個新組件的函數，并且接收一個組件作為參數。

那么我們就能在高階組件里寫條件語句，返回不同的組件即可：

function higherOrderComponent(Component) {
  return function EnhancedComponent(props) {
    if (condition) {
      return ;
    }

    return ;
  };
}

3 精讀

這么多方法都能實現條件渲染，那么重點在于可讀性與可維護性。

比如通過調用函數實現組件渲染：

{renderButton()}

看上去還是比較冗余，如果使用 renderButton getter 定義，我們就可以這么寫它：

{button}

其實我們想要的就是 button，而不是 renderButton。那么還可以進一步，干脆封裝成 JSX 組件：

是否要付出這些努力，取決于應用的復雜度。如果應用復雜度非常高，那你應當盡量使用最后一種封裝，讓每個文件的邏輯盡量獨立、簡單。

如果應用復雜度比較低，那么注意不要過度封裝，以免把自己繞進去。

所以看來這又是一個沒有固定答案的問題，選擇何種方式封裝，取決于應用復雜度。

應用復雜度

對任何代碼封裝，都會增加這段 連接邏輯 的復雜度。

假定無論如何代碼的復雜度都是恒定不變的，下面這段代碼，連接復雜度為 0，而對于 render 函數而言，邏輯復雜度是 100：

function render() {
  if (renderComponent) {
    return isOk ?  : ;
  } else {
    return ;
  }
}

下面這段代碼拆成了兩個函數，邏輯復雜度對 render SubComponent 來說都是 50，但連接復雜度是 50：

function render() {
  if (renderComponent) {
    return ;
  } else {
    return ;
  }
}

function SubComponent() {
  return isOk ?  : 
}

可以看到，我們通過函數拆分，降低了每個函數的邏輯復雜度，但卻提高了連接復雜度。

下面來做一個比較，我們假設一個正常的程序員，可以一次性輕松記憶 10 個函數。如果再多，函數之間的調用關系就會讓人摸不著頭腦。

應用較小時

在應用代碼量比較小時，假設一共有 10 個函數，如果做了邏輯抽象，拆分出了 10 個子函數，那么總邏輯復雜度不變，函數變成了 20 個。

此時小王要修改此項目，他需要找到關鍵代碼的位置。

如果沒有做邏輯抽象，小王一下子就記住了 10 個函數，并且很快完成了需求。

如果應用做了邏輯抽象，他需要理解的邏輯復雜度是不變的，但是要讀的函數變成了 20 個。小王需要像偵探一樣在線索中不斷跳轉，他還是只找了 10 個關鍵函數，但一共也就 20 個函數，邏輯并不復雜，這值得嗎？

小王心里可能會嘀咕：簡單的邏輯瞎抽象，害我文件找了半天！

應用較大時

此時應用代碼量比較大，假設一共有 500 個函數，我們不考慮抽象后帶來的復用好處，假設都無法復用，那么做了邏輯抽象后，那么總邏輯復雜度不變，函數變成了 1000 個。

此時小王接到了需求，終于維護了一個大項目。

小王知道這個項目很復雜，從一開始就沒覺得能理解項目全貌，所以把自己當作一名偵探，準備一步步探索。

現在有兩種選擇，一種是在未做邏輯抽象時探索，一種是在做過邏輯抽象后探索。

如果沒做邏輯抽象，小王需要面對 500 個這種函數：

function render() {
  if (renderComponent) {
    return isOk ?  : ;
  } else {
    return isReady ?  : ;
  }
}

如果做了邏輯抽象，小王需要面對 1000 個這種函數：

function render() {
  if (renderComponent) {
    return ;
  } else {
    return ;
  }
}

在項目龐大后，總函數數量并不會影響對線索的查找，而總線索深度也幾乎總是固定的，一般在 5 層左右。

小王理解 5 個或 10 個函數成本都差不多，但沒有做邏輯抽象時，這 5 個函數各自參雜了其他邏輯，反而影響對函數的理解。

這時做邏輯抽象是合適的。

4 總結

所以總的來說，筆者更傾向使用子函數、子組件、IF 組件、高階組件做條件渲染，因為這四種方式都能提高程序的抽象能力。

往往抽象后的代碼會更具有復用性，單個函數邏輯更清晰，在切面編程時更利于理解。

當項目很簡單時，整個項目的理解成本都很低，抽象帶來的復雜度反而讓項目變成了需要切面編程的時候，就得不償失了。

總結一下：

當項目很簡單，或者條件渲染的邏輯確認無法復用時，推薦在代碼中用 && 或者三元運算符、IIFE 等直接實現條件渲染。

當項目很復雜時，盡量都使用子函數、子組件、IF 組件、高階組件等方式做更有抽象度的條件渲染。

在做邏輯抽象時，考慮下項目的復雜度，避免因為抽象帶來的成本增加，讓本可以整體理解的項目變得支離破碎。

5 更多討論

討論地址是：精讀《React 八種條件渲染》 · Issue #90 · dt-fe/weekly

如果你想參與討論，請點擊這里，每周都有新的主題，周末或周一發布。

云服務器 GPU云服務器條件渲染 vue條件渲染 react _React

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/95512.html

精讀《Vue3.0 Function API》

摘要：拿到的都是而不是原始值，且這個值會動態變化。精讀對于的與，筆者做一些對比。因此采取了作為優化方案只有當第二個依賴參數變化時才返回新引用。不需要使用等進行性能優化，所有性能優化都是自動的。前端精讀幫你篩選靠譜的內容。 1. 引言 Vue 3.0 的發布引起了軒然大波，讓我們解讀下它的 function api RFC 詳細了解一下 Vue 團隊是怎么想的吧！首先官方回答了幾個最受關注的...

voyagelab 2019-08-23 18:24 評論0 收藏0
精讀《React16 新特性》

摘要：引言于發布版本，時至今日已更新到，且引入了大量的令人振奮的新特性，本文章將帶領大家根據更新的時間脈絡了解的新特性。其作用是根據傳遞的來更新。新增等指針事件。 1 引言于 2017.09.26 Facebook 發布 React v16.0 版本，時至今日已更新到 React v16.6，且引入了大量的令人振奮的新特性，本文章將帶領大家根據 React 更新的時間脈絡了解 React1...

Nosee 2019-08-23 13:58 評論0 收藏0
精讀《react-easy-state 源碼》

摘要：會自動觸發函數內回調函數的執行。因此利用并將依賴置為使代碼在所有渲染周期內，只在初始化執行一次。同時代碼里還對等公共方法進行了包裝，讓這些回調函數中自帶效果。前端精讀幫你篩選靠譜的內容。 1. 引言 react-easy-state 是個比較有趣的庫，利用 Proxy 創建了一個非常易用的全局數據流管理方式。 import React from react; import { stor...

curlyCheng 2019-08-23 16:48 評論0 收藏0
精讀《Scheduling in React》

摘要：調度系統，支持不同渲染優先級，對進行調度。調度帶來的限制調度系統也存在兩個問題。調度系統能力有限，只能在瀏覽器提供的能力范圍內進行調度，而無法影響比如的渲染回收周期。精讀關于調度系統的剖析，可以讀深入剖析這篇文章，感謝我們團隊的淡蒼提供。 1. 引言這次介紹的文章是 scheduling-in-react，簡單來說就是 React 的調度系統，為了得到更順滑的用戶體驗。畢竟前端做到...

LeexMuller 2019-08-23 16:56 評論0 收藏0
精讀《React Hooks》

摘要：更容易將組件的與狀態分離。也就是只提供狀態處理方法，不會持久化狀態。大體思路是利用共享一份數據，作為的數據源。精讀帶來的約定函數必須以命名開頭，因為這樣才方便做檢查，防止用判斷包裹語句。前端精讀幫你篩選靠譜的內容。 1 引言 React Hooks 是 React 16.7.0-alpha 版本推出的新特性，想嘗試的同學安裝此版本即可。 React Hooks 要解決的問題是狀態共享，...

kohoh_ 2019-08-23 13:03 評論0 收藏0