Bien, ahora tenemos una pregunta sobre la notificación recién mencionada de que la aplicación CSS en el repositorio de GitHub se convierte en app.post.css. ¿Ahora necesitas prestar atención a esto? Creo que en algún lugar estamos usando post CSS en lugar de CSS. Sí, pero al final, si vas a usar post CSS necesitas usar post CSS. En general, por ejemplo, en mi ejemplo de esta masterclass no estoy usando post CSS, estoy usando CSS. Sí, exactamente, esto es más porque agregamos el complemento de Tile Window dentro de Svelte. Con Svelte-TileWindow, genera todas las, digamos, las cosas solicitadas para que Tile Window funcione. Entonces, este PostCSS fue generado por ellos. Así que creo que debería funcionar porque estás usando PostCSS en TileWindow. Si no quieres usar TileWindow y quieres eliminarlo, puedes deshacerte de él y usar un CSS normal. Sí, exactamente. Pero si quieres usar TileWindow, déjalo como está. Sí, está funcionando bien. Porque aquí tienes la cosa de preprocess. Sí, por ejemplo, si aplicas algo a PostCSS, si vas a redefinir algo para TileWind. Sí, pero no es algo obligatorio. Digamos que es opcional.
Bien, entonces, ¿quieres mostrarnos cómo implementar o? Sí, sí, si quieres puedo mostrarte algo sobre la implementación. Por supuesto que quiero. Sí. Pero hasta ahora todo está claro. Más o menos, más o menos, menos, más. Sí, pero sí, no te asustes al final. Si pruebas Atom con esto, verás que es más fácil porque ahora es, al final, la última parte de esta masterclass como puedes ver siempre está creando componentes, recordando definir el componente, y eso es todo. Así que al final es bastante fácil, ¿verdad? Entonces puedes acelerar el proceso de creación de nuevos componentes. Y mi sugerencia es crear algunos componentes que puedas reutilizar en múltiples proyectos. En caso de que necesites crear múltiples componentes. Pero si quieres, puedo mostrarte algo sobre después de que crees tu sitio web, quieres publicarlo en algún lugar, ¿verdad? Entonces, localmente, ¿vas a usar NPM run dev, verdad? Y estás usando el servidor web local. Y en este caso, tienes una especie de Node.js en el fondo que sirve las páginas y demás, ¿verdad? Pero, ¿qué pasa si quieres generar un sitio estático a partir de tu proyecto y publicarlo en algún lugar, ¿verdad? Por ejemplo, en las páginas de GitHub o Netlify o en AWS S3 o algún CDN. Entonces, en este caso, puedes configurar Svelket para generar un sitio estático en lugar de uno dinámico, ¿verdad? Voy a compartir mi pantalla. En la pantalla compartida, ¿puedes ver el control de zoom, no? No. ¿Pero solo puedes ver el terminal? Solo el terminal, sí. Bueno, bien. Puedo mover esto. Bien, bien. Perfecto. Así que necesito el terminal. Y en este caso, estoy usando un proyecto, más o menos, el mismo que construimos hoy con Alba. Permíteme resaltar algunas diferencias, ¿de acuerdo? Porque como sabes, en ciencias de la computación, puedes lograr las mismas cosas de varias formas, ¿verdad? Así que solo para que sepas que probablemente es mejor saber que, por ejemplo, puedes lograrlo de diferentes maneras. Una forma es, por ejemplo, en este caso, no estoy usando un preprocess de Svelte. Estoy usando Vite preprocess, ¿verdad? Y la diferencia principal es que el preprocess de Svelte es más complejo, te permite acceder a características adicionales. Por ejemplo, usando la plantilla, para cargar archivos externos y demás. Para este tipo de ejemplo, creo que Vite preprocess es suficiente, ¿verdad? Y la ventaja también es porque Vite preprocess viene incluido con Svelte, ¿verdad? Así que no tengo que instalar nada más. Otra forma de cargar los componentes, en mi caso, como puedes ver, en mi ejemplo, no estoy usando el layout. No es nuestra mejor práctica, ¿verdad? Porque el layout es muy útil cuando necesitas algún contenedor compartido entre las páginas. Así que mi sugerencia es usar Layout.js y Layout.Svelte. Pero para empezar, para mantenerlo simple, puedes omitir el layout porque no es obligatorio. En este caso, estoy cargando en el page.js. Y como puedes ver, estoy usando una función de bloque de historia de usuario porque quiero centralizar y crear una especie de, como puedes ver, se importa por SB Lib, ahora podemos ver. Y mi sugerencia en lugar de usar punto punto barra invertida punto punto barra invertida. Así que una ruta relativa cuando vas a importar algo para Svelkite, usando $Lib. $Libs es la palabra clave mágica para referirse a una variable. Para referirse a la lib, al directorio de lib de origen. Así que en este caso, por ejemplo, si vas a mover este tipo de page.js a una subcarpeta, no tienes que reescribir la referencia porque no es relativa, ¿verdad? Así que en este caso, estoy importando desde s.blib y en s.blib tengo la función de bloque de historia de usuario donde tengo el bloque de historia en él. Así que simplemente moví a un lugar centralizado el bloque de historia en él. Estoy usando el token de acceso, sí, pero en este caso lo estoy cargando desde el archivo .env. Entonces, por ejemplo, si no quieres usar el token de acceso directamente o codificado en tu código fuente, puedes importarlo, y estoy usando una convención de Svelkit, y estoy usando $env, barra invertida estática, barra invertida pública, así que significa que estoy cargando una clave pública, y en este caso tengo el token de acceso público y la región pública, ¿verdad? Entonces, de esta manera puedo crear algunos parámetros para controlar el token de acceso y la región. Y luego tengo, obviamente, el .env donde tengo el token de acceso público y la región pública. Y luego, y típicamente, pongo el .env en el archivo .gitignore y para, porque necesitaba un ejemplo, tengo .env.example que refleja el extractor y el nombre de la clave que necesito en mi código fuente. Pero como puedes ver, puedo poner algún ejemplo, ¿verdad? Así que en este caso, puedo ignorar en git el .env pero tengo el .env.example. Entonces, por ejemplo, en el proyecto, si tengo un nuevo desarrollador que quiere ayudarme, pueden clonar el proyecto, copiar el .env.example en .env y luego personalizar su token de acceso. ¿Verdad? Sí, este. Luego tenemos también otra forma, porque en el pasado tuve algunos problemas al importar los componentes, especialmente si vas a jugar con el renderizado del lado del cliente, el renderizado del lado del servidor y solo el lado del servidor. Así que de esta manera, resolví un problema para importar el componente. Como puedes ver, la sintaxis es un poco diferente. Así que ahora, personalmente, estoy usando el await import de esta manera. Y de esta manera, como puedes ver, es el primer paso para hacerlo más dinámico, ¿verdad? Porque por ejemplo, esto es una cadena, así que puedes recorrer todos los archivos que tienes y luego realizar el await import. Pero sí, es solo una pequeña cosa. Sí, otra cosa que quiero mostrarte, sí, está en ahora. Y como puedes ver en este caso, estoy omitiendo el padre no solo porque no tengo el layout, sino porque tengo el bloque de historia de usuario, ¿verdad? Y luego de la misma manera, estoy cargando la API de bloque de historia de usuario, y luego puedo usarla, de manera similar a los demás. Probablemente otra mejora que puedo hacer es porque puedo seleccionar las historias de borrador de las historias de los publicadores y tienen que configurar la versión, probablemente es mejor mover este valor codificado en una clave en el .env, ¿verdad? Así que solo una mejora de este código. Pero déjame mostrarte, en este caso, si voy a ejecutar este tipo de proyecto, puedo ver que, déjame mostrarte, ¿de acuerdo? Este es el proyecto servido por el servidor localmente, ¿verdad? Y el servidor local usa Node.js, ¿verdad? Así que significa que si quiero implementar este tipo de proyecto en algún lugar, necesito Node.js en el lado del servidor. Pero probablemente, a veces, es algo que no quiero porque quiero generar algunas páginas estáticas a partir de este contenido, ¿verdad? Por esta razón, para publicar cosas en SvelteKit, tienes los adaptadores. Tienes muchos adaptadores, pero quiero centrarme principalmente en el adaptador static, ¿verdad? Porque el adaptador static te permite crear una copia o mejor dicho, generar un archivo HTML estático en la fase de construcción, ¿verdad? Y luego, una vez que estén listos, puedes copiarlos en algún lugar. Bien, para esto, tienes que instalar NPX y FTP, el m.adapterstatic es algo que ya tengo en mi proyecto, pero déjame hacerlo de nuevo, solo para mostrarte. Bien, como puedes ver, ya lo tengo, y luego puedo ir a la configuración. En la configuración, tengo que ir al archivo de configuración svelte.config, y como puedes ver en el kit, tenemos el adaptador. En el adaptador, estoy usando el estático, como puedes ver, porque de forma predeterminada en el svelte.config.js predeterminado, encontrarás algo como esto, ¿de acuerdo? Pero porque instalé el estático, voy a cambiar el estático. Y luego puedo usar el adaptador. En el adaptador, puedo definir, esencialmente, puedes definir más parámetros, pero los más importantes son, por ejemplo, el directorio, en este caso build, donde quieres crear tu sitio estático. Y luego lo último es, ir al archivo plus-page.js, o si tienes el archivo layout.js, tienes que declarar una variable, una constante, lo siento. La constante es PRENDER true. En este caso, puedo generar el sitio estático, ¿verdad? Bien. Ahora puedo ejecutar npm run build. Y el npm run build porque tenemos el adaptador static, genera todos los archivos. Y ahora tengo mi sitio web estático en el directorio de construcción. Así que tengo el index.html, tengo about.html, como puedes ver, porque en este caso solo tengo dos páginas. Y luego tengo underscore app donde tengo, si te lo muestro, probablemente es mejor mostrártelo en el código, si inspecciono el directorio de construcción, como puedes ver, está ignorado por Git porque no necesitas confirmar y enviar este tipo de activos generados. Y así en el underscore app tienes todo, por ejemplo, CSS y JavaScript generados. Como puedes ver, tengo un JavaScript para cada componente.
React Advanced Conference 2021
Comments