Интенсивное чтение "React Eight Conditional Rendering"

внешний интерфейс программист JavaScript React.js

1. Введение

Статьи, прочитанные в этом выпуске:8 React conditional rendering methods

Описывает восемь стилей условного рендеринга React.

Шаблонный условный рендеринг очень распространен.Когда он встречается, он часто используется случайным образом, так как же написать его с лучшей ремонтопригодностью? Давайте сначала рассмотрим восемь методов условного рендеринга!

2 Обзор

IF/ELSE

Поскольку JSX поддерживает смешивание js и html, альтернативное использование может решить проблему условного рендеринга:

function render() {
  if (renderComponent1) {
    return <Component1 />;
  } else {
    return <div />;
  }
}

return null

Если вы не хотите отображать пустые элементы, лучше использоватьnullвместо пустогоdiv:

function render() {
  if (renderComponent1) {
    return <Component1 />;
  } else {
    return null;
  }
}

Это повышает эффективность рендеринга React.

компонентная переменная

Назначив компонент переменной, вы можете произвольно изменить его перед возвратом.

function render() {
  let component = null;

  if (renderComponent1) {
    component = <Component1 />;
  }

  return component;
}

Тернарный оператор

Тернарный операторСинтаксис следующий:

condition ? expr_if_true : expr_if_false

Также удобно использовать на JSX:

function render() {
  return renderComponent1 ? <Component1 /> : null;
}

Но когда тернарные операторы вложены друг в друга, стоимость понимания становится высокой.

&&

Это чаще всего используется из-за наименьшего количества кода.

function render() {
  return renderComponent1 && <Component1 />;
}

IIFE

IIFE означает, что функция выполняется сразу, то есть следующий код:

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

Когда вы глубоко разбираетесь в коде JSX и хотите написать большой кусок логики, помимо возврата к началу, вы также можете использовать IIFE:

function render() {
  return (
    <div>
      {(() => {
        if (renderComponent1) {
          return <Component1 />;
        } else {
          return <div />;
        }
      })()}
    </div>
  );
}

Подсборка

Это вариант IIFE, который заменяет функцию немедленного выполнения обычной функцией:

function render() {
  return (
    <div>
      <SubRender />
    </div>
  );
}

function SubRender() {
  if (renderComponent1) {
    return <Component1 />;
  } else {
    return <div />;
  }
}

компоненты ПЧ

Сделать условный компонент рендерингаIFвместо js-функцийif:

<If condition={true}>
  <span>Hi!</span>
</If>

Реализация этого компонента также очень проста

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 <AnotherComponent {...props} />;
    }

    return <Component {...props} />;
  };
}

3 Интенсивное чтение

С таким количеством способов добиться условного рендеринга основное внимание уделяется удобочитаемости и ремонтопригодности.

Например, рендеринг компонента достигается вызовом функции:

<div>{renderButton()}</div>

Это все еще выглядит избыточным, если вы используетеrenderButtonопределение геттера, мы можем записать его так:

<div>{button}</div>

На самом деле нам нужна кнопка, а неrenderButton. Затем вы можете пойти дальше и просто инкапсулировать его в компонент JSX:

<div>
  <Button />
</div>

Делать эти усилия или нет, зависит от сложности приложения. Если сложность приложения очень высока, то стоит попробовать использовать последний пакет, чтобы логика каждого файла была максимально независимой и простой.

Если сложность приложения относительно невелика, то будьте осторожны, не переинкапсулируйте его, чтобы не запутаться в нем.

Так что похоже, что это еще один вопрос без определенного ответа.Выбор инкапсуляции зависит от сложности приложения.

сложность приложения

Для любой инкапсуляции кода этот раздел будет добавленлогика подключениясложность.

Предполагая, что сложность кода в любом случае постоянна, в следующем коде сложность соединения равна 0, а дляrenderДля функций логическая сложность равна 100:

function render() {
  if (renderComponent) {
    return isOk ? <Component1 /> : <Component2 />;
  } else {
    return <div />;
  }
}

Следующий код разбит на две функции, логическая сложность правильнаяrender SubComponentоба равны 50, но сложность соединения равна 50:

function render() {
  if (renderComponent) {
    return <SubComponent>;
  } else {
    return <div />;
  }
}

function SubComponent() {
  return isOk ? <Component1 /> : <Component2 />
}

Видно, что мы уменьшаем логическую сложность каждой функции за счет разделения функций, но увеличиваем сложность соединения.

Сделаем сравнение, предположим, что нормальный программист может легко запомнить 10 функций за раз. Если их больше, связь вызова между функциями будет запутанной.

Когда приложение маленькое

Когда объем кода приложения относительно невелик, предположим, что всего функций 10. Если сделать логическую абстракцию и разделить 10 подфункций, то общая логическая сложность останется неизменной, а количество функций станет равным 20.

В настоящее время, если Сяо Ван хочет изменить этот проект, ему нужно найти местонахождение кода ключа.

Если нет логической абстракции, Сяо Ван может запомнить сразу 10 функций и быстро выполнить требования.

Если приложение выполняет логическую абстракцию, логическая сложность, которую ему нужно понять, остается прежней, но количество функций, которые нужно прочитать, становится 20. Сяо Вану нужно продолжать прыгать в подсказках, как детектив.Он все еще нашел только 10 ключевых функций, но всего функций всего 20. Логика не сложная.Стоит ли оно того?

Сяо Ван может пробормотать про себя: «Простая логика абстрактна, а я долго искал файл!

Когда приложение большое

В настоящее время объем кода приложения относительно велик. Предположим, что всего функций 500. Мы не рассматриваем преимущества повторного использования, которые приносит абстракция. Если предположить, что их нельзя использовать повторно, то после логической абстракции общая логика сложность остается неизменной, а функция меняется, стало 1000.

В это время Сяо Ван получил спрос и, наконец, поддержал крупный проект.

Сяо Ван знал, что этот проект очень сложный, и он не чувствовал, что сможет понять весь проект с самого начала, поэтому он считал себя детективом и готовился исследовать шаг за шагом.

Теперь есть два варианта: один — исследовать без логической абстракции, а другой — исследовать после логической абстракции.

Если нет логической абстракции, Сяо Ван должен столкнуться с500такая функция:

function render() {
  if (renderComponent) {
    return isOk ? <Component1 /> : <Component2 />;
  } else {
    return isReady ? <Component3 /> : <Component4 />;
  }
}

Если сделать логическую абстракцию, Сяо Вану придется столкнуться с1000такая функция:

function render() {
  if (renderComponent) {
    return <Component1And2 />;
  } else {
    return <Component3And4 />;
  }
}

После того, как проект большой, общее количество функций не влияет на поиск подсказок, а общая глубина подсказок почти всегда фиксирована, обычно около 5 слоев.

Сяо Ван понимает, что стоимость 5 или 10 функций одинакова, но когда нет логической абстракции, каждая из этих 5 функций смешивается с другой логикой, что влияет на понимание функции.

Здесь уместна логическая абстракция.

4 Резюме

В общем, я предпочитаю использовать подфункции, подкомпоненты, компоненты IF и компоненты более высокого порядка для условного рендеринга, потому что эти четыре метода могут улучшить способность программы к абстракции.

Часто абстрагированный код будет более пригодным для повторного использования, логика отдельной функции более ясна, и ее легче понять в аспектном программировании.

Когда проект очень прост, затраты на понимание всего проекта очень низки, а сложность, вызванная абстракцией, делает проект необходимым для аспектного программирования, которое не стоит потери.

В заключение:

  • Когда проект очень простой, или логику условного рендеринга нельзя использовать повторно, рекомендуется использовать ее в коде&&Или тернарные операторы, IIFE и т. д. напрямую реализуют условный рендеринг.
  • Когда проект очень сложный, попробуйте использовать подфункции, подкомпоненты, компоненты IF, компоненты более высокого порядка и другие методы для более абстрактного условного рендеринга.
  • При выполнении логической абстракции учитывайте сложность проекта, чтобы избежать увеличения стоимости абстракции и фрагментации проекта, который можно понять как единое целое.

еще 5 обсуждений

Адрес обсуждения:Интенсивное чтение «Восемь условных рендерингов в React» · Выпуск №90 · dt-fe/weekly

Если вы хотите принять участие в обсуждении, пожалуйста,кликните сюда, с новыми темами каждую неделю, выходящими по выходным или понедельникам.

Категории