Когда использовать компоненты React на базе класса ES6 в сравнении с функциональными компонентами ES6 React?

Потратив некоторое время на изучение React, я понимаю разницу между двумя основными парадигмами создания компонентов.

У меня вопрос, когда я должен использовать какой и почему? Каковы преимущества / компромиссы одного над другим?

ES6 классы:

import React, { Component } from 'react';

export class MyComponent extends Component {
  render() {
    return (
      <div></div>
    );
  }
}

Функциональность:

const MyComponent = (props) => {
    return (
      <div></div>
    );
}

Я считаю функциональным всякий раз, когда этим компонентом не удается манипулировать состоянием, но так ли это?

Я предполагаю, что если я использую какие-либо методы жизненного цикла, лучше всего использовать компонент на основе классов.

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

Поскольку они легкие, написание этих простых компонентов в качестве функциональных компонентов является довольно стандартным.

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

Дополнительная информация: https://facebook.github.io/react/docs/reusable-components.html#es6-classes

РЕДАКТИРОВАТЬ : Многое из вышесказанного было правдой, до введения React Hooks.

• componentDidUpdateможет быть скопирован с useEffect(fn), где fnэто функция для запуска при рендеринге.

• componentDidMountМетоды можно реплицировать с помощью useEffect(fn, []): где fn- функция, запускаемая при повторном рендеринге, и []массив объектов, для которых компонент будет перерисован, если и только если хотя бы один из них изменил значение с момента предыдущего рендеринга. Поскольку их нет, useEffect()запускается один раз, на первом монтировании.

• stateможет быть реплицировано с useState(), чье возвращаемое значение может быть преобразовано в ссылку на состояние и функцию, которая может установить состояние (т. е. const [state, setState] = useState(initState)). Пример может объяснить это более четко:

const Counter = () => {
  const [count, setCount] = useState(0)

  const increment = () => { 
    setCount(count + 1);
  }

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={increment}>+</button>
    </div>
  )
}

default export Counter

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

«Функции обработки событий переопределяются для каждого рендера в функциональных компонентах»

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

Если они есть, вы можете предотвратить переопределение функций с помощью useCallbackи useMemoхуков. Однако имейте в виду, что это может ухудшить производительность вашего микроскопического кода .

Но, честно говоря, я никогда не слышал, чтобы переопределение функций было узким местом в приложениях React. Преждевременная оптимизация - корень всего зла - беспокойтесь об этом, когда это проблема

Всегда старайтесь по возможности использовать функции без сохранения состояния (функциональные компоненты). Существуют сценарии, в которых вам нужно использовать обычный класс React:

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

ОБНОВИТЬ

Теперь есть класс React, PureComponentкоторый вы можете расширить (вместо Component), который реализует свой собственный, shouldComponentUpdateкоторый позаботится о сравнении мелких объектов. Читать далее

ОБНОВЛЕНИЕ март 2019

https://overreacted.io/how-are-function-components-different-from-classes/

ОБНОВЛЕНИЕ Фев 2019:

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

Их мотивация:

1.) It’s hard to reuse stateful logic between components
2.) Complex components become hard to understand
3.) Classes confuse both people and machines

Функциональный компонент с хуками может делать почти все, что может делать компонент класса, без каких-либо недостатков, упомянутых выше.

Я рекомендую использовать их, как только вы сможете.

Оригинальный ответ

Функциональные компоненты не более легкие, чем компоненты на основе классов, «они работают точно как классы». - https://github.com/facebook/react/issues/5677#issuecomment-241190513

Приведенная выше ссылка немного устарела, но в документации React 16.7.0 говорится, что функциональные и классовые компоненты:

"эквивалентны с точки зрения React." - https://reactjs.org/docs/components-and-props.html#stateless-functions

По сути, нет никакой разницы между функциональным компонентом и компонентом класса, который просто реализует метод рендеринга, кроме синтаксиса.

В будущем (цитируя приведенную выше ссылку) «мы [React] могли бы добавить такие оптимизации».

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

- https://reactjs.org/docs/react-api.html#reactmemo

- https://reactjs.org/docs/react-api.html#reactpurecomponent

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

Начиная с React 16.8, термин «Функциональные компоненты без состояния» вводит в заблуждение, и его следует избегать, поскольку они больше не являются лицами без состояния ( React.SFC устарел , Дэн Абрамов в React.SFC ), они могут иметь состояние, они могут иметь хуки (которые действуют как методы жизненного цикла), они более или менее пересекаются с компонентами класса

Компоненты на основе классов

• штат
• методы жизненного цикла
• памятка с помощью React.PureComponent

Функциональные компоненты:

• состояние ( useState , useReducer перехватывает)
• методы жизненного цикла (через хуки useEffect , useLayoutEffect )
• памятка через памятку HOC

Почему я предпочитаю функциональные компоненты

• Реагировать обеспечивает useEffect крюк , который является очень четким и лаконичным способом объединить componentDidMount, componentDidUpdateи componentWillUnmountметоды жизненного цикла
• С помощью хуков вы можете извлечь логику, которая может быть легко разделена между компонентами и тестируемой
• меньше путаницы по поводу объема работ

Реагировать мотивацию , почему с помощью крюков (т.е. функциональных компонентов).