¿Qué son los componentes de presentación y contenedor en React?

React tiene una arquitectura basada en componentes que le anima a dividir su base de código en unidades de funciones reutilizables. Sin embargo, no todos los componentes son iguales. Examinemos las diferencias entre dos tipos comunes, componentes de presentación y contenedor (también conocidos como "con estado").

¿Existe algún estado?

Para empezar, debe tenerse en cuenta que estos términos no se refieren a ninguna característica específica de React. Describen un estilo de escritura de los componentes de React que ayuda a mantener la modularidad y las preocupaciones separadas. La existencia de los dos tipos de componentes se deriva de las elecciones realizadas en el código base.

Solo hay un factor distintivo: los componentes del contenedor tienen el estado y los componentes de presentación no. En la práctica, esto significa que un componente contenedor siempre realiza una llamada a React setState() método. Un componente de presentación nunca hará uso del estado.

Mirando ejemplos

Aquí hay un componente de presentación simple:

import React from "react";
 
class Presentational extends React.Component {
 
    render() {
        return <h1>{this.props.title}</h1>;
    }
 
}
 
export default Presentational;

El componente es extremadamente simple. Hace un solo h1 etiqueta que muestra el texto pasado al componente a través de su title apuntalar. Echemos ahora un vistazo a un componente de contenedor con estado:

import React from "react";
 
class Container extends React.Component {
 
    constructor(props) {
        super(props);
 
        this.state = {
 
            time: (new Date()).toString()
 
        };
 
    }
 
 
    componentDidMount() {
        setInterval(() => {
            this.setState({time: (new Date()).toString()});
        }, 1000);
    }
 
 
    render() {
        return <h1>{this.state.time}</h1>;
    }
 
}
 
export default Container;

El componente contenedor render El método es casi idéntico al del componente de presentación. La diferencia es que el componente contenedor deriva el texto de sí mismo, en lugar de depender de un valor externo pasado como soporte.

Cada segundo, el componente contenedor llama setState() para actualizar el archivo time clave en su estado. Esto hace que React vuelva a renderizar el componente y muestre la nueva hora. Nuestro contenedor tiene su propio estado.

Características de todo tipo

Varias características únicas tienden a surgir tanto en la presentación como en los componentes del contenedor. Mirando primero los componentes de la presentación, es probable que la mayor parte de su código exista dentro render método. Contendrán muy poca lógica ya que su comportamiento está definido por el mundo exterior.

Los componentes de la presentación ignoran felizmente de dónde provienen sus datos. No saben cuándo (o si) cambiará. Es posible que algunos ejemplos ni siquiera acepten accesorios. Aquí hay un elemento decorativo que simplemente renderiza un archivo de imagen específico:

export () => <img src="https://www.cloudsavvyit.com/logo.png" />

Los componentes del contenedor son muy opuestos a sus equivalentes de presentación. Por lo general, encontrará que la mayor parte de la lógica de su sitio termina dentro de un componente contenedor. los render El método puede ser relativamente corto ya que gastará muchas más líneas para recuperar datos de fuentes externas, transformarlos de acuerdo a sus necesidades y luego almacenarlos en el estado.

Un componente del contenedor render El método podría consistir en una sola línea que haga un componente de presentación. Ahora tiene una fuerte separación de preocupaciones, y ambos componentes tienen un papel distinto que respeta plenamente el del otro. El componente contenedor genera los datos; el componente de presentación lo pone en la pantalla.

Así es como se ve en la práctica:

import React from "react";
 
const View = ({title, body}) => (
    <div>
        <h1>{title}</h1>
        <p>{body}</p>
    </div>
);
 
class BlogPostComponent extends React.Component {
 
    constructor(props) {
        super(props);
 
        this.state = {
 
            blog: null
 
        };
 
    }
 
 
    componentDidMount() {
        fetch("/blog-post.json")
            .then(response => response.json());
            .then(blog => this.setState({blog}));
    }
 
 
    render() {
        return (
            <View
                title={this.state.blog.headline}
                body={this.state.blog.content} />
        );
    }
 
}}

BlogPostComponent es nuestro componente contenedor. Sube una publicación a la red. Luego, los datos se proporcionan a View componente para renderizado. View sin importar de dónde obtengan los datos, en el futuro podemos reutilizarlos para ver publicaciones recuperadas de una API de terceros como Facebook o Twitter.

Los componentes de contenedor se denominan así porque tienden a encapsular áreas funcionales completas de su aplicación. Hacen que su proyecto funcione y representan los sistemas de backend de la aplicación.

En una verdadera base de código, BlogPostComponent tendría aún más responsabilidad. Debe monitorear si la publicación se ha cargado y manejar los errores mientras se recupera de la red. En consecuencia, el render El método puede incorporar alguna lógica básica para cambiar lo que se muestra: un mensaje de error, una barra de progreso o nuestra presentación. View componente. Los componentes de presentación nunca tienen una mayor responsabilidad de representar una sección específica de la interfaz de usuario en el DOM.

Ventajas de separar los componentes de presentación y envase

El uso de esta plantilla le ayuda a organizar su base de código y evita que los componentes se vuelvan demasiado voluminosos. Si bien no es una regla estricta y rápida, la separación diligente de los dos tipos mejora la capacidad de mantenimiento a medida que aumenta el número de componentes de su proyecto.

Intente buscar oportunidades para refactorizar como un componente contenedor render el método crece. Lo más probable es que pueda tomar gran parte de su contenido y dividirlo en un nuevo componente de presentación. Esto facilita la reutilización del código de presentación en el futuro. Termina siendo autónomo y capaz de funcionar independientemente de cualquier fuente de datos específica.

Es menos probable que los componentes con estado se reutilicen. Los comportamientos no triviales se acumulan naturalmente dentro de ellos, lo que resulta en dependencias del mundo exterior. Esto no quiere decir que no puedo ser reutilizado: un botón de confirmación de dos pasos contendrá el estado interno (para determinar si se muestra "Restablecer contraseña de usuario" o "¿Está seguro?") pero también se distribuirá por toda la base del código.

Quizás más que cualquier otra cosa, distinguir intencionalmente entre los componentes Presentional y Container lo mantiene al tanto del estado de su aplicación. Minimizar la cantidad de componentes con estado ayuda a crear una base de código manejable y ayuda a separar las preocupaciones.

Si no puede decidir si un componente debe mantener el estado, siga codificando y refactorizando más tarde; probablemente sea demasiado temprano en el ciclo de vida de su proyecto para saber dónde se reunirá la complejidad (y por lo tanto el estado).