Decidí intentar usar el retroceso en lugar de redux y me encontré con el problema de almacenar en caché las colecciones mutables. Para ser más precisos, el problema no está en el almacenamiento en caché de la respuesta en sí, sino en la gestión posterior de los datos, sin volver a solicitar. Por ejemplo, solicité una serie de franjas horarias libres que se mostrarán en el calendario, el usuario puede cambiarlas (desbloquear o bloquear). Después de la solicitud (desbloquear o bloquear) puedo usar useRecoilRefresher_UNSTABLE para restablecer el caché del selector y solicitar ranuras actualizadas nuevamente, esto funciona como se esperaba, pero ¿por qué hacer esto si puede recordar el resultado después de la primera solicitud y luego simplemente actualizarlo? mi código es:

 export const _cacheFreeSlotsA = atom<SlotsArray | null>({ key: '_cacheFreeSlotsA', default: null, }); export const freeSlotsS = selector<SlotsArray>({ key: 'freeSlotsS', get: async ({ get }) => { const cache = get(_cacheFreeSlotsA); if (cache) { return cache; } const res = await slotsAPI.getFreeSlots(); return res.slots; }, }); export const useUpdateFreeSlotsS = () => { const setFreeSlots = useSetRecoilState(_cacheFreeSlotsA); const currentSlots = useRecoilValue(freeSlotsS); return async (req: ChangeSlotsRequest) => { await slotsAPI.changeSlots(req); switch (req.operation) { case 'open': setFreeSlots([...currentSlots, ...req.slots]); break; case 'close': setFreeSlots(difference(currentSlots, req.slots)); break; } }; }; // export const useUpdateFreeSlotsS = () => { // const refresh = useRecoilRefresher_UNSTABLE(freeSlotsS); // return async (req: ChangeSlotsRequest) => { // await slotsAPI.changeSlots(req); // refresh(); // }; // };

Funciona pero parece una solución. ¿Hay una forma más elegante y clara de implementar este comportamiento? (sería perfecto si dentro del método get de freeSlotsS pudiera acceder al método set , pero desafortunadamente no está en los argumentos)