Así que estoy haciendo una imagen/svg de marcador de posición para usar el componente de imagen Nextjs y copié este código de su repositorio. No tengo mucha experiencia en el desarrollo de backend (principalmente frontend), así que tuve que investigar sobre el búfer, los flujos, window.bto, etc. Lo que no puedo entender completamente es por qué se necesita el tipo de typeof window === "undefined" y el subsiguiente líneas de código. Si elimino eso, también funciona.
Puedo entender que es un caso límite, como un "qué pasaría si". Pero no puedo entender por qué es necesario. Siempre se representará en un navegador. ¿Por qué verificar si la ventana no está definida?
Gracias de antemano y perdón por el mal inglés, no es mi idioma principal.
Código Nextjs
const shimmer = (w, h) => ` <svg width="${w}" height="${h}" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs> <linearGradient id="g"> <stop stop-color="#333" offset="20%" /> <stop stop-color="#222" offset="50%" /> <stop stop-color="#333" offset="70%" /> </linearGradient> </defs> <rect width="${w}" height="${h}" fill="#333" /> <rect id="r" width="${w}" height="${h}" fill="url(#g)" /> <animate xlink:href="#r" attributeName="x" from="-${w}" to="${w}" dur="1s" repeatCount="indefinite" /> </svg>` const toBase64 = (str) => typeof window === 'undefined' ? Buffer.from(str).toString('base64') : window.btoa(str) const Shimmer = () => ( <div> <ViewSource pathname="pages/shimmer.js" /> <h1>Image Component With Shimmer Data URL</h1> <Image alt="Mountains" src="/mountains.jpg" placeholder="blur" blurDataURL={`data:image/svg+xml;base64,${toBase64(shimmer(700, 475))}`} width={700} height={475} /> </div>Mi implementación en el componente.
<Image src={props.src} layout={props.layout} width={props.width} height={props.height} placeholder="blur" blurDataURL={`data:image/svg+xml;base64,${toBase64(shimmer(300, 300))}`} />Next.js es un marco para React que ayuda a los desarrolladores a administrar la representación del lado del servidor en React.
Hay muchos beneficios de la representación del lado del servidor, que incluyen: almacenar en caché páginas específicas (o almacenar en caché solo lo que es público y mantener los datos específicos del usuario o los datos requeridos por autenticación para cargarse en la interfaz).
Dado que Next.js realiza la representación del lado del servidor, eso significa que a veces usan la función reactDOMServer.renderToString() en Node.js. Construyen la página completa como HTML y la envían al usuario que está navegando por el sitio. La intención de Next.js al generar la página HTML es maximizar las capacidades de los CDN y mejorar el SEO de su página. Entonces, no solo representan la página de React como HTML. Realizan las solicitudes de API y await que regresen, lo que les permite representar la lista de elementos con los que respondió la API.
Esto puede permitir a los desarrolladores aprovechar los aspectos dinámicos de React y ejecutar la función de JavaScript dentro del código de representación (como: {products.length <= 0 && <EmptyStateDiv type='products' />} ), pero lamentablemente no puede usar JavaScript/funcionalidad que vive en el navegador del cliente/usuario (a diferencia de JavaScript/node.js/navegador multiplataforma).
Entonces, si bien toda la funcionalidad integrada en JS (como los métodos de prototipo de Array) se puede usar sin pensarlo dos veces. Otras funcionalidades como fetch se pueden usar multiplataforma en Node.js y Frontend/React pero solo debido a bibliotecas multiplataforma como isomorphic-fetch . Y finalmente, otra funcionalidad vive solo dentro del navegador y no es nativa de JavaScript. Esto incluye especialmente métodos/propiedades accesibles desde el navegador del usuario específico, como podría ser excelente: document.innerWidth is > 1600 pero eso no es posible ya que esta función se ejecuta antes de que un cliente específico haya procesado la página. Next.js construyó la página en el lado del servidor donde cosas como document / window no están definidas y donde no tendría sentido que existieran. (Aunque probablemente pueda optimizar y almacenar en caché diferentes experiencias para usuarios de dispositivos móviles y de escritorio, leyendo algunos encabezados del cliente).
Si bien se ejecuta en el servidor en Node.js (representación del lado del servidor), la ventana no está definida en el tiempo de ejecución de Node.js y podría bloquearse antes de la representación. Tampoco tendría sentido que la ventana se defina en el servidor, ya que la ventana generalmente contiene propiedades específicas del navegador como clientHeight/clientWidth o permite que un usuario haga redireccionamientos del lado del cliente con window.location.assign , lo que sería imposible en el servidor.
Si este código se ejecuta en el servidor como parte de la representación previa (ya sea representación del lado del servidor o representación estática), no habrá window (y, por lo tanto, no window.btoa para la codificación base64) ya que no hay navegador, sino Se puede utilizar el Buffer de node.js.