Dónde almacenar los datos de los componentes de React: estado, almacenamiento, estático y esto

Dónde almacenar los datos de los componentes de React: estado, almacenamiento, estático y esto

Con la llegada de React y Redux, ha surgido una pregunta común:

¿Qué debo guardar en la tienda Redux y qué debo guardar en el estado local ?

Pero esta pregunta es en realidad demasiado simplista, porque también hay otras dos formas de almacenar datos para usarlos en un componente: estática y esta .

Repasemos qué es cada uno de estos y cuándo debe usarlos.

Estado local

Cuando se introdujo React por primera vez, se nos presentó el estado local . Lo importante que debe saber sobre el estado local es que cuando cambia el valor de un estado , se activa una nueva representación.

Este estado se puede transmitir a los niños como accesorios , lo que le permite separar sus componentes entre componentes de datos inteligentes y componentes de presentación tontos si así lo desea.

Aquí hay una aplicación de contador básica que usa el estado local :

Sus datos (el valor del contador) se almacenan dentro del componente de la aplicación y se pueden transmitir a sus hijos.

Casos de uso

Suponiendo que su contador es importante para su aplicación y está almacenando datos que serían útiles para otros componentes, no querrá usar el estado local para mantener este valor.

La mejor práctica actual es utilizar el estado local para manejar el estado de su interfaz de usuario (UI) en lugar de los datos. Por ejemplo, usar un componente controlado para completar un formulario es un uso perfectamente válido del estado local .

Otro ejemplo de datos de IU que podría almacenar en el estado local sería la pestaña seleccionada actualmente de una lista de opciones.

Una buena forma de pensar en cuándo utilizar el estado local es considerar si el valor que está almacenando será utilizado por otro componente. Si un valor es específico para un solo componente (o quizás un solo hijo de ese componente), entonces es seguro mantener ese valor en el estado local .

Conclusión: mantenga el estado de la interfaz de usuario y los datos transitorios (como las entradas de formulario) en el estado local .

Tienda Redux

Luego, después de que pasó un tiempo y todos comenzaron a sentirse cómodos con la idea del flujo de datos unidireccional, obtuvimos Redux.

Con Redux, obtenemos una tienda global . Esta tienda vive en el nivel más alto de su aplicación y transmite datos a todos los niños. Te conectas a la tienda global con el contenedor de conexión y una función mapStateToProps .

Al principio, la gente puso todo en la tienda Redux . Usuarios, modales, formularios, sockets ... lo que sea.

A continuación se muestra la misma aplicación de contador, pero usando Redux. Lo importante a tener en cuenta es que el contador ahora proviene de this.props.counter después de ser mapeado desde mapStateToProps en la función de conexión , que toma el valor del contador de la tienda global y lo asigna a los accesorios del componente actual .

Ahora, cuando hace clic en el botón, se envía una acción y se actualiza la tienda global . Los datos se manejan fuera de nuestro componente local y se transmiten.

Vale la pena señalar que cuando se actualizan los accesorios , también se activa una nueva renderización, como cuando se actualiza el estado .

Casos de uso

La tienda Redux es ideal para mantener el estado de la aplicación en lugar del estado de la interfaz de usuario. Un ejemplo perfecto es el estado de inicio de sesión de un usuario. Muchos de sus componentes necesitarán acceso a esta información, y tan pronto como cambie el estado de inicio de sesión, todos esos componentes (los que se renderizan, al menos) deberán volver a renderizarse con la información actualizada.

Redux también es útil para desencadenar eventos para los que necesita acceso en múltiples componentes o en múltiples rutas. Un ejemplo de esto sería un modal de inicio de sesión, que puede activarse mediante una multitud de botones en toda su aplicación. En lugar de renderizar condicionalmente un modal en una docena de lugares, puedes renderizarlo condicionalmente en el nivel superior de tu aplicación y usar una acción Redux para activarlo cambiando un valor en la tienda .

Conclusión : mantenga en la tienda los datos que desea compartir entre los componentes .

esta.

Una de las características menos utilizadas cuando se trabaja con React es esta . La gente a menudo olvida que React es solo JavaScript con sintaxis ES2015. Todo lo que pueda hacer en JavaScript, también lo puede hacer en React.

El siguiente ejemplo es una aplicación de contador funcional, similar a los dos ejemplos anteriores.

Estamos almacenando el valor del contador en el componente y usamos forceUpdate () para volver a renderizar cuando cambia el valor. Esto se debe a que los cambios en cualquier cosa que no sea el estado y los accesorios no desencadenan una nueva representación .

Esto es en realidad un ejemplo de cómo se debe no utilizar este . Si se encuentra usando forceUpdate () , probablemente esté haciendo algo mal. Para los valores para los que un cambio debería desencadenar una nueva representación, debe usar el estado local o la tienda de accesorios / Redux .

Casos de uso

El caso de uso para esto es almacenar valores para los cuales un cambio no debería desencadenar una nueva representación. Por ejemplo, los enchufes son algo perfecto para almacenar en esto .

Además, muchas personas no se dan cuenta de que ya están usando esto todo el tiempo en sus definiciones de funciones. Cuando define render () , realmente está definiendo this.prototype.render = function () , pero está oculto detrás de la sintaxis de la clase ES2015.

Conclusión: use esto para almacenar cosas que no deberían desencadenar una repetición.

Estático

Los métodos y propiedades estáticos son quizás el aspecto menos conocido de las clases de ES2015 (cálmate, sí, sé que en realidad no son clases bajo el capó) , principalmente porque no se usan con tanta frecuencia. Pero en realidad no son especialmente complicados. Si ha utilizado PropTypes , ya ha definido una propiedad estática .

Los siguientes dos bloques de código son idénticos. La primera es cómo la mayoría de la gente define PropTypes. El segundo es cómo puedes definirlos con static .

Como puede ver, la estática no es tan complicada. Es solo otra forma de asignar un valor a una clase. La principal diferencia entre static y this es que no es necesario crear una instancia de la clase para acceder al valor.

En el ejemplo anterior, puede ver que para obtener el valor staticProperty , podríamos llamarlo directamente desde la clase sin instanciarlo, pero para obtener prototypeProperty , tuvimos que instanciarlo con new App () .

Casos de uso

Los métodos y propiedades estáticos rara vez se usan y deben usarse para funciones de utilidad que todos los componentes de un tipo particular necesitarían.

PropTypes son un ejemplo de una función de utilidad en la que se adjunta a algo como un componente Button, ya que cada botón que renderice necesitará esos mismos valores.

Otro caso de uso es si le preocupa la obtención excesiva de datos. Si está utilizando GraphQL o Falcor, puede especificar qué datos desea recuperar de su servidor. De esta manera, no terminará recibiendo muchos más datos de los que realmente necesita para su componente.

Entonces, en el componente de ejemplo anterior, antes de solicitar los datos para un componente en particular, puede obtener rápidamente una matriz de valores requeridos para su consulta con App.requiredData. Esto le permite realizar una solicitud sin tener que buscar en exceso.

Conclusión: probablemente nunca usarás estática .

Esa otra opción ...

En realidad, hay otra opción, que dejé intencionalmente fuera del título porque debería usarla con moderación: puede almacenar cosas en una variable de ámbito de módulo .

Hay situaciones específicas en las que tiene sentido, pero en su mayor parte simplemente no deberías hacerlo.

Puede ver que esto es casi lo mismo que usar esto, excepto que estamos almacenando el valor fuera de nuestro componente, lo que podría causar problemas si tiene más de un componente por archivo. Es posible que desee usar esto para establecer valores predeterminados si los valores no están vinculados a su tienda ; de lo contrario, sería mejor usar una estática para los accesorios predeterminados.

Si necesita compartir datos entre componentes y desea mantener los datos disponibles para todo el módulo, casi siempre es mejor usar su tienda Redux .

Conclusión: no use variables de ámbito de módulo si puede evitarlo.

Sam Corcos es el desarrollador líder y cofundador de Sightline Maps, la plataforma más intuitiva para la impresión de mapas topográficos en 3D, así como LearnPhoenix.io, un sitio de tutoriales de nivel intermedio-avanzado para crear aplicaciones de producción escalables con Phoenix y React. Obtenga $ 20 de descuento en LearnPhoenix con el código de cupón: free_code_camp