¿Es bueno actualizar los cachés dentro de los reductores? Quiero decir, ¿se puede actualizar un caché en cada parte de mi front-end (componentes, pantallas, ganchos, ayudantes...) o se debe delegar este comportamiento a una parte específica del sistema?
En mi aplicación, cada usuario tiene un campo "TotalFollowers".
Estoy almacenando los datos de cada usuario en el estado de un contexto de reacción. Para realizar actualizaciones puras y complejas basadas en el estado anterior, estoy usando un reductor.
Además, implementé un caché LRU en memoria, solo para evitar solicitudes de base de datos innecesarias y mejorar la experiencia/rendimiento del usuario. En este caché, estoy almacenando algunos datos que también están incluidos en el contexto de reacción del que he hablado... así que, en ambos lados, los datos deben ser iguales.
Como estoy actualizando el campo totalFollowers de un usuario específico cuando el usuario actual lo sigue, en mi reductor tengo lo siguiente:
export default (otherUsers, action) => { switch (action.type) { case "follow-user": { const { userId, isFollowing } = action; const prevUserData = otherUsers.get(userId); return new Map([ ...otherUsers, [ userId, { ...prevUserData, totalFollowers: prevUserData.totalFollowers + (isFollowing ? 1 : -1) ] ] ); } ... } }Como dije antes... mi caché tiene algunos datos que también están incluidos en el contexto (que usa el reductor que describí), y "totalFollowers" es uno de esos datos.
Si mi reductor me da la posibilidad de acceder al estado de forma nativa/atómica, creo que actualizar mi caché dentro de él es una buena idea. Pero he leído que el único propósito de un reductor es actualizar el estado... Tengo miedo de eso, ya que mi idea de actualizar el caché dentro del reductor podría ser un antipatrón (evitar efectos secundarios dentro de funciones puras)
¿Qué piensas? ¿Es "correcto" realizar actualizaciones de caché dentro de los reductores?
import { usersCache } from "../../services/firebase/api/users" export default (otherUsers, action) => { switch (action.type) { case "follow-user": { const { userId, isFollowing } = action; const prevUserData = otherUsers.get(userId); const newTotalFollowers = prevUserData.totalFollowers + (isFollowing ? 1 : -1); usersCache.updateUser(userId, { totalFollowers: newTotalFollowers }); // merge update return new Map([ ...otherUsers, [ userId, { ...prevUserData, totalFollowers: newTotalFollowers ] ] ); } ... } }Caché y reductor son dos cosas diferentes.
solo cuando desee construir una mini máquina de estado, elegirá usar reducer. Pero incluso hacer eso tiene su propio problema, normalmente cada actualización de cualquier propiedad del estado debería desencadenar una actualización. Por lo tanto, reducir o no depende principalmente de la decisión de si la lógica que está construyendo está realmente condensada (o retorcida) dentro de un grupo de propiedades relacionadas.
Tengo el presentimiento de que sabes caché más que yo. así que me saltaré esta parte. Utiliza el caché para asegurarse de que las cosas se puedan devolver rápidamente si se cumple la misma condición, también quiere asegurarse de tener al menos más de dos condiciones. De lo contrario, será un desperdicio.
También mencionaste el contexto, pero el contexto también es diferente. Se asegura de que pueda compartir un valor. Pero la parte complicada es que cada vez que un valor de contexto cambia debido a un cambio de estado, mostrará todos los elementos secundarios debajo de él.
Normalmente pensaría que el caché es un muy buen complemento para el reductor (o contexto). Sin embargo, la ganancia aquí es el caché, por ejemplo, ahorra tiempo para omitir el cálculo.
Pero no apuestes por el render. ¡Incluso cuando obtiene de la memoria, el valor conectado al reductor o al contexto aún cambia! Lo que significa que aún puede volver a renderizarse al 100 % con el caché.
Lo que trato de decir es que el caché es un concepto que no tiene nada que ver con React. Si lo aplicas, solo obtienes su propio beneficio, pero no esperes otros beneficios.