React functional stateless component, PureComponent, Component; ¿cuáles son las diferencias y cuándo debemos usar qué?

¿Cómo decide, cómo elige entre estos tres basados en el propósito/tamaño/accesorios/comportamiento de nuestros componentes?

Extendiéndose desde React.PureComponent o desde React.Component con un método personalizado shouldComponentUpdate tienen implicaciones de rendimiento. El uso de componentes funcionales sin estado es una opción "arquitectónica" y no tiene ningún beneficio de rendimiento desde el primer momento (todavía).

• Para componentes simples y solo de presentación que necesitan ser reutilizados fácilmente, prefiera stateless functional componente. De esta manera, está seguro de que están desacoplados de la lógica real de la aplicación, que son fáciles de probar y que no tienen efectos secundarios inesperados. La excepción es si por alguna razón tiene muchos de ellos o si realmente necesita optimizar su método de renderizado (ya que no puede definir shouldComponentUpdate para un componente funcional sin estado).

• Extend PureComponent si sabe que su salida depende de props/state simples ("simple" significa que no hay estructuras de datos anidadas, como PureComponent realiza una comparación superficial) Y necesita/puede obtener algunas mejoras de rendimiento.

• Extienda Component e implemente su propio shouldComponentUpdate si necesita algunas ganancias de rendimiento al realizar una lógica de comparación personalizada entre los props siguientes/actuales y el estado. Por ejemplo, puede realizar rápidamente una comparación profunda usando lodash # isEqual:

  class MyComponent extends Component {
      shouldComponentUpdate (nextProps, nextState) {
          return !_.isEqual(this.props, nextProps) || !_.isEqual(this.state, nextState);
      }
  }
  

Además, implementar su propio shouldComponentUpdate o extender desde PureComponent son optimizaciones, y como de costumbre debe comenzar a buscar en eso solo si tiene problemas de rendimiento (evite optimizaciones prematuras). Como regla general, siempre trato de hacer estas optimizaciones después de que la aplicación esté en un estado de trabajo, con la mayoría de las características ya implementadas. Es mucho más fácil centrarse en los problemas de rendimiento cuando realmente se interponen en el camino.

Más detalles

Componentes funcionales sin estado:

Estos se definen simplemente usando una función. Ya que no hay estado interno para un componente sin estado, la salida (lo que se renderiza) solo depende de los props dados como entrada a esta función.

Ventajas:

• La forma más simple posible de definir un componente en React. Si no necesita administrar ningún estado, ¿por qué preocuparse por las clases y la herencia? Una de las principales diferencias entre una función y una clase es que con la función está seguro de que la salida depende solo de la entrada (no de ningún historial de la anterior ejecución).

• Idealmente, en tu app deberías intentar tener tantos componentes sin estado como sea posible, porque eso normalmente significa que moviste tu lógica fuera de la capa de vista y la moviste a algo como redux, lo que significa que puedes probar tu lógica real sin tener que renderizar nada (mucho más fácil de probar, más reutilizable, etc.).).

Contras:

• No hay métodos de ciclo de vida. No tienes una manera de definir componentDidMount y otros amigos. Normalmente lo hace dentro de un componente padre más alto en la jerarquía para que pueda convertir todos los hijos en apátridas.

• No hay forma de controlar manualmente cuando se necesita un re-renderizado, ya que no se puede definir shouldComponentUpdate. Un re-renderizado ocurre cada vez que el componente recibe nuevos props(no hay forma de comparar poco profundo, etc.). En el futuro, React podría optimizar automáticamente los componentes sin estado, por ahora hay algunas bibliotecas que puedes usar. Dado que los componentes sin estado son solo funciones, básicamente es el problema clásico de la "memoización de funciones".

• No se admiten referencias: https://github.com/facebook/react/issues/4936

Un componente que extiende la clase PureComponent FRENTE a un componente normal que extiende la clase de componente:

React solía tener un PureRenderMixin que se podía adjuntar a una clase definida usando la sintaxis React.createClass. El mixin simplemente definiría un shouldComponentUpdate realizando una comparación superficial entre los siguientes accesorios y el siguiente estado para comprobar si algo ha cambiado. Si nada cambia, entonces no hay necesidad de realizar un re-renderizado.

Si quieres usar la sintaxis ES6, no puedes usar mixins. Así que por conveniencia React introdujo una clase PureComponent de la que puedes heredar en lugar de usar Component. PureComponent simplemente implementa shouldComponentUpdate de la misma manera que el PureRendererMixin. Es principalmente una cosa de conveniencia para que no tenga que implementarlo usted mismo, ya que una comparación superficial entre el estado actual/siguiente y los accesorios es probablemente la más escenario común que puede darle algunas victorias rápidas de rendimiento.

Ejemplo:

class UserAvatar extends Component {
    render() {
       return <div><img src={this.props.imageUrl} /> {{ this.props.username }} </div>
    }
} 

Como puede ver, la salida depende de props.imageUrl y props.username. Si en un componente padre renderizas <UserAvatar username="fabio" imageUrl="http://foo.com/fabio.jpg" /> con las mismas props, React llamaría a render cada vez, incluso si la salida fuera exactamente la misma. Sin embargo, recuerde que React implementa la diferencia de DOM, por lo que el DOM no se actualizaría realmente. Aún así, realizar la diferencia dom puede ser costoso, por lo que en este escenario sería un desperdicio.

Si el componente UserAvatar se extiende PureComponent en su lugar, se realiza una comparación superficial. Y debido a que props y nextProps son lo mismo, render no se llamará en absoluto.

Notas sobre la definición de "puro" en React:

En general, una "función pura" es una función que evalúa siempre el mismo resultado dada la misma entrada. La salida (para React, eso es lo que devuelve el método render) no depende de ningún historial/estado y no tiene ningún efectos secundarios (operaciones que cambian el "mundo" fuera de la función).

En React, los componentes sin estado no son necesariamente componentes puros de acuerdo con la definición anterior si llamas a "sin estado" un componente que nunca llama a this.setState y que no usa this.state.

De hecho, en un PureComponent, todavía puede realizar efectos secundarios durante los métodos de ciclo de vida. Por ejemplo, podría enviar una solicitud ajax dentro de componentDidMount o podría realizar algún cálculo DOM para ajustar dinámicamente el altura de un div dentro de render.

La definición de "Componentes tontos" tiene un significado más "práctico" (al menos en mi entendimiento): a un componente tonto "se le dice" qué hacer por un componente padre a través de props, y no sabe cómo hacer las cosas, pero usa devoluciones de llamada de props en su lugar.

Ejemplo de un "smart" AvatarComponent:

class AvatarComponent extends Component {
    expandAvatar () {
        this.setState({ loading: true });
        sendAjaxRequest(...).then(() => {
            this.setState({ loading: false });
        });
    }        

    render () {
        <div onClick={this.expandAvatar}>
            <img src={this.props.username} />
        </div>
    }
}

Ejemplo de un "mudo" AvatarComponent:

class AvatarComponent extends Component {
    render () {
        <div onClick={this.props.onExpandAvatar}>
            {this.props.loading && <div className="spinner" />}
            <img src={this.props.username} />
        </div>
    }
}

Al final diría que "tonto"," sin estado "y" puro " son conceptos muy diferentes que a veces pueden superposición, pero no necesariamente, dependiendo principalmente de su caso de uso.