Muy bien. Así que definimos nuestro fragmento aquí y realmente la tarjeta de publicación, se renderiza en este punto dentro de la lista de publicaciones. Aquí es donde necesitaríamos, podemos poner el fragmento para la tarjeta de publicación dentro de otro componente, que es este para la lista de publicaciones. Creemos uno para este archivo también. Así que escribe eso, así que si estás siguiendo, escribe esto conmigo, así que exporta Const. Esto será campos de lista de publicaciones, así, igual a GQL. Muy bien, presiona Enter un par de veces, ábrelo, y este será otro fragmento que estamos definiendo. Así que fragmento, ahí vamos, fragmento, campos de lista de publicaciones. Ahí tienes con en publicación, ¿verdad? Entonces, si defines el tipo como hablamos, abre algunas llaves y realmente todo este componente se preocupa solo por el ID de la base de datos porque lo usa como la clave prop, ¿verdad? Entonces, eso lo podemos definir aquí, un ID de la base de datos. Sin embargo, todo lo demás, simplemente se pasa a la tarjeta de publicación. Así que aquí es donde podemos hacer esta cosa donde importamos los campos de la tarjeta de publicación desde este componente adyacente aquí desde la tarjeta de publicación. Entonces, si escribes eso, importa los campos de la tarjeta de publicación desde la tarjeta de publicación, tomaremos este fragmento e interpolaremos dentro de este fragmento aquí. Presionaré Enter y lo haremos con esta sintaxis de dólar para interpolar algunos datos. Lo pegaré aquí. Ahora podemos realmente utilizar este fragmento dentro de este otro fragmento dentro de la tarjeta de publicación, solo tomaré su nombre, ¿verdad? Y luego recuerda la sintaxis para esto es solo los tres puntos. Así que diré dentro de este otro fragmento, justo al lado de donde está el ID de la base de datos, voy a hacer punto, punto, punto campos de la tarjeta de publicación, ¿verdad? Muy bien, y ahora estos campos de la tarjeta de publicación, a su vez podemos exportarlos y finalmente usarlos en la página del blog. Así que veamos cómo podemos hacer eso. Entonces, de vuelta en la página del blog, ahora, podemos hacer, déjame revisar el chat, okay, creo que lo estamos haciendo bien. Avísame si tienes alguna pregunta mientras avanzas con esto de los fragmentos. Así que dentro de la página del blog ahora, podemos importar los campos de la lista de publicaciones desde la lista de publicaciones. Y podemos ponerlo en esta línea aquí. Ya estamos importando este componente desde ese archivo. Así que ahora solo queremos importar algo más. Podemos poner una coma, leer la coma y luego las llaves. Y lo otro que queremos de ese archivo es esta constante que hemos definido aquí, ¿verdad? Entonces eso es lo que también estamos importando de la lista de publicaciones. Y esto, como vimos antes, vamos a presionar Enter e interpolaremos para que tengamos acceso a él dentro de obtener publicaciones. Y ahora, como vimos antes, ni siquiera necesitamos el ID de la base de datos en este punto. Todo lo que necesitamos es el fragmento de campos de la lista de publicaciones. Así que copiaré el nombre de este fragmento y luego punto, punto, punto campos de la lista de publicaciones. Muy bien, guardaré eso. Guardaré eso. Y la tarjeta de publicación ya está guardada así que veamos si funciona. Sí, todo sigue funcionando. Así que espero que veas el flujo aquí. Así que empezando desde el nivel más alto como el blog, estamos diciendo aquí están los requisitos de datos de este componente. Realmente lo único que le importa es la colección de publicaciones, ¿verdad? Así que si lo miras, sabes la consulta que definimos aquí, solo dice que quiero una colección de publicaciones. En cuanto a lo que cada uno de los nodos tiene, simplemente lo está diferiendo, está diciendo cualquier campo de la lista de publicaciones que ese componente dice que necesita, eso es lo que deberías obtener de GraphQL, ¿verdad? Está diferiendo esa toma de decisiones a este componente de campos de lista de publicaciones. Así que si vamos allí y decimos, está bien, campos de lista de publicaciones, ¿qué necesitas ahora? ¿Cuáles son tus requisitos de datos? Nos dice que le importa este ID de la base de datos, ese es el campo específico que necesito para renderizar mis datos. En cuanto a cualquier otro campo en esto, estoy diferiendo esa toma de decisiones. Ve a la tarjeta de publicación, ya sabes, y mira los campos que necesita. Estoy diferiendo cualquier otra toma de decisiones a la tarjeta de publicación. Y luego dices, está bien, hagámoslo, vayamos a la tarjeta de publicación. Componente de tarjeta de publicación, ¿qué necesitas? ¿Cuáles son tus requisitos de datos, ¿verdad? Y nos dice que necesita estos campos específicos en el objeto de publicación para satisfacer sus necesidades de datos, ¿verdad? Entonces simplemente puedes tomar todos estos y seguir adelante y renderizarlos dentro del componente. Así que espero que pienses que este patrón es genial y poderoso. Te permite, como dije varias veces, colocar las necesidades de datos de tu componente junto con el componente en sí. Y hace que las cosas sean realmente fáciles de gestionar. He descubierto que, a medida que tu base de código se mueve y cambia y crece, es como, siempre y cuando tengas un fragmento aquí con las necesidades de datos y eso se mapee al componente en sí, entonces es bastante fácil mantener estos dos sincronizados en comparación con si tuvieras estas necesidades de datos definidas, ya sabes, varios componentes en el árbol de componentes que están definidos en algún otro lugar lejano, o lo que sea. Esto hace que esté cerca de la fuente de donde realmente se usan. Muy bien, eso es todo para los componentes o el tema de los fragmentos. Creo que si revisas este último, el último chequeo aquí, si revisas los fragmentos, los usa en todas partes. No solo para la página del blog, sino también para la página individual aquí, rompe algunas de las cosas que la página de publicación individual descompone en fragmentos y luego los compone también, tal vez también la página de categoría. Entonces sí, si quieres ver, me detendré ahí con un ejemplo que hicimos con la página del blog, cómo definir fragmentos y componerlos juntos. Pero si quieres ver algunos otros ejemplos, como puedes ver este compromiso aquí desde nuestro punto de control para ver el, y eso sería como la aplicación final en ese punto. Sí, así que creo que casi se acaba el tiempo. Nos quedan un par de minutos. Me encantaría escuchar algunas preguntas, sin embargo. Como mencioné, trabajo en una empresa específica de WordPress, WP Engine, y hago cosas de WordPress sin cabeza todo el día. Así que he pensado en estas cosas y he estado, mi equipo produce todo tipo de recursos en este sitio de desarrolladores si quieres ver alguno de nuestros contenidos. Este es mi mundo donde vivo. Así que, por eso me inscribí en este tema en particular en la Cumbre de React. Entonces, Victor dice, ¿qué CMS prefieres? Sí, esa es una gran pregunta. Personalmente, he pasado mucho, mucho tiempo en el espacio de WordPress, y lo conozco muy bien. Nunca he lanzado otro proyecto de producción utilizando otro CMS. Realmente me gustan algunos de los CMS sin cabeza modernos que están apareciendo, creo que son interesantes. Como Contentful, Sanity y Prismic y algunos de esos. Creo que son interesantes y tienen algunas formas modernas interesantes de hacer el modelado de contenido y luego obtener los datos en el formato que necesitarías para renderizar componentes de React y cosas así. Está construido con una mentalidad de front-end desacoplada desde el principio. Creo que eso es bastante interesante, bastante poderoso. Así que ciertamente me gusta lo que están haciendo muchos de los CMS. La única desventaja con ellos, sin embargo, es que todos son propietarios. Una excepción sería Strapi. Strapi es uno de código abierto, como el basado en JavaScript que podrías revisar. S-T-R-A-P-I. Aún no he revisado Strapi pero me gusta el hecho de que sea de código abierto y las licencias gratuitas o lo que sea es genial. Así que ese sería uno para revisar pero todos los demás que mencioné, Contentful, Prismic, Sandy, todos son propietarios lo que me pone un poco nervioso. Es como si construyera un sitio para mi cliente o lo que sea, algún negocio, si construyo un sitio utilizando el CMS y luego deciden cuadruplicar sus precios o cambiar su licencia para que partes de ella no sean accesibles, como pueden hacerlo en cualquier momento. Así que me gusta que WordPress sea gratuito y de código abierto donde si construyes algo sobre headless WordPress, siempre es gratuito y de código abierto y no tienes que preocuparte por la compañía detrás de él triplicando sus precios o cambios de licencia o lo que sea, como dije. Así que me gusta esa parte de ello, pero Strapi, como dije, también podría tener algunas de esas mismas ventajas. Así que WordPress, la otra cosa de ello es que es tan robusto en este punto y tantos equipos de marketing y personas como esa realmente lo aman por su interfaz de edición y la experiencia que brinda a los creadores de contenido. Entonces, si haces headless WordPress, te permite seguir dando a esas personas su CMS preferido con el que les encanta trabajar, pero también divertirte como desarrollador en el front-end y construir aplicaciones basadas en componentes utilizando tecnologías como React y Svelte. Entonces, sí, no puedo hablar profundamente sobre las comparaciones, pero sí, admiro algunas de las cosas que otros CMS están haciendo, pero la mayor parte de mi experiencia está en el mundo de WordPress en este momento. Nikhil o Nikhail dice, ''¿Has utilizado Next.js como generador de sitios estáticos? ''¿Tiene sentido obtener los datos ''de la API de WordPress mientras se construye el sitio estático ''y tener un CMS sin cabeza? Tal vez ni siquiera en la web, solo un WordPress sin cabeza local y SSG Next.js, solo preguntando.'' Sí, ciertamente podrías hacer eso. Sí, te refieres a usar Next.js como opción para generar un sitio completamente estático, ¿verdad, donde todas las páginas de tu sitio terminan siendo archivos HTML que podrías distribuir a través de un CMS, o un CDN más bien, y es, ya sabes, sitios completamente estáticos pre-renderizados. Sí, podrías hacer eso si no tienes nada dinámico en tu sitio de WordPress, ya sabes, si no tienes un sistema de comentarios o formularios de contacto, ya sabes, u otros tipos de formularios que los usuarios necesitarían completar e interactuar con ellos, donde podrías necesitar un servidor para intervenir, ya sabes, para hacer eso. Si no tienes nada de eso y tu sitio es solo contenido estático, como destinado para el consumo, entonces sí, eso podría ser una buena, podría ser una buena opción. Y como decías, incluso te refieres a ejecutar el sitio de WordPress localmente, ya sabes, Next JS, cuando ejecuta una compilación, simplemente puedes acceder a tu sitio de WordPress local, ya sabes, para construir todas las páginas y luego implementar esas páginas estáticas en la web y WordPress en sí ni siquiera necesitaría estar en línea. Y tienes razón, ciertamente podrías hacer eso. Sí, ya sabes, probablemente no querrías hacerlo para algún cliente de producción, ya sabes, tener el sitio de WordPress viviendo en la máquina de una persona o lo que sea, como probablemente no sería la mejor idea allí, ya sabes, querría alojarlo en algún lugar con algún host de WordPress. Pero sí, si es un proyecto personal y es para tu propio sitio y dices tengo copias de seguridad en mi computadora. Entonces, ese database de WordPress, ya sabes, sé que ya está respaldado y no me preocupo de que desaparezca, entonces sí, ciertamente podrías hacer eso. Eso sería genial.
Comments