Redux: ¿eliminar parte del estado como componente de desmontaje?

Indagamos en todo internet para así traerte la solución a tu duda, si continúas con alguna difcultad deja tu comentario y contestamos porque estamos para ayudarte.

Solución:

A menos que esté tratando con decenas de miles de registros, probablemente no valga la pena el esfuerzo y complicará su código. ¿Estás seguro de que se trata de un problema real para tu aplicación? Mantener el estado anterior es realmente útil, por ejemplo, para el botón “Atrás” instantáneo.

Si lo desea, puede enviar una acción de limpieza al desmontar ciertos componentes o en un cambio de ruta. Sin embargo, creo que en la gran mayoría de las aplicaciones esto sería innecesario, y mantener un caché podría ser preferible siempre que recuerde verificar si hay elementos nuevos después del montaje.

Si sus datos fueron cargados en el detalle componente (no Maestro), creo que está bien restaurar el estado.

Debido a que el componente de estado de detalle en realidad no se ‘almacenará’, además, los datos se descargarán nuevamente incluso si está volviendo a show el mismo recurso. y si vas a show un recurso diferente, el estado residual del último recurso visitado permanece hasta que se descargan los datos del recurso actual, y eso se conectará a los usuarios.

Uno de los enfoques es definir una acción/reductor para restaurar el estado cuando el detalle el componente se va a desmontar.

Otra forma es restaurar el estado cuando cambia la ruta:

import  LOCATION_CHANGE  from 'react-router-redux'
import * as types from 'constants/ActionTypes'

const initialState = 

export default function show(state = initialState, action) 

  switch (action.type) 

    case types.LOGOUT:
    case LOCATION_CHANGE:
      return initialState

    case types.SHOW_SUCCESS:
      return action.payload

    default:
      return state
  

@Dan Abramov no solo no es necesario, sino que también puede generar errores difíciles de rastrear. Hemos experimentado que, dado que el componenteWillUnmount() es asíncrono, cuando se envía una acción para borrar un determinado reductor dentro de componenteWillUnmount() puede causar errores cuando pasa de esta vista directamente a otra vista que se basa en esta sección del reductor.

Por ejemplo:

Digamos que tiene la siguiente forma de estado de tienda:

const state = 
    list: ["thing"]

Entonces imagine que uso este estado en una vista llamada Cosas

Luego imagine que me doy cuenta de que en 9 de cada 10 de mis otras vistas no estoy usando state.list, así que decido que quiero evitar la “inflación” o las “fugas de memoria” y pongo una acción que borra esta sección de mi estado. en el componenteWillUnmount en Things

Se esperaría que la secuencia de eventos siempre fuera:

1. Desmontar cosas
2. Despachar acción para borrar state.list
3. Luego monta la siguiente vista
4. Luego, en 1 de las 10 vistas, vuelva a llenar state.list SI lo necesita en esta vista

Sin embargo, esta no es la secuencia. A veces, en cambio, será:

1. Desmonte Things y vaya directamente a otra vista que necesite state.list
2. Inmediatamente monte esta siguiente vista. Nuestra vista SÍ necesita state.list, por lo que despachamos esta acción. O dado que state.list ya existe, no despachamos la acción de búsqueda porque ya la tenemos.
3. Solo un momento después, el componenteWillUnmount envía la acción CLEAR con éxito.
4. Involuntariamente BORRÓ la lista de estado en esta vista aunque no quería hacerlo. Y, por supuesto, como estamos @conectados, ¡nuestra pantalla se queda en blanco!

Es decir, aunque Redux es síncrono, el componente WillUnmount no es síncrono y, por lo tanto, no se puede garantizar que cualquier acción enviada dentro de él suceda en el orden previsto. Este es un problema en cualquier caso extremo en el que vaya directamente a otra vista que SÍ quiera esa sección del estado.

Una forma de evitar esto es tener un condicional dentro de componentWillUnmount que diga “Solo envíe la acción CLEAR SI dejo esta vista (desmontándola) por la siguiente razón… NO CUANDO VAYA A ESTA OTRA VISTA QUE DEPENDE DE ESTA SECCIÓN DE STATE. Puede hacer esto, por ejemplo, teniendo una propiedad en localState que se llame algo así como shouldIClearList:, y es true por defecto a menos que haga clic en el botón llamado goToMyOtherViewThatNeedsList. Sin embargo, esto agrega una complejidad innecesaria en muchos casos en los que el enlace a la otra vista que necesita la lista está en un componente principal de nivel superior completamente diferente como la barra de navegación y, por lo tanto, ya sea que la vista a la que intenta ir sea o no esta “problemática view” no es fácilmente “conocido” por su componente secundario Things.

De hecho, creo que la idea de “Bloat” es válida, y la mejor manera de borrar redux al desmontar sin encontrarse con un problema como este sería muy apreciada. La única solución que puedo ver de inmediato es NO borrar nunca el reductor dentro del componenteWillUnmount. Es demasiado peligroso. O si es absolutamente necesario, asegúrese de que su aplicación no tenga absolutamente ninguna forma de pasar de esta vista directamente a otra vista que necesite esta sección de estado (algo muy difícil de hacer en una aplicación enorme sin tener que tener algún tipo de de documentación compartida entre todos los equipos de software de la empresa).

Recuerda algo, que te brindamos la opción de esclarecer si te ayudó.

---

---

Utiliza Nuestro Buscador