摘要：引言本期精讀的文章是介紹了八種條件渲染方式。此時(shí)小王接到了需求，終于維護(hù)了一個(gè)大項(xiàng)目。更多討論討論地址是精讀八種條件渲染如果你想?yún)⑴c討論，請(qǐng)點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。

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

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

模版條件渲染非常常見(jiàn)，遇到的時(shí)候往往會(huì)隨機(jī)選擇一種方式使用，那么怎么寫(xiě)會(huì)有較好的維護(hù)性呢？先一起了解下有哪八種條件渲染方式吧！

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

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

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

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

這樣對(duì) React 渲染效率有提升。

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

function render() {
  let component = null;

  if (renderComponent1) {
    component = ;
  }

  return component;
}

三元運(yùn)算符的語(yǔ)法如下：

condition ? expr_if_true : expr_if_false

用在 JSX 上也很方便：

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

但三元運(yùn)算符產(chǎn)生嵌套時(shí)，理解成本會(huì)變得很高。

這個(gè)是最常用了，因?yàn)榇a量最少。

function render() {
  return renderComponent1 && ;
}

IIFE 含義是立即執(zhí)行函數(shù)，也就是如下代碼：

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

當(dāng)深陷 JSX 代碼中，又想寫(xiě)一大塊邏輯時(shí)，除了回到上方，還可以使用 IIFE：

function render() {
  return (
    

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

這是 IIFE 的變種，也就是把這段立即執(zhí)行函數(shù)替換成一個(gè)普通函數(shù)：

function render() {
  return (
    

      
    
  );
}

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

做一個(gè)條件渲染組件 IF 代替 js 函數(shù)的 if：

  Hi!

這個(gè)組件實(shí)現(xiàn)也很簡(jiǎn)單

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

  return condition ? positive : negative;
};

高階組件，就是返回一個(gè)新組件的函數(shù)，并且接收一個(gè)組件作為參數(shù)。

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

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

    return ;
  };
}

這么多方法都能實(shí)現(xiàn)條件渲染，那么重點(diǎn)在于可讀性與可維護(hù)性。

比如通過(guò)調(diào)用函數(shù)實(shí)現(xiàn)組件渲染：

{renderButton()}

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

{button}

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

是否要付出這些努力，取決于應(yīng)用的復(fù)雜度。如果應(yīng)用復(fù)雜度非常高，那你應(yīng)當(dāng)盡量使用最后一種封裝，讓每個(gè)文件的邏輯盡量獨(dú)立、簡(jiǎn)單。

如果應(yīng)用復(fù)雜度比較低，那么注意不要過(guò)度封裝，以免把自己繞進(jìn)去。

所以看來(lái)這又是一個(gè)沒(méi)有固定答案的問(wèn)題，選擇何種方式封裝，取決于應(yīng)用復(fù)雜度。

對(duì)任何代碼封裝，都會(huì)增加這段 連接邏輯 的復(fù)雜度。

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

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

下面這段代碼拆成了兩個(gè)函數(shù)，邏輯復(fù)雜度對(duì) render SubComponent 來(lái)說(shuō)都是 50，但連接復(fù)雜度是 50：

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

function SubComponent() {
  return isOk ?  : 
}

可以看到，我們通過(guò)函數(shù)拆分，降低了每個(gè)函數(shù)的邏輯復(fù)雜度，但卻提高了連接復(fù)雜度。

下面來(lái)做一個(gè)比較，我們假設(shè)一個(gè)正常的程序員，可以一次性輕松記憶 10 個(gè)函數(shù)。如果再多，函數(shù)之間的調(diào)用關(guān)系就會(huì)讓人摸不著頭腦。

在應(yīng)用代碼量比較小時(shí)，假設(shè)一共有 10 個(gè)函數(shù)，如果做了邏輯抽象，拆分出了 10 個(gè)子函數(shù)，那么總邏輯復(fù)雜度不變，函數(shù)變成了 20 個(gè)。

此時(shí)小王要修改此項(xiàng)目，他需要找到關(guān)鍵代碼的位置。

如果沒(méi)有做邏輯抽象，小王一下子就記住了 10 個(gè)函數(shù)，并且很快完成了需求。

如果應(yīng)用做了邏輯抽象，他需要理解的邏輯復(fù)雜度是不變的，但是要讀的函數(shù)變成了 20 個(gè)。小王需要像偵探一樣在線(xiàn)索中不斷跳轉(zhuǎn)，他還是只找了 10 個(gè)關(guān)鍵函數(shù)，但一共也就 20 個(gè)函數(shù)，邏輯并不復(fù)雜，這值得嗎？

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

此時(shí)應(yīng)用代碼量比較大，假設(shè)一共有 500 個(gè)函數(shù)，我們不考慮抽象后帶來(lái)的復(fù)用好處，假設(shè)都無(wú)法復(fù)用，那么做了邏輯抽象后，那么總邏輯復(fù)雜度不變，函數(shù)變成了 1000 個(gè)。

此時(shí)小王接到了需求，終于維護(hù)了一個(gè)大項(xiàng)目。

小王知道這個(gè)項(xiàng)目很復(fù)雜，從一開(kāi)始就沒(méi)覺(jué)得能理解項(xiàng)目全貌，所以把自己當(dāng)作一名偵探，準(zhǔn)備一步步探索。

現(xiàn)在有兩種選擇，一種是在未做邏輯抽象時(shí)探索，一種是在做過(guò)邏輯抽象后探索。

如果沒(méi)做邏輯抽象，小王需要面對(duì) 500 個(gè)這種函數(shù)：

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

如果做了邏輯抽象，小王需要面對(duì) 1000 個(gè)這種函數(shù)：

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

在項(xiàng)目龐大后，總函數(shù)數(shù)量并不會(huì)影響對(duì)線(xiàn)索的查找，而總線(xiàn)索深度也幾乎總是固定的，一般在 5 層左右。

小王理解 5 個(gè)或 10 個(gè)函數(shù)成本都差不多，但沒(méi)有做邏輯抽象時(shí)，這 5 個(gè)函數(shù)各自參雜了其他邏輯，反而影響對(duì)函數(shù)的理解。

這時(shí)做邏輯抽象是合適的。

所以總的來(lái)說(shuō)，筆者更傾向使用子函數(shù)、子組件、IF 組件、高階組件做條件渲染，因?yàn)檫@四種方式都能提高程序的抽象能力。

往往抽象后的代碼會(huì)更具有復(fù)用性，單個(gè)函數(shù)邏輯更清晰，在切面編程時(shí)更利于理解。

當(dāng)項(xiàng)目很簡(jiǎn)單時(shí)，整個(gè)項(xiàng)目的理解成本都很低，抽象帶來(lái)的復(fù)雜度反而讓項(xiàng)目變成了需要切面編程的時(shí)候，就得不償失了。

總結(jié)一下：

當(dāng)項(xiàng)目很簡(jiǎn)單，或者條件渲染的邏輯確認(rèn)無(wú)法復(fù)用時(shí)，推薦在代碼中用 && 或者三元運(yùn)算符、IIFE 等直接實(shí)現(xiàn)條件渲染。

當(dāng)項(xiàng)目很復(fù)雜時(shí)，盡量都使用 子函數(shù)、子組件、IF 組件、高階組件 等方式做更有抽象度的條件渲染。

在做邏輯抽象時(shí)，考慮下項(xiàng)目的復(fù)雜度，避免因?yàn)槌橄髱?lái)的成本增加，讓本可以整體理解的項(xiàng)目變得支離破碎。

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

如果你想?yún)⑴c討論，請(qǐng)點(diǎn)擊這里，每周都有新的主題，周末或周一發(fā)布。