资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

立即前往
首页/文章专栏/精读《React 八种条件渲染》

精读《React 八种条件渲染》

Rainie / 2250人阅读

摘要：引言本期精读的文章是介绍了八种条件渲染方式。此时小王接到了需求，终于维护了一个大项目。更多讨论讨论地址是精读八种条件渲染如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。

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

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/95512.html

相关文章

  • 精读《Vue3.0 Function API》

    摘要：拿到的都是而不是原始值，且这个值会动态变化。精读对于的与，笔者做一些对比。因此采取了作为优化方案只有当第二个依赖参数变化时才返回新引用。不需要使用等进行性能优化，所有性能优化都是自动的。前端精读帮你筛选靠谱的内容。 1. 引言 Vue 3.0 的发布引起了轩然大波，让我们解读下它的 function api RFC 详细了解一下 Vue 团队是怎么想的吧！ 首先官方回答了几个最受关注的...

    voyagelab 评论0 收藏0

  • 精读《React16 新特性》

    摘要：引言于发布版本，时至今日已更新到，且引入了大量的令人振奋的新特性，本文章将带领大家根据更新的时间脉络了解的新特性。其作用是根据传递的来更新。新增等指针事件。 1 引言 于 2017.09.26 Facebook 发布 React v16.0 版本，时至今日已更新到 React v16.6，且引入了大量的令人振奋的新特性，本文章将带领大家根据 React 更新的时间脉络了解 React1...

    Nosee 评论0 收藏0

  • 精读《react-easy-state 源码》

    摘要：会自动触发函数内回调函数的执行。因此利用并将依赖置为使代码在所有渲染周期内，只在初始化执行一次。同时代码里还对等公共方法进行了包装，让这些回调函数中自带效果。前端精读帮你筛选靠谱的内容。 1. 引言 react-easy-state 是个比较有趣的库，利用 Proxy 创建了一个非常易用的全局数据流管理方式。 import React from react; import { stor...

    curlyCheng 评论0 收藏0

  • 精读《Scheduling in React》

    摘要：调度系统，支持不同渲染优先级，对进行调度。调度带来的限制调度系统也存在两个问题。调度系统能力有限，只能在浏览器提供的能力范围内进行调度，而无法影响比如的渲染回收周期。精读关于调度系统的剖析，可以读深入剖析这篇文章，感谢我们团队的淡苍提供。 1. 引言 这次介绍的文章是 scheduling-in-react，简单来说就是 React 的调度系统，为了得到更顺滑的用户体验。 毕竟前端做到...

    LeexMuller 评论0 收藏0

  • 精读《React Hooks》

    摘要：更容易将组件的与状态分离。也就是只提供状态处理方法，不会持久化状态。大体思路是利用共享一份数据，作为的数据源。精读带来的约定函数必须以命名开头，因为这样才方便做检查，防止用判断包裹语句。前端精读帮你筛选靠谱的内容。 1 引言 React Hooks 是 React 16.7.0-alpha 版本推出的新特性，想尝试的同学安装此版本即可。 React Hooks 要解决的问题是状态共享，...

    kohoh_ 评论0 收藏0

发表评论

登陆后可评论

0条评论

Rainie

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<