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

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

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

ES6 / 7 классы:

import React, { Component } from 'react';

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

функционал:

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

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

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

3 105
javascript reactjs redux ecmascript-6

3 ответа:

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

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

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

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

84

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

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

обновление

теперь есть класс React под названием PureComponent что вы можете продлить (вместо Component) который реализует свой собственный shouldComponentUpdate Это заботится о мелком сравнении реквизита для вас. подробнее

29

функциональные компоненты не более легкие, чем компоненты на основе классов, "они работают точно так же, как классы."- https://github.com/facebook/react/issues/5677

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

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

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

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

в будущем (цитируя приведенную выше ссылку) "мы [реагируем] можем добавить такие оптимизации", но пока мой команда нашла согласованность лучший вариант (особенно для неизбежного нового разработчика, который приходит и путается о том, где this.props пошли или случайно имена props что-то еще в функциональный компонент).

4