#Hola gente! Me estoy volviendo loco con
sudden pine
Igual estoy loco y no ha podido funcionar este código de la manera que yo espero durante los 2 días en los que vi cambios, si es así me encantaría saber cómo conseguir el resultado que quiero.
Al ser un pet project, tampoco me importaría que el componente fuera dinámico e hiciera el fetch todas las veces que alguien nuevo hace una petición, pero como está dentro de la ruta / quería intentar ahorrarme ese "gasto", el problema es que ahora mismo tampoco estoy muy seguro de cómo hacer para que se haga fetch en todas las peticiones, si es utilizando el force-dynamic o no-cache.
Tampoco se si me falta alguna pieza del rompecabezas y resulta que NextJS o Vercel están cacheando los datos y por eso aunque los datos estén "stale" no está haciendo el fetch como debería, pero cuando he probado a utilizar next: revalidate junto con cache en el fetch, me salta un warning en la consola y en los ejemplos que he visto no se usan juntos, lo que me hace pensar que el revalidate debería saltarse la caché...
hardy nimbus
estas usando ISR?
alternativamente puedes crear un endpoint en un cron que este lea la api y guarde los datos en una bbdd neon por ejemplo
sudden pine
No estoy muy seguro del concepto de ISR... así que supongo que no, no estoy usándolo 😄 . Respecto al tema del cron, es un proyecto muy simple, no tiene ni BBDD, es una landing bastante sencilla y no se si tiene mucho sentido añadirle tanta complejidad, pero igualmente lo miraré, no he usado nunca una bbdd neon, entiendo que sería hacer el fetch cada 12h desde github por ejemplo con un cron, insert a una bbdd o update y listo. El problema es que luego el fetch a la bbdd de donde tiraría la App tendrí aque tener le mismo comportamiento (revalidate o algo asi) no?, entonces estaría un poco en las mismas...
hardy nimbus
a ver vamos a ver algunos conceptos SSG si una pagina no lee bbdd, no consulta api ni usa cookies esa pagina sera generada con SSG es decir sera completamente estatica (esto no tiene nada que ves con usar cliente o no ) el server cada vez que alguien pida la pagina entregara esta prerenderizada (en build time) con Server Components o Con SSR segun sea el caso.
ahora ISR es lo mismo que SSG pero en este caso aplicada al caso de que se use una bbdd o una api y te pongo un ejemplo
imaginate que tienes 50 productos en tu web, por consumir datos esta fuera de SSG pero next puede coger los ID de lor productos que se reciben como parametros y por cada ID va a generar una pagina estatica que se genera una vez al entrar un usuario a esto se le llama ISR, esta pagina se genera dinamicamente, aunque se puede revalidar para que vaya actualizando datos, Ademas es incremental es decir a medida que se añaden productos y estos son consultados la pagina se genera 1 vez pero se sirve a todos los usurios
ojo todo esto es si usas fetch en server si lo haces en cliente eso fetch no se refleja ni en server componente ni en SSR
sudden pine
Okey entendido, en mi caso creo que mi página no es SSG, porque utilizo 2 componentes que hacen llamadas a la API de YT, uno que es el que me está dando problemas, dentro de un Server Component, y otro en un Client component, que ese hace una llamada cada vez que alguien entra a la página y además lo puedo chequear en el apartado de Red de las devtools. El tema es, si yo hago una llamada a una API desde un Server Component, si por defecto yo no especifico ni revalidación ni caché, yo entendí que ese componente se pre-renderiza en build time y luego siempre se va a devolver el componente que se pre-renderizó en build time, sin que Next/Vercel lo actualicen. Eso es justo lo que me estaba pasando al principio y por lo que necesitaba realizar un nuevo deploy para que los cambios se actualizasen. Ahora, entendí que añadiendo { next: { revalidate: x } } como parámetro en el fetch de mi Server Component, NextJS detectaría que ese componente tiene que "actualizar" los datos de la petición HTTP a la API cada X tiempo (en mi caso, 12h). Me estoy perdiendo algo? Simplemente seguí los pasos que se especifican en la documentación, además he visto muchos issues abiertos en el repo de NextJS hablando de que el time-based revalidation no funciona bien.
Si ese es el caso, es decir, que debería estar funcionando y no está funcionando por un bug o algo que no se cómo debuggear, existe alguna otra manera de hacer que ese Server Component haga fetch a la API cada vez que un usuario entra a la web? Puedo forzar ese comportamiento? Ahora mismo la web recibe pocas visitas así que no me preocupa congestionar la API, y si en el futuro se soluciona el problema del time-based revalidation me moveré allí...
Por tu comentario asumo que en el momento en el que hago una petición HTTP a una API mi página pasa de SSG a ISR, pero como digo, el revalidate de 12h estuvo funcionando como 2 días, y luego dejó de actualizarse, a partir de ese momento siempre muestra los mismos datos, incluso después de hacer un deploy sigue manteniendo lo mismo, que podría ser un problema de caché pero no se si sería de Next o de Vercel, o de otro sitio que no identifico. Lo más raro aún es que trabajando en local (al no haber caché), sí que tengo los datos más actualizados, tanto con npm run dev como con npm run build && npm run start, pero en el momento en el que se hace deploy y se visita la página, vuelve a mostrar los datos antiguos, cosa que es muy rara porque esperaría que en build time se hiciera una petición para al menos pre-renderizar los últimos resultados aunque luego no se vayan actualizando
hardy nimbus
Okey entendido, en mi caso creo que mi página no es SSG, porque utilizo 2 compon...
No te estas perdiendo nada deberia funcionarte bien
para pasar se SSG a ISR es necesario explicitarlo tu y se debe hacer usando el un param pero no es tu caso
el SSG no se aplica si hay datos por ejemplo un fetch es complicado darte una respuesta pq el codigo aparenta estar bien si tu codigo no es privado podria clonar el repo hacer el deploy y probar, como alternativa solo por probar prueba a poner fetch('loquesea', {cache:"no-store"})
o
en la pagina que lee los datos ponle export const revalidate=loquesea
en teoria la pagina provocara el fetching de todas las peticiones que se lanzen en ella
sudden pine
el SSG no se aplica si hay datos por ejemplo un fetch es complicado darte una re...
Voy a probar esto a ver, lo que entiendo es que sería quitar el revalidate y poner el cache verdad? porque he intentado a poner los dos y me salta un warning en la consola, entiendo que no se pueden tener ambas opciones...
sudden pine
en teoria la pagina provocara el fetching de todas las peticiones que se lanzen ...
También tenía pensado probarlo, pero eso creo que lo que hace es convertir la página entera en dinámica verdad? y justo eso me daba un poco de cosa porque al ser una landing sería hacer toda la página web dinámica... probaré con el cache: no-store primero a ver...
hardy nimbus
También tenía pensado probarlo, pero eso creo que lo que hace es convertir la pá...
si haces un fetch en teoria tu pagina y va a ser dinamic
fetch headers incluso cookies va a ser dinamico pq hablamos de valores que van a ir cambiando y que no son predecibles
el fetch se puede solventar con isr pq lo que hace es para cada id los datos se van a asumir que cambian poco y que son iguales para todos los usuarios
para hacerlo tendrias que meter el fetch en un getStaticProps eso le dice al back que debe generar la pagina como estatica usando los datos del fetch y si puedes poner el revalidate tambien
sudden pine
pues en la documentación no entendí eso, entendí que usando un fetch sin parámetros, se hacía el fetch en build time y la página seguía siendo SSG
y de hecho estaba funcionando así hasta que hice los cambios con el time-based revalidation 🤔
hardy nimbus
has probado a hacer la build en local? te mostrara que paginas son dinamicas
sudden pine
he probado a hacer build en local pero no se cómo ver qué paginas son dinamicas y cuales no mirando el build
igualmente, sólo tengo una página, /
no hay distintas páginas, ni slugs, ni bases de datos, es una landing super simple
por eso me esta costando tanto entender por qué falla si mi código es prácticamente el ejemplo de la documentación de next
y esque el problema es debuggear server calls
no hay manera de ver cuándo, cómo y dónde se hacen los fetch en server components
hardy nimbus
deberia funcionarte no entiendo pq no lo hace
tienes otra opcion que es un deploy hook pero no me gusta demasiado
pues tienes razon me ha generado una pagina estatica con un fetch
y es raro pq juraria que eso no me lo hizo en la ultima build XD
ahora me salen dinamicas
sudden pine
cómo ves cuál es dinámica y cuál estática?
sudden pine
cómo lo sabes? jajaja
sudden pine
eso quiere decir que todas son dinámicas? va por ruta no?
y si fuera unas cuantas estáticas y unas dinámicas que saldría?
hardy nimbus
espera que creo otra pagina
sudden pine
por ejemplo, para probar lo que me has dicho del no-cache, cómo se que está funcionando/no funciona? hay alguna forma de testearlo? o tiene que ser deploy y ver qué pasa?
es que no tengo ni idea de cómo debuggear SSR la verdad
hardy nimbus
tendras que alterar los datos que devuelve el fetch
no te confundas ssr es una cosa server componente es otra cosa
SSR es que un client component se renderizar en el server se manda al navegador despues llega el js de react y la pinta de nuevo
server component es la pagina es renderizada en el back y se manda al cliente pero nunca envias el js
si haces la build te saledinamica?
y pq solo tienes una pagina?
hardy nimbus
por ejemplo, para probar lo que me has dicho del no-cache, cómo se que está func...
not-foutn es la unica estatica pero podria convertir locale in ISR
sudden pine
Ohh entiendo, voy a investigar un poco a ver si saco hueco y miro todo esto bien, sigo sin saber cómo testear/debuggear qué ocurre exactamente en runtime, pero al menos puedo hacer build y comprobar lo que está interpretando Next