Saludos! tengo un input de busqueda por nombre que ejecuta un fetch cada que hacen onChange. tengo problemas para gestionar dichos fetch, cada letra genera un nuevo cambio de estado (nuevo render) y a su vez un nuevo fetch, por lo que cada que muere el componente queda un fetch en el aire que cambia cosas que no debería, es decir LOS MUERTOS NO HABLAN! xD. para solucionar esto decidí crear un AbortController y en el clean up del componente limpiar ese FETCH. el detalle es que parece que no tengo exito abortando el FETCH pq sigo teniendo el mal comportamiento en el input
#Input de busqueda loco (FETCH)
carmine locust
Pasaste la referencia del abortController al fetch?
rigid loom
lo hago sin ref
carmine locust
Entonces creo que esperas magia. Cómo piensas abortar si no tienes una referencia al abortController del fetch anterior?
subtle lichen
useEffect(() => {
const getData = async (controller) => {
try {
const resp = await fetch("url" + id, { signal: controller.signal });
const data = await resp.json();
setData(data);
} catch (err) {
if (err.name !== 'AbortError') {
console.error("Fetch error:", err);
}
}
}
const controller = new AbortController();
getData(controller);
return () => {
controller.abort();
};
}, [id]);
``` mete en id lo que cambieMe explico. Imagina que estás buscando 'abc':
- onChange se ejecuta para 'a', y le pasas un abortController
- onChange se ejecuta para 'b'... Cómo puedes cancelar el fetch de 'a' si no tienes una referencia al abortController que le pasaste?
rigid loom
pero no es igual ? se supone la agarra de ahí no ?
yo no cree el AbortController en el useEffect pq hago la fetch en otro lado. useEffect no tiene acceso al componente muerto ?
carmine locust
Ve el código de Nuitari
errant pond
Ese const controller = new AbortController() te crea una instancia nueva y que no tiene que ver con la anterior
rigid loom
ya lo vi, entiendo lo que hacen, pero no tengo claro donde poner el new AbortC.. para que accedan tanto el onChange como el cleanup
carmine locust
En su código, se crea un abort controller dentro del useEffect, y si cambia el id, entonces se ejecuta el cleanup y se aborta.
errant pond
const [controller] = useState(() => new AbortController())
no es que me guste, pero es una opción 😂
con eso, solo se crea una vez
lo de Nautari, es lo más simple para que resuelvas
rigid loom
entiendo, pero solo hago 1 render, por lo q solo se crea un solo abort. como no tengo mas estados.
de hecho si se crea otro render. deseo q sea otro abort distinto en efecto. igual voy a hacerlo por las dudas y veo si hala xD
errant pond
si tienes un estado de zustand
rigid loom
aja
errant pond
eso provoca más renders
carmine locust
Necesitas crear un abort controller por fetch.
errant pond
ese cleanup es solo cuando desmontas/desaparece ese componente
no para cada rerender
carmine locust
UUna vez que entiendas eso, entenderás que tienes que estructurar la lógica del fetching de datos para que funciones como debería
rigid loom
desmontar es diferente a re.renderizar ?
errant pond
muy diferente
rigid loom
ah! ok
carmine locust
desmontar es diferente a re.renderizar ?
Sí
rigid loom
ok. dejen aplico y veo si hala. asi cambia la cosa
errant pond
👍
rigid loom
joda sigue igual T.T
puse [controller] y sin array y funciona igual de mal T.T
hay forma de saber en las devtools si si está abortando los fetch ?
rigid loom
es que si hago eso, ya se que funcionará, pq ya lo he hecho, pero quiero q mi store se encargue de ese fetch.
se supone para eso es la store, q haga todo y los componentes solo consuman.
errant pond
porque aun no estás haciendo un abort cada que ocurre un onChange
solo lo estás haciendo al desmontar el componente...
rigid loom
es que. el useEffect vacio, está atento a cada cambio o re-render
rigid loom
mm pensé q si.
hago onchage, cambia estado, cambia estado, useEffect se ejecuta- no ?
errant pond
solo se ejecuta si la dependencia en el arreglo cambia, o al desmontar el componente
rigid loom
por eso. al no poner nada. cambia cada q cambia alguno de sus estados, en plan [todos]
errant pond
a que te refieres con no poner nada? puedes poner acá el ejemplo
errant pond
vale, asi si se ejecuta en cada render
pero sigues teniendo el problema del momento en que se ejecuta
velo de esta forma
onChange provoca un request a la api
y en seguida se ejecuta el useEffect que cancela el último request
que es el que acabas de iniciar 😂
rigid loom
si, pero el cleanup se ejecuta matando el anterior, no el actual
por lo q debería dejar viva la ultima fetch
errant pond
tienes un solo abortController,
no estas creando uno distinto cada vez
lo que te pasé de const [controller] = useState(() => new AbortController()) descartalo
rigid loom
joda q problema... xD . deja veo console.log a ver si se ejecuta o no
errant pond
sale hasta mejor con un useRef que decía Moy
rigid loom
puse esos console.log
errant pond
estás en sala2 no?
errant pond
voy allá
rigid loom
bn
rigid loom
ya haló xD
errant pond
👍
rigid loom
errant pond
ahora si
rigid loom
el problema era que no estaba abortando pq no mandaba bn el puto signal xD
que lindo ver lo rojo e.e
rigid loom
Según un profesor, los fetch y en general las cosas que exijan un cleanup (setInterval, setTime, etc) deben ir dentro de un sideEffect, puesto que limpia solamente lo que se haga dentro del mismo sideEffect. asi que al final separé la logica de set el input y luego en el componente como efecto secundario del cambio del input genero el fetch dentro del useEffect