Crear una aplicación de WordPress sin cabeza con Next.js y WPGraphQL

Rate this content
Bookmark

En este masterclass, aprenderás cómo construir una aplicación de Next.js que utiliza Apollo Client para obtener datos de un backend de WordPress sin cabeza y usarlo para renderizar las páginas de tu aplicación. Aprenderás cuándo debes considerar una arquitectura de WordPress sin cabeza, cómo convertir un backend de WordPress en un servidor GraphQL, cómo componer consultas utilizando el IDE GraphiQL, cómo colocar fragmentos de GraphQL junto con tus componentes, y más.

173 min
04 Jul, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Comencemos con el masterclass sobre cómo construir una aplicación de WordPress sin cabeza con Next.js y WP GraphQL. Cubriremos los beneficios y desventajas de un enfoque sin cabeza, exploraremos la aplicación terminada y la página del blog, e implementaremos características como la búsqueda y las páginas de publicaciones individuales. También aprenderemos cómo convertir WordPress en un servidor GraphQL, configurar Apollo Client, componer consultas de GraphQL y usar fragmentos. El masterclass discute el almacenamiento en caché, la invalidación de caché y el uso de Next.js como generador de sitios estáticos. Se comparan varias opciones de CMS, incluyendo WordPress, Contentful, Sanity, Prismic y Strapi.

Available in English

1. Introducción a Headless WordPress

Short description:

Comencemos con la masterclass sobre cómo construir una aplicación de Headless WordPress con Next.js y WP GraphQL. Cubriremos temas como qué es Headless WordPress y por qué deberías considerarlo. Luego nos sumergiremos en la parte práctica de la masterclass, donde clonarás una aplicación de Next.js y la conectarás a un backend de WordPress utilizando GraphQL. También discutiremos los beneficios de una arquitectura headless y por qué podrías elegirla en lugar de WordPress tradicional. ¡Así que empecemos!

Entonces, sí, empecemos ya que estamos unos minutos pasados de la hora. Así que gracias, en primer lugar, por estar aquí, por sintonizar esta masterclass. Estoy realmente emocionado por esto.

El título de esta masterclass, como ya sabes, es Construye una aplicación de Headless WordPress con Next.js y WP GraphQL. Así que lo que haremos es, tengo algunas diapositivas para repasar. Compartiré mis diapositivas, me presentaré y luego repasaremos algunos temas, como qué es Headless WordPress, por qué podrías considerarlo.

Y después de pasar por esas diapositivas, luego nos sumergiremos en la parte práctica de la masterclass donde clonarás una aplicación de Next.js, la pondrás en funcionamiento en tu máquina local, y luego veremos cómo podemos conectarla a un backend de WordPress para que estemos obteniendo data de ese backend de WordPress a través de GraphQL, y luego lo usaremos para renderizar las páginas de nuestra aplicación de Next.js. Y recorreremos varios tipos de páginas y veremos cómo se construye cada una. Así que espero que realmente lo disfrutes y saques mucho provecho de ello.

De acuerdo. Así que construyamos una aplicación de Headless WordPress con Next.js y WP GraphQL. De acuerdo. Para empezar, me presentaré. Mi nombre es Kellan Mace. Trabajo en una empresa llamada WP Engine, que es una de las plataformas de alojamiento más populares en la web para sitios de WordPress, específicamente. Y es relevante para esta audiencia y esta charla el hecho de que WP Engine recientemente, lanzamos esta nueva plataforma de alojamiento llamada Atlas, que está orientada a sitios de WordPress headless incluso.

Entonces, con una sola cuenta y un solo proveedor de alojamiento, puedes alojar tanto el backend de WordPress como tu aplicación de JavaScript frontend en el mismo lugar, lo cual es bastante genial. Así que echa un vistazo a Atlas si te interesa. Mi nombre de usuario de Twitter también está aquí, si quieres ponerte en contacto conmigo después de la conferencia. Los mensajes directos están abiertos, así que por favor, si te adentras en esto y tienes algunas preguntas, por favor ponte en contacto y házmelo saber aquí. Así que con eso, nos sumergiremos.

Sé que empiezo con una especie de aclaración o llamado de atención, llamando la atención sobre las diferencias entre el WordPress tradicional y luego el Headless, y por qué podrías elegir uno u otro, como dije. Así que hagamos eso.

Oh sí, antes de hacer eso, solo una diapositiva aquí, y es clonar el repositorio de la aplicación. Quería poner esto justo en la parte superior de la presentación de diapositivas aquí, solo porque podría llevar un minuto dependiendo de tu conexión a internet. Pero para que clones este repositorio, y luego puedes seguir los pasos en el archivo readme allí. Te dirán que entres en el directorio de este proyecto y luego ejecutes npm install para instalar las dependencias, y así sucesivamente. Así que si lo haces ahora, eso te ahorrará un minuto una vez que llegues a la parte práctica más adelante. Entonces no tendrás que esperar a que se instalen las dependencias y demás. Así que adelante y toma ese enlace en la diapositiva de esta diapositiva. De acuerdo, con eso, hablemos de WordPress tradicional o monolítico. Como muchos de ustedes en la llamada probablemente ya saben, WordPress ha existido durante un tiempo. Somos el sistema de gestión de contenido más popular del mundo. En este momento, la estadística es bastante asombrosa. Es como si WordPress hubiera logrado aproximadamente el 43% de la cuota de mercado en Internet. Ese es el porcentaje de sitios en línea que utilizan eso, lo cual es simplemente alucinante de pensar.

En el WordPress tradicional, WordPress tiene muchas funciones, es responsable de proporcionar la interfaz de administración a la que acceden tus creadores de contenido, cuando crean, editan y gestionan su contenido, es responsable de guardar los datos en la base de datos. Y luego, cuando llegan solicitudes de, ya sabes, visitantes del sitio web, WordPress también es responsable de extraer los datos de la base de datos, y luego darles formato utilizando su API de temas, como HTML, y finalmente responder a esa solicitud. Así que tiene muchas funciones y hace muchas tareas. Y en muchos casos en la web, esta es una gran configuración y funciona muy bien.

Pero cada vez más personas eligen adoptar una arquitectura headless o desacoplada. Así que hablemos de eso a continuación. Así es como se ve algo así, donde todavía se utiliza WordPress. Puedes verlo a la izquierda de esta diapositiva aquí. Pero se utiliza realmente solo para proporcionar esa buena experiencia de administración a tus creadores de contenido y para almacenar los datos. Pero no maneja ningún renderizado, no devuelve, ya sabes, ningún HTML al visitante del sitio. En su lugar, tienes una aplicación frontend que hace eso y eso es Next.js en nuestro caso en la masterclass es lo que usaremos para eso. Así que tienes Next.js y se encarga de, ya sabes, consultar los datos de WordPress y utilizar eso para renderizar páginas HTML que se sirven a los visitantes del sitio. Y en el medio, tienes que tener algún tipo de capa de API. Así que necesitas alguna forma de que tu frontend de javascript y tu backend de WordPress se comuniquen entre sí.

Una forma de hacerlo es utilizar la API REST que viene integrada en WordPress nativo. Sin embargo, yo argumentaría que una mejor opción en estos días es WPGraphQL. Ese es el logotipo que ves aquí en la parte inferior. WPGraphQL es un complemento gratuito y de código abierto para WordPress que convierte cualquier sitio de WordPress en una API de GraphQL, lo cual es muy poderoso. Entonces obtienes todos los beneficios de GraphQL. En la arquitectura de la API REST, si quisieras consultar publicaciones de blog, usuarios, categorías y algo más, podrías tener que acceder a múltiples puntos finales de la API REST solo para agregar, ya sabes, para obtener todos los datos que necesitas, lo cual puede llevar tiempo y afectar el rendimiento. Pero con WPGraphQL, tienes los beneficios de GraphQL donde puedes ingresar a tu gráfico de datos de WordPress en cualquier punto y desde allí, consultar como quieras. Puedes decir, quiero las primeras 10 publicaciones de blog, y para cada una de ellas, quiero su nombre y otras publicaciones que hayan escrito. Y para cada una de ellas, quiero las categorías y componer estas consultas anidadas y obtener todos esos datos en una sola solicitud de red, lo cual es muy poderoso. Y tiene otros beneficios también, pero diría que ese es uno de los principales. Esto es cómo se ve una arquitectura desacoplada. Y esto es lo que realmente estaremos construyendo hoy. De acuerdo, la siguiente pregunta después de que hayas, ya sabes, escuchado hablar de tradicional versus desacoplado es, bueno, ¿por qué? ¿Por qué elegir uno u otro? ¿Cuáles son los beneficios, verdad? Así que cubramos eso a continuación muy rápido. Algunos de los beneficios de ir headless o para una arquitectura desacoplada serían estos. Tus creadores de contenido pueden seguir utilizando su CMS. Si hablas con muchos equipos de marketing de muchas empresas, realmente aman y conocen y, ya sabes, confían en WordPress, y quieren seguir utilizando eso como su CMS preferido. Así que pueden hacerlo con una configuración headless. Performance y escalabilidad, ya sabes, los frameworks como Next.js hacen que sea muy fácil tener un control muy detallado y decir, quiero que esta ruta sea completamente estática. Esta otra ruta sea renderizada en el servidor. Esta otra ruta, haré algo de renderizado en el lado del cliente. Tienes un control muy detallado sobre, ya sabes, el rendimiento y cómo se construye cada una de tus páginas, y también puede escalar muy bien. El tercer punto es un backend agnóstico de plataforma. Esto es algo interesante de pensar. Con un enfoque headless o desacoplado, tu backend de WordPress, solo sirve JSON puro. Eso significa que podrías tener un cliente web, como una aplicación de Next.js que obtiene ese JSON y lo renderiza para el cliente web. Pero si quisieras, también podrías construir una aplicación para iOS, una aplicación para Android, una aplicación de escritorio, y todas estas aplicaciones podrían obtener sus datos del mismo punto final de GraphQL, ya sabes, el mismo JSON que usa el cliente web. Otras plataformas también podrían usar y consumir. Así que eso lo hace bastante poderoso si tienes, ya sabes, múltiples plataformas que necesitas soportar. El siguiente es fácil de obtener datos de múltiples fuentes. Esto sería, por ejemplo, en el momento de la compilación cuando se están construyendo las páginas estáticas de tu sitio si quieres obtener algunos datos de WordPress, algunos datos de Salesforce, datos de la API de YouTube, algunos datos de Contentful o cualquier otra cosa. Lo hace... los frameworks modernos como NOCS lo hacen muy fácil de hacer, obtener datos de todas estas, ya sabes, fuentes, y luego unirlo todo en tus páginas HTML. El siguiente es una security mejorada. He visto arquitecturas de sitios donde hacen algo así como tener un frontend de JavaScript que sirve el sitio web a los visitantes del sitio, llamar al backend de WordPress, donde los creadores de contenido gestionan el contenido. Y luego ese backend de WordPress, lo bloquean para que solo ciertas direcciones IP puedan conectarse a esa instalación de WordPress e iniciar sesión para gestionar el contenido. Cualquier otra persona en todo Internet que intente, ya sabes, acceder al administrador de WordPress para intentar ingresar sería denegado. Dado que no tienen, ya sabes, una de esas direcciones IP permitidas, por ejemplo. En el WordPress tradicional, no se podía hacer eso porque todos necesitan poder acceder, ya sabes, a esa dirección web donde vive WordPress porque está haciendo todo el renderizado, ¿verdad? Tus visitantes del sitio necesitan visitar eso. Cuando tienes un enfoque desacoplado, eso ya no es necesario. Puedes hacer algunos trucos donde restringes el acceso al administrador de WordPress mientras permites que tus visitantes del sitio vean la aplicación frontend de JavaScript aquí. Y el último en esta lista es una mejor experiencia de desarrollo.

2. Headless WordPress: Beneficios y Desventajas

Short description:

Al utilizar un enfoque headless, puedes elegir un marco de trabajo front-end para construir componentes y tener una buena experiencia de desarrollo. Sin embargo, existen desventajas, como la complejidad adicional, la necesidad de recrear algunas funciones integradas de WordPress, la incapacidad de utilizar complementos de WordPress para elementos visuales y la incapacidad de utilizar las nuevas funciones de edición de sitio completo. Ahora vamos a sumergirnos en el contenido de la masterclass, comenzando con la parte de configuración. Exploraremos las páginas de la aplicación terminada, convertiremos WordPress en un servidor GraphQL, configuraremos el entorno de desarrollo local y configuraremos Apollo Client. Luego, pasaremos a la parte de construcción de características, donde cubriremos temas como componer una consulta GraphQL, implementar páginas específicas y aprovechar los fragmentos de GraphQL si el tiempo lo permite.

Yo diría, ya sabes, en estos días, muchos de nosotros en la comunidad de desarrollo web realmente apreciamos y nos gusta construir en una arquitectura basada en componentes. Entonces, dado que estás en la Cumbre de React, asumiré que te gusta React y te gusta construir en una arquitectura basada en componentes y entiendes todo eso, ¿verdad? Si optas por un enfoque headless, puedes elegir un marco de trabajo front-end para facilitar las cosas y luego construir en componentes y tener una experiencia de desarrollo realmente agradable, lo cual puede ser otra ventaja.

Bien, desventajas. Revisemos esta diapositiva y luego revisaré el chat aquí para ver si tenemos alguna pregunta. Una es la complejidad adicional. Entonces, tienes algunos elementos más en movimiento. En lugar de solo WordPress, ahora tienes el sitio de WordPress, que proporciona datos. Y luego tienes tu aplicación front-end, que consume esos datos. Así que tienes algunos elementos más en movimiento para gestionar.

Luego, otra desventaja sería que requiere recrear algunas funciones integradas de WordPress. Algunos ejemplos aquí serían la autenticación de usuarios y las vistas previas de publicaciones. En el WordPress tradicional, un creador de contenido puede crear un nuevo borrador de blog y una publicación, escribir un poco de contenido y luego hacer clic en un botón para previsualizar esa publicación y ver cómo se vería en el front-end si se publicara. Ese tipo de cosas no las obtienes de forma gratuita. Si separas tu front-end de tu back-end, ahora no tienes una forma de autenticar al usuario y saber si tienen permiso para ver un borrador no publicado de una publicación, por ejemplo. Algunas soluciones preconstruidas que las personas han creado en WordPress para agregar esa funcionalidad a Headless. Pero debes saber que no es algo que esté listo para usar, ya sabes, que debes pensar un poco en cómo voy a agregar esta función a mi arquitectura desacoplada.

La tercera aquí es que no puedes usar complementos de WordPress para agregar elementos visuales. A algunas personas les gusta tener un control total sobre su propio sitio web. Entonces, si construyes un sitio para, por ejemplo, una pequeña tienda local, y quieren poder administrar el sitio ellos mismos, es posible que deseen la capacidad de instalar un complemento de WordPress y agregar un carrusel de imágenes o algo así en el front-end del sitio, y eso ya no puedes hacerlo con un enfoque headless. No puedes simplemente activar un complemento que agregue elementos visuales a la página porque todos esos elementos visuales están controlados por tu aplicación JavaScript desacoplada, ¿verdad? Así que eso tiene sentido.

Esto puede no ser una desventaja, dependiendo de tu proyecto, ya sabes, muchas veces no quieres que el cliente mismo agregue todo tipo de elementos visuales a la página todo el tiempo y potencialmente afecte el rendimiento y ese tipo de cosas, por lo que esto también podría verse como una ventaja porque tienes las cosas más controladas y organizadas en cuanto a lo que se renderiza.

Y el último que tengo aquí es que no puedes utilizar las nuevas funciones de edición de sitio completo. WordPress 6.0 acaba de ser lanzado y tiene nuevas funciones de edición de sitio completo que están orientadas a esa persona que mencioné, donde el propietario del sitio web mismo quiere tener un control total sobre el sitio web y la capacidad de crear diseños por sí mismos utilizando una especie de experiencia de creación de páginas. Eso es lo que estas nuevas funciones de edición de sitio completo que vienen a WordPress, habilitan ese tipo de flujo de trabajo. Sin embargo, si optas por un enfoque headless o desacoplado, no podrás hacer eso porque, nuevamente, el renderizado está controlado por la aplicación front-end de JavaScript. Eso podría ser una desventaja para algunos proyectos, pero tener un control estricto sobre lo que se renderiza también podría ser una ventaja, como mencioné.

Bien, déjame hacer una pausa por un momento y abrir el chat para ver qué tenemos. Muy bien. Leyendo los comentarios aquí. Sí, definitivamente puedo poner el enlace de GitHub allí, así que déjame hacer esto. Ah, bien, así que he puesto el enlace al repositorio de GitHub en el chat. Sin embargo, no deberías necesitar ese enlace directo porque deberías poder abrir las diapositivas que compartí a las 10:05, mi hora, a las 10:05 en el chat. Pero copiaré ese enlace nuevamente también. El enlace a las diapositivas, ahí vamos. Así que he puesto el enlace a las diapositivas en el chat también si eso es útil para alguien. Veo, oh veo que algunos de ustedes también compartieron el enlace de GitHub, gracias por hacer eso. Me ahorraron el problema, de acuerdo. Continuemos con esto. Luego solo tengo un par más. Eso fue todo en las diapositivas en cuanto a cómo Headless WordPress es diferente de WordPress tradicional y luego los beneficios y desventajas, ahora continuaré con esta presentación. Lo siguiente después de los beneficios y desventajas aquí fue a codificar. En este punto, podemos sumergirnos en nuestra masterclass y hablar sobre lo que vamos a construir juntos hoy. Muy bien, esto es lo que cubriremos. Aquí está el contenido de la masterclass, lo llamo la parte de configuración. Entonces, lo que haremos es abrir nuestra aplicación terminada y ponerla en funcionamiento en un navegador. Y veremos tanto las páginas que tiene como el código que alimenta cada una de esas páginas. Así que, en primer lugar, haremos un recorrido por las páginas de nuestra aplicación terminada. En segundo lugar, veremos cómo podemos convertir WordPress en un servidor GraphQL con el complemento WP GraphQL. En tercer lugar, configuraremos el entorno de desarrollo local. Algunos de ustedes que clonaron el proyecto y siguieron los pasos en el archivo readme ya han hecho parte de ese trabajo, por lo que eso les ahorrará tiempo una vez que lleguen a ese paso. En cuarto lugar, configuraremos Apollo Client. Ese es el cliente GraphQL que utilizaremos en nuestra aplicación Next.js para obtener datos de nuestro backend de WordPress. Una vez que terminemos con esta parte de configuración, luego pasaremos a la parte de construcción de características. Así que cubriremos estas cosas aquí. Entonces, el quinto en la lista es componer una consulta GraphQL utilizando el IDE gráfico. Te mostraré cómo puedes hacer eso. Y luego, del seis al nueve, aquí se trata de implementar páginas específicas de nuestra aplicación. Tenemos la página de índice de blog o página de inicio del blog, tenemos la página de una sola publicación de blog. El número ocho, tenemos una página de categoría única. El número nueve será divertido, esa es nuestra página de búsqueda, donde en lugar de pre-renderizar una página estática de antemano, como podríamos hacer con algunas de estas otras páginas, la de búsqueda se renderizará sobre la marcha. A medida que el usuario escribe algo y presiona un botón, enviaremos una solicitud en tiempo real a nuestro backend para encontrar publicaciones de blog coincidentes y luego volveremos a renderizar la página para mostrar las publicaciones de blog coincidentes. Así que veremos cómo podemos hacer eso. Y luego el número diez, si tenemos tiempo, si llegamos a eso, veremos cómo aprovechar los fragmentos de GraphQL. De esta manera, podemos reducir el código repetitivo y tener partes de nuestras consultas de GraphQL desvinculadas de los componentes que realmente las utilizan. Con un fragmento de GraphQL, podemos tener un solo componente React y colocar los datos que necesita junto con el propio componente. Por lo que hace que tu base de código sea muy agradable y organizada. Veremos cómo podemos hacer eso si, nuevamente, si tenemos tiempo para llegar al paso nueve. Si no, sin embargo, si solo llegamos al paso nueve, creo que aún será muy beneficioso en una masterclass útil ver cómo construyes cada una de las páginas que cubriremos aquí. Muy bien, y después de eso, la última diapositiva de esta presentación son enlaces útiles. A medida que avanzamos en la masterclass, haré referencia a estas cosas. El número uno ya lo he mencionado, ¿verdad? Ese es el repositorio de la aplicación Next.js. Pero los números dos al siete aquí son cosas. A medida que avanzamos, solo haré referencia a los enlaces en esta página para que puedas hacer clic en ellos y abrirlos. Para sumergirnos en esto, lo primero que haremos es clonar ese repositorio, como dije. Entonces, con suerte, la mayoría de ustedes ya lo han hecho, pero si no, pueden hacer clic en el enlace para abrir este repositorio de código. Y solo necesitaremos seguir los pasos en este archivo readme aquí. Entonces, clonar el repositorio, ingresarás al directorio y ejecutarás npm install para instalar las dependencias. Y en realidad, el resto lo haré contigo aquí. Así que sumerjámonos. En la línea de comandos aquí, puedes ver que ya he clonado este proyecto yo mismo aquí en mi escritorio, y ahora ejecutaré npm install solo para asegurarme de que todas las dependencias del proyecto estén instaladas, ¿de acuerdo? Y una vez que estén, continuaremos con el resto de los pasos aquí. Simplemente dice, crea un nuevo archivo .env.local en la carpeta raíz con esto como su contenido. Muy bien, hagamos eso. Así que abramos nuestro proyecto en una ventana de VS Code. Permíteme redimensionar esto para nosotros. Ahí vamos, bien. Siguiendo las instrucciones aquí, haré clic derecho aquí y simplemente iré a nuevo archivo. Lo llamaré .env.local. Y dentro de esto, vamos a poner una variable de entorno. Copiaré esto aquí y luego lo pegaré en este archivo.

3. Recorrido de la Aplicación Terminada y Página de Blog

Short description:

El punto final de GraphQL es utilizado por nuestra aplicación Next.js para obtener datos de un sitio de backend de WordPress. Si ya utilizas WordPress, puedes obtener datos de tu propio sitio apuntando la aplicación Next.js a una instalación local de WordPress. Asegúrate de tener WP GraphQL instalado y activado si eliges esta opción. Para ejecutar la aplicación localmente, utiliza npm run dev y abre localhost:3000. Puedes alojar el frontend y el backend de WordPress en hosts diferentes, como Atlas de WP Engine, Netlify, Vercel u otros proveedores. Realiza un recorrido por la aplicación terminada, comenzando por la página de inicio y la página de blog, que muestra una cuadrícula de publicaciones de blog enlazadas. La página de blog utiliza datos ficticios, pero los reemplazaremos con datos reales de un backend de WordPress. La página de publicación de blog obtiene las publicaciones de un archivo de datos ficticios y las renderiza utilizando componentes como lista de publicaciones y tarjeta de publicación. Nuestra tarea es obtener datos reales de un backend de WordPress y utilizarlos para renderizar la lista de publicaciones. Continuemos con un recorrido por la página de una sola publicación de blog.

Entonces, esto apunta al punto final de GraphQL que nuestra aplicación Next.js utilizará cuando obtenga datos de un sitio de backend de WordPress. Hablaremos más sobre eso en un momento. Aquí hay una alternativa si ya utilizas WordPress y quieres obtener datos de tu propio sitio, puedes hacerlo. Si dice que quieres apuntar la aplicación Next.js a una instalación local de WordPress, reemplaza eso con el dominio de tu sitio local de WordPress. Puedes hacer eso ahora o más tarde, si quieres probar cómo se ve obtener datos de un sitio de WordPress diferente. Esto es lo único que necesitarías cambiar aquí.

Si decides utilizar una instalación local de WordPress, asegúrate de tener WP GraphQL instalado y activado. Luego, ejecuta npm run dev para ejecutar la aplicación en localhost:3000. Puedes detenerla en cualquier momento presionando Control + C. Bien, veamos cómo podemos hacer eso. En la línea de comandos, ejecutaré npm run dev, ahí está. Luego, simplemente haré clic en este enlace aquí para abrir localhost:3000. Veremos nuestra aplicación en todo su esplendor. Aquí está, la aplicación WP sin cabeza. Bien, esto es lo que exploraremos aquí. Volvamos a nuestra secuencia de eventos.

De acuerdo, lo primero que haremos ahora es el recorrido de nuestra aplicación terminada. Veamos el chat aquí. Muy bien. Entonces, Kyle, veo tu pregunta aquí. ¿Hay un socio de alojamiento preferido con esta arquitectura o puedes elegir, por ejemplo, AWS? Sí, gran pregunta. Hay muchas opciones disponibles. Algunas aplicaciones populares para alojar el frontend, bueno, déjame retroceder un momento, hay dos opciones. Una es que necesitas alojar tu aplicación JavaScript basada en Node.js, ya sabes, tu frontend. Necesitas alojar eso en algún lugar, pero también necesitas alojar el sitio de WordPress en otro lugar. Pueden ser el mismo host o pueden ser hosts diferentes.

Mencioné al comienzo de la presentación que mi empresa, WP Engine, tiene un producto llamado Atlas. Si utilizas Atlas, te permite alojar y administrar ambos desde un solo panel de control. Entonces, lo que puedes hacer es crear un nuevo entorno de aplicación Atlas y llamarlo entorno de aplicación de producción y decir, para mi aplicación frontend, aquí está el repositorio. Y para mi backend de WordPress, quiero crear uno nuevo en tu plataforma de WP Engine y luego hacer clic en un botón y creará ambos. El frontend y el backend, que se apuntan entre sí y utilizan GraphQL como la capa de datos. Y puedes administrar ambos desde un solo panel de control, lo cual es bastante bueno. Somos el único host que conozco que aloja ambos. De lo contrario, si no quieres usar Atlas, hay otros proveedores disponibles. Netlify y Vercel, render.com son algunos de los más populares para alojar tu aplicación frontend JavaScript. Y luego, para el backend de WordPress, como dijiste, puedes alojarlo en AWS o en Digital Ocean o Linode u otros proveedores de alojamiento administrado en el espacio de WordPress, como SiteGround o Bluehost, entre otros. También puedes hacer eso. Entonces, podrías tener la aplicación frontend en Netlify o Vercel y luego tu aplicación backend en Digital Ocean o AWS o cualquier otro lugar. Siempre que los configures para que se apunten entre sí, como estamos haciendo aquí, donde especificas el punto final de GraphQL donde se encuentra tu WordPress, esa sería otra opción para ti. Veamos, Alex. Sí, tienes razón. Incluso podrías alojar el frontend en AWS también. Sí, si eres alguien muy técnico y sabes cómo alojar aplicaciones Node.js en AWS, ciertamente también podrías hacer eso. Puedes alojar la aplicación frontend en AWS también. Es cierto. Excelentes preguntas. Muy bien, sigamos adelante. El siguiente paso es un recorrido por nuestra aplicación terminada. Veamos cómo está construida aquí. Con la aplicación que les di de antemano, no hice mucho. Simplemente agregué algunas páginas y componentes que recorreremos aquí. Comencemos con esta página de inicio aquí. Si todos ustedes han utilizado Next.js, probablemente reconozcan que es simplemente la pantalla de bienvenida que utiliza el framework. Pero vayamos a la página de blog y veamos cómo se ve. Verán que tenemos esta página de blog y tiene una cuadrícula de publicaciones de blog enlazadas. Veamos cómo funciona eso. Y tal vez en el chat, ¿puedo obtener un pulgar hacia arriba si pueden cargar la página /blog y esto es lo que ven? ¿Se ve bien? Mientras hacemos eso, profundicemos en ello.

Abriré la carpeta de páginas en el editor de código y luego iré a blog aquí, y así es como se ve esa página. Genial, gracias por el pulgar hacia arriba. Muy bien, aquí está la página de blog. Puedes ver que en este momento estamos haciendo trampa. Ninguno de estos datos es real, son datos ficticios. Lo que estamos haciendo en este archivo es que tenemos este directorio aquí llamado datos ficticios con un archivo de índice dentro. Puedes ver que tiene un montón de datos de publicaciones codificados aquí. Así que imita la estructura de los datos. Volveremos a esto más adelante cuando hagamos consultas reales de GraphQL, pero por ahora, esto es solo datos ficticios codificados. Entonces, lo que hace nuestra página de blog es extraer las publicaciones de ese archivo de datos ficticios y en lugar de getStaticProps, le decimos a Next.js: `oye, en el momento de la construcción de esta página, envía una propiedad al componente llamada publicaciones y aquí es donde debes obtener los datos de estas publicaciones que importamos de nuestros datos ficticios`. Y si miras el componente aquí, eso es exactamente lo que hace, ¿verdad? Recibe las propiedades, desestructura eso para extraer las publicaciones, luego renderiza este componente de lista de publicaciones y ese es el responsable de mostrar nuestras publicaciones en una lista aquí. Haré clic en ese para que podamos verlo. Entonces, la lista de publicaciones es bastante simple, es solo una lista desordenada aquí y luego mapeamos cada una de las publicaciones y, ya sabes, colocamos una de cada una de ellas en un LI con una tarjeta de publicación dentro. Y haré clic en la tarjeta de publicación y también es bastante simple. ¿Verdad? Simplemente desestructura las propiedades de las publicaciones que recibe para extraer el título, el extracto, el URI, la imagen destacada y luego tiene una etiqueta de artículo y muestra parte del contenido de esa publicación de blog de esa manera. Así es como se escribe la publicación de blog aquí. Muy bien. Nuestra tarea es eliminar estos datos ficticios aquí y obtener datos reales de un backend de WordPress y luego utilizar esos datos reales para renderizar la lista de publicaciones. Por lo tanto, veremos cómo cambian en lugar de los títulos en latín aquí. Verás que esta página se vuelve a renderizar una vez que lo hagamos, con los datos reales de las publicaciones de blog de nuestro backend de WordPress. Será genial ponerlo en funcionamiento. Muy bien. Hemos visto la página de blog. Ahora hagamos un recorrido rápido por la página de una sola publicación de blog. Haré clic en una de ellas y veremos una página individual de una publicación de blog aquí. Nuestra aplicación frontend estaría dentro de la carpeta de páginas. Iré a este URI de puntos suspensivos.

4. Explorando las Páginas de Búsqueda y Publicación de Blog Individual

Short description:

En esta parte, exploraremos la página de búsqueda y la página de publicación de blog individual. La página de búsqueda está actualmente rota ya que depende de datos ficticios. Discutiremos cómo manejar la protección contra XSS al renderizar contenido HTML de un CMS como WordPress. React escapa HTML por sí mismo, pero hay consideraciones al tratar con un CMS. Explicaremos las opciones para manejar el contenido HTML, como usar dangerously set inner HTML o usar una biblioteca como HTML React Parser.

Aquí está el archivo js también. Si no estás seguro de qué es esto, como por qué están aquí los corchetes con los puntos suspensivos, esto es solo una convención de Next.js. En nuestras diapositivas, en la página de enlaces, puedes ver su documentación. Por ejemplo, el número seis aquí, si te preguntas por qué creamos ese archivo .env.local y dije que estábamos almacenando una variable de entorno en él, si te preguntas de dónde viene eso, por qué lo estamos haciendo, aquí está la respuesta. El número seis te muestra en la documentación de Next cómo crear variables de entorno. Del mismo modo, si te preguntas cómo funciona el enrutamiento basado en archivos aquí, como con esta ruta de captura de todo, puedes consultar la documentación de Next.js para ver cómo funciona todo eso. Básicamente, esto es solo una ruta de captura de todo que le dice a Next.js que cualquier cosa que no coincida con una de las otras, como /blog o /search. Si es algo más, úsalo como una especie de captura todo para renderizar nuestras otras páginas. Lo estamos usando nosotros mismos para renderizar nuestra página de publicación individual. Entonces, en nuestra aplicación frontend, lo que hace es muy similar a la página anterior. Puedes ver que estamos importando la publicación desde nuestros datos ficticios. Y luego, más abajo, dentro de getStaticProps, pasamos esa publicación individual como las props que nuestro componente debe recibir. Y dentro de un componente, desestructuramos la publicación para extraer la fecha, el título, el contenido, el autor, y así sucesivamente. Y luego lo usamos para renderizar nuestra lista aquí. Con el componente de diseño, que simplemente le da a la página un poco de margen y relleno y un ancho máximo, y así sucesivamente. Y dentro de eso, deberíamos tener una etiqueta de artículo con todo esto. Entonces puedes ver que, ya sabes, aquí está el título de la publicación del blog. Aquí está, ya sabes, el nombre del autor, y luego una fecha formateada que dice de dónde obtenemos esta información meta. Debajo de eso, tenemos el contenido de las publicaciones del blog. Ya sabes, todo este HTML se renderiza. Y luego, en la parte inferior, decimos que si tenemos categorías, luego mostramos una categoría como encabezado. Permíteme desplazarme hacia abajo aquí, categorías como, y luego, ya sabes, mapeamos cada una de las categorías y simplemente las mostramos en la lista. Así es como se escribe la página de publicación individual del blog. Muy bien. Nuestra tarea es eliminar estos datos ficticios aquí y obtener datos reales de un backend de WordPress y luego utilizar esos datos reales para renderizar la lista de publicaciones. Por lo tanto, veremos cómo cambian en lugar de los títulos en latín aquí. Verás que esta página se vuelve a renderizar una vez que lo hagamos, con los datos reales de las publicaciones de blog de nuestro backend de WordPress. Será genial ponerlo en funcionamiento. Muy bien. Hemos visto la página de blog. Ahora hagamos un recorrido rápido por la página de búsqueda. Eso podría ser interesante. Aquí está la búsqueda y está rota. Puedes notar que esto no funciona en absoluto. ¿Verdad? Y nuevamente, eso se debe a que todo esto son solo datos ficticios. Si ahora escribo la palabra, por ejemplo, puedo hacer clic en buscar y enviar este formulario todo el día. Pero mis datos, ya sabes, no van a cambiar. Y eso se debe a que todo esto son solo datos ficticios en este momento. Si abrimos nuestra página de búsqueda, nuevamente estamos extrayendo publicaciones de nuestros datos ficticios. Y, sí, y luego usándolos. Entonces, dentro de este objeto de datos que estamos construyendo, pasamos las publicaciones y más abajo, tenemos nuestro formulario en la parte superior aquí para que la persona escriba el término de búsqueda, ya sabes, que desea buscar. Y luego, debajo de eso, estamos representando cosas. Entonces, en este momento está roto porque renderizamos nuestra lista de publicaciones. Y luego le damos a data.post.nodes. Ya sabes, que en última instancia provino de nuestro archivo de datos ficticios. Entonces, ahí es donde, por eso, todo esto son solo datos ficticios. Una vez que terminemos con este archivo, funcionará como se espera. Por lo tanto, podrás escribir una palabra específica dentro de una o más publicaciones de blog. Ya sabes, aquí haz clic en buscar y enviará una solicitud desde el cliente al backend de WordPress y luego volverá a renderizar la lista para mostrar las coincidencias aquí. Eso es todo para el recorrido. Hay una página de categoría que no vimos, pero podemos dejar eso para más tarde. Está aquí si haces clic en una sola categoría. También tenemos esta página donde muestra solo el título de esa categoría en la que estás interesado y luego las publicaciones de blog que están asignadas a esa categoría. También construiremos esa. Muy bien. Sí, con eso, haré una pausa, revisaré el chat ahora mismo. Acabo de ver un montón de pulgares arriba, así que debo estar haciendo un trabajo fantástico, pero por favor avísame, como dije, si algo necesita más explicación. Veamos. Muy bien, Alex, es una buena pregunta. Alex pregunta dónde se maneja la protección XSS. XSS es scripting entre sitios. Entonces, esa es una buena pregunta. React escapa HTML por sí solo. Entonces, cuando vas a renderizar algo con React, si la cadena contiene ciertos caracteres HTML o ciertos caracteres HTML donde podría ocurrir un ataque de scripting entre sitios, donde algún JavaScript malicioso se está ejecutando en la página, como una extensión de Chrome o algo así. Si esa extensión de Chrome está tratando de inyectar contenido en la página y hay algunos caracteres no escapados, React se encarga de eso. Sin embargo, cuando estás tratando con un CMS, a veces hay otras consideraciones que debes tener en cuenta. Debes decirle a React que confíe en cierto contenido, si eso tiene sentido. Entonces, ya que estamos en ese tema, solo me detendré en esto por un segundo aquí. Un ejemplo sería el contenido. Entonces, en nuestra página de publicación individual del blog aquí, te mencioné que todo este HTML para el contenido proviene de WordPress. Entonces, si no confiamos en estos datos, si queremos darle estos datos a React, intentaría escaparlo como siempre hace. Permíteme mostrarte cómo se ve eso. Entonces, si simplemente pasamos el contenido de esta manera, permíteme guardar eso. Veamos si podemos hacer que se vuelva a renderizar. Deberíamos ver un montón de etiquetas HTML. Sí, así es como se vería tu sitio, ¿verdad? Porque este es el contenido HTML que compone esa publicación del blog. Entonces, esto es lo que se vería si permites que React haga su escapado como siempre hace, escaparía todo este HTML aquí. Entonces, debes decidir por ti mismo, ya sabes, ¿confío en este HTML que proviene de mi CMS? Y espero que sí, WordPress es utilizado por millones de personas y tiene muchos ojos en términos de seguridad. Así que diría que se puede confiar en que produzca HTML si es seguro. Entonces, tienes algunas opciones. Y si decides confiar en el contenido HTML y le dices a React que no lo escape, en la página tienes algunas opciones. Una sería usar dangerously set inner HTML. Estoy seguro de que algunos de ustedes han visto esto antes. Entonces, React, sí, si haces esto, si tienes un div de autocierre como este y dices dangerously set inner HTML, y dentro de esto, pasas un objeto con una clave de doble guion bajo HTML, dos puntos, y el valor de ese HTML, en nuestro caso, eso es contenido, así, esta sería una forma de manejarlo. Entonces, esto le dice a React que no intente escapar este HTML para la protección contra scripting entre sitios, por ejemplo. Entonces, si guardo eso y luego lo miro, ahora puedes ver que React está omitiendo ese escapado y está representando la marca que se le dio. Entonces, esta es una forma de hacerlo. En nuestra aplicación, dejé que una biblioteca lo hiciera. Tengo este analizador de HTML React aquí, que viene con una función de análisis. Entonces, esta es otra forma de hacerlo. En lugar de hacerlo tú mismo con el div de autocierre, en nuestra aplicación, simplemente estaba pasando el contenido a través de la función de análisis que este analizador de HTML basado en React usa para escaparlo. Muy bien. Entonces, Alex, avísame si eso respondió a tu pregunta. Entonces, sí, WordPress realiza su propio escapado del HTML que produce. En la aplicación frontend, debes decirle a React, oye, esta cadena que estoy a punto de poner en la página, ya está escapada en HTML, confío en ella.

5. Convirtiendo WordPress en un Servidor GraphQL

Short description:

Para convertir WordPress en un servidor GraphQL, habilita el complemento WPGraphQL. Proporciona un punto final GraphQL al que puede acceder tu frontend desacoplado. El punto final GraphQL se puede personalizar, pero la convención es usar '/graphql'. WPGraphQL puede aprovechar soluciones de almacenamiento en caché existentes como Redis o memcached para acelerar las respuestas de GraphQL. Se está desarrollando una función llamada consultas persistentes, que permitirá almacenar en caché las respuestas en un CDN.

Entonces, no intentes escaparlo y simplemente renderízalo. Muy bien, genial. Sí, excelente pregunta ahí.

Muy bien, sigamos adelante entonces. Acabamos de terminar nuestro recorrido de la aplicación terminada, ¿verdad? Ahora profundicemos más. El siguiente paso en nuestra lista de cosas por cubrir es convertir WordPress en un servidor GraphQL con WPGraphQL. Les mostraré cómo hacerlo. Pero en realidad no necesitarás ejecutar un sitio de WordPress tú mismo en tu máquina. En su lugar, simplemente nos conectaremos a un sitio de WordPress que está en vivo en Internet.

Entonces, aquí estoy usando una aplicación gratuita llamada Local para ejecutar sitios de WordPress localmente en mi máquina, y simplemente iniciaré uno de estos sitios y luego iré a la pantalla de administración de WordPress. Permíteme iniciar sesión en este sitio y simplemente mostrarte algunas cosas. Muy bien, aquí estamos en el administrador de WordPress. La forma de convertir tu backend de WordPress en una API GraphQL es habilitando el complemento WPGraphQL que mencioné. Así es, aquí está. Si no lo tienes en tu sitio, simplemente haz clic en 'Agregar nuevo' aquí y busca en el directorio de complementos de WordPress WPGraphQL y luego encuéntralo en la lista. Ahí está, WPGraphQL. Lo instalarías y luego lo activarías y lo verías en tu lista de complementos aquí, ¿de acuerdo?

Una vez que hayas hecho eso, eso le dará a tu sitio un punto final GraphQL al que tu frontend desacoplado puede acceder. Entonces, si te preguntas, bueno, ¿dónde está ese punto final GraphQL, verdad? Lo que puedes hacer es en la barra lateral aquí, puedes ir a GraphQL y luego en la página de configuración, justo en la parte superior, te muestra cuál es el punto final GraphQL. Puedes personalizarlo, pero la convención es simplemente usar '/graphql' aquí. Una nota también, cualquier persona que esté tomando notas y quiera hacer esto en su propio sitio de WordPress, una cosa que me aseguraría de hacer en esta página es en tu entorno local, habilitar el modo de depuración de GraphQL aquí. Esto es de gran ayuda cuando en tu aplicación frontend, si algunas consultas que estás intentando enviar fallan, en lugar de recibir mensajes de depuración muy opacos e inútiles, si habilitas esto, recibirás mensajes de depuración mucho más útiles. Así que solo una nota si estás ejecutando un sitio de WordPress y haciendo este tipo de cosas, definitivamente habilita el modo de depuración y te ayudará en tu entorno local.

Entonces, veamos este punto final. Voy a hacer clic en él mientras mantengo presionada la tecla de comando para abrirlo en una nueva pestaña. Verás que solo obtengo una respuesta JSON si intento visitarlo directamente en un navegador web, simplemente dice que las solicitudes GraphQL deben incluir al menos uno de estos parámetros, consulta o ID de consulta o lo que sea. Y eso se debe a que no he proporcionado una consulta, ¿verdad? Todo lo que hice fue enviar una solicitud GET en un navegador a este punto final, no proporcioné ningún dato. Así que esa es la salida esperada allí. Muy bien, así es como lo harías en tu propio sitio de WordPress. Sin embargo, para nosotros, vamos a usar un punto final GraphQL predefinido. Así que vamos a ver, voy a cerrar estas cosas, no necesitamos ver eso más. En cambio, vamos a usar este punto final aquí, así que este sería el número cinco en la lista de enlaces. Si lo abres en una nueva pestaña. Oh, ahí vamos. Así que eso te llevará a este contenido, .wpgraphql.com/graphql. Así que este es el punto final que vamos a usar para que no tengas que preocuparte por ejecutar tu propio sitio de WordPress localmente. Y si te fijas, es el mismo que hemos agregado a nuestro archivo .env.local aquí. De ahí viene esto. Así que vamos a usar esto para el resto de la masterclass como el sitio del que obtendremos nuestros datos de WordPress. Muy bien.

Eso fue el número dos, cómo convertir WordPress en un servidor GraphQL con el complemento WPGraphQL. Así que haré una pausa aquí y revisaré el chat para ver si hay alguna pregunta. Veamos. Entonces, ¿es más seguro evitar dangerously set innerHTML y en su lugar usar una biblioteca de análisis? En la mayoría de los casos, no. Si observas algunas bibliotecas populares de análisis que existen, incluida la que estamos usando en este proyecto, en realidad usan dangerously set innerHTML. Entonces, si observas el código fuente de esas bibliotecas, podrían intentar renderizarlo de otra manera dependiendo de cómo se vea el HTML, pero como último recurso o alternativa para renderizar el contenido, ellos mismos usarían dangerously set innerHTML para lograr lo mismo. Entonces, no, no diría que es más o menos seguro. Un analizador puede ser útil si quieres intercambiar cosas. Permíteme mostrarte un pequeño desvío aquí. Mantengo este sitio con mi equipo en el trabajo, developers.wpengine.com. Solíamos tener muchos recursos, artículos, videos y todo tipo de cosas sobre cómo hacer esto, cómo usar WordPress sin cabeza. Así que uno de los artículos que escribí recientemente trata sobre cómo trabajar con los datos de Gutenberg y se refiere un poco a esta pregunta que estamos discutiendo ahora mismo. Así que este es un blog que escribí, Gutenberg y WordPress sin cabeza: renderizar bloques como HTML. Así que si abro esta página del blog, te mostraré uno. Oh sí, nuestra resaltado de sintaxis está roto en este momento. Este es un mal demo, lo siento. Pero de todos modos, esta es la sección a la que me refería. Usa un analizador para convertir algunos bloques en componentes. Esto es algo que podría interesarte. Entonces, por ejemplo, en Next.js, ya sabes, quieres usar el componente de enlace de Next.js para obtener la navegación del lado del cliente para cualquier enlace interno, pero de forma predeterminada, lo que WordPress te dará, si tienes algún enlace interno dentro de tu contenido, simplemente te dará una etiqueta de anclaje regular. Entonces, el resultado es que en tu aplicación frontend, si alguien está leyendo una publicación de blog y luego hace clic en algo que es un enlace interno, si eso es solo una etiqueta de anclaje, obtendrán una recarga completa de la página, ¿verdad? Seguirá funcionando, los llevará a la siguiente página, pero se pierde el propósito de usar un marco de aplicación de una sola página como Next.js. Eso es capaz de hacer la navegación del lado del cliente muy rápida. Entonces, en esta publicación de blog, explico cómo reemplazar, ya sabes, esas etiquetas de anclaje por tus enlaces internos, cómo reemplazarlos por un componente de enlace, para obtener una navegación rápida y fluida del lado del cliente. Ese sería un ejemplo de cuándo querrías usar un analizador más allá de simplemente escapar HTML como estamos haciendo aquí. Pondré este blog en el chat en caso de que alguno de ustedes esté interesado en lo que estoy hablando. Esta publicación puede ser útil. Sí, también pondré este sitio allí en caso de que estén interesados en cualquiera de nuestros videos de demostración, etc. Muy bien, excelentes preguntas. Veamos. Entonces, M tiene otra pregunta. ¿Este punto final almacena en caché las consultas? Esta también es una excelente pregunta. wp-graphql que estamos usando aquí, esto es lo que estamos usando para nuestra capa de API, ¿verdad? Para permitir que WordPress se comunique de ida y vuelta a través de nuestro frontend desacoplado. Puede aprovechar cualquier solución de almacenamiento en caché existente que puedas usar en el backend de WordPress, como Redis o memcached. Si se utiliza alguno de ellos, como una caché de objetos, wp-graphql también verá ganancias de velocidad. Entonces, si tienes una consulta específica que, cada usuario que visita una determinada página de tu sitio, si tienes una consulta específica que siempre se ejecuta, lo que haría Redis es ver esa consulta a la base de datos y luego la almacenaría en caché en la memoria para que la próxima vez que llegue una solicitud, sirva, ya sabes, la respuesta desde la memoria. Entonces, sería mucho, mucho más rápido. Sí, puedes usar soluciones de almacenamiento en caché existentes como Redis o memcached, esas funcionarían para almacenar en caché y acelerar tus respuestas de GraphQL. Pero iré un paso más allá. Una cosa realmente emocionante es que Jason Ball, el creador y mantenedor de wp-graphql, y otro tipo, Mark, están trabajando en una función llamada consultas persistentes para wp-graphql en este momento. Y esto llevará la historia de la caché al siguiente nivel. Esto se ve así: llega una solicitud para una consulta y luego, después de que se resuelve, se guarda en algún tipo de caché, podría ser una caché en memoria como Redis o memcached, pero más allá de eso, la respuesta JSON se almacena, se puede almacenar en un CDN. Entonces eso significa que podrías distribuir, ya sabes, las respuestas a tus consultas de GraphQL, podrías distribuirlas por todo el mundo en centros de datos utilizando un CDN. Entonces eso significa que algún usuario que esté en Tokio, Japón o algo así, si está tratando de visitar tu sitio y enviar una consulta de GraphQL, esa consulta llegaría a su centro de datos local dentro de Japón, vería que, oh, tenemos una respuesta en caché para esta consulta que aún es válida y la devolvería de inmediato. Entonces, este viaje de ida y vuelta, ir al servidor de origen ni siquiera sería necesario. Simplemente serviría las respuestas directamente desde el centro de datos CDN más cercano. Eso es hacia donde se dirige WP GraphQL, lo cual es muy emocionante para mí. Esto sería similar a otras soluciones, como GraphCDN, que es un producto popular que hace este tipo de cosas, donde toma las respuestas de GraphQL y las almacena en caché en todo el mundo en un CDN. Pero muy pronto WP GraphQL tendrá soporte nativo para eso, para ese tipo de consultas persistentes.

6. Configuración de Apollo Client y Puntos de control

Short description:

Hemos cubierto los pasos de configuración, incluyendo convertir WordPress en un servidor GraphQL utilizando el complemento WP GraphQL y configurar el desarrollo local. Los puntos de control están disponibles en caso de que te quedes atrás. Recomendamos usar Apollo Client para un proyecto del mundo real para habilitar el almacenamiento en caché en memoria de las consultas en el cliente. La configuración de Apollo Client implica instalar los paquetes necesarios, inicializar el cliente con la URI del backend de GraphQL y el tipo de caché, y conectar el cliente a React utilizando Apollo Provider. TypeScript no es necesario para este proyecto simple, pero puede ser beneficioso para proyectos más grandes y complejos.

Estoy muy emocionado por eso. Esto llevará el juego de almacenamiento en caché al siguiente nivel. Mantente atento si estás interesado, puedes seguir el blog aquí o seguir la cuenta de Twitter para obtener actualizaciones. Muy bien, creo que eso es todo por las preguntas, así que sigamos adelante con la masterclass. Estas son preguntas excelentes, muchas gracias. Avísame si tienes más. Muy bien, ¿qué hemos hecho? Hicimos un recorrido por nuestra aplicación. Vimos cómo puedes convertir WordPress en un servidor GraphQL utilizando el complemento WP GraphQL, luego configuramos Git para el desarrollo local. Algunos de estos pasos ya los hemos realizado, serían estos pasos aquí en el archivo readme, así que ya los hemos revisado. Sí, estamos bien allí. Sin embargo, mencionaré una cosa más, los puntos de control. Esto es muy importante para nuestra masterclass. Permíteme ampliar un poco el texto. Esto dice que puedes revisar estos commits en Git para ponerte al día si te quedas atrás en cualquier momento. Muy bien, a medida que nos adentramos en el código y realmente trabajas en el teclado, realizando estas actualizaciones en el sitio, intentando que las cosas funcionen, si te quedas atrás en algún momento y el grupo ya ha terminado de implementar una página y estamos listos para pasar a la siguiente y sientes que te estás quedando atrás, no es un problema en absoluto. Lo que puedes hacer es ejecutar en la línea de comandos, ejecutar Git checkout y luego simplemente pegar este hash de commit aquí y eso te pondrá al día. El primer commit aquí sería, y solo recuerda que este es el commit después de crear la página de índice del blog, este es el commit después de crear la página de publicación de blog individual, y así sucesivamente. Entonces, si en algún momento sientes que te estás quedando atrás, no te preocupes en absoluto, simplemente ve y revisa este commit y eso te pondrá al día con el resto del grupo. Muy bien, pero si todos siguieron los pasos, tienes tu archivo env.local allí y ejecutaste npm run dev, deberías estar en el mismo punto en el que estoy aquí, mirando la aplicación frontend. ¿Alguien en el chat puede darme un pulgar hacia abajo o algo así si está roto y no pudiste iniciar esta aplicación? Avísame, estaré atento a eso. Muy bien, creo que estamos configurados para el desarrollo local aquí. El siguiente paso es Configurar Apollo Client. Entonces, si estás haciendo esto en un proyecto del mundo real, mi recomendación sería usar algún tipo de cliente GraphQL en tu aplicación JavaScript. Eso hace que, alguien hizo la pregunta anterior sobre el almacenamiento en caché, y la respuesta que di fue sobre cómo almacenar en caché las respuestas que regresan del servidor. Sin embargo, Apollo Client hará un tipo diferente de almacenamiento en caché, que es el almacenamiento en caché en memoria de las consultas en el cliente. Entonces, eso significa que si alguien está en una determinada página y se envía una consulta y se recibe una respuesta, digamos que navegan lejos de esa página a una página diferente y luego regresan a esa página, ¿verdad? Lo que Apollo hará es ver que se necesita algún dato y luego verificará su propia caché y dirá: `Oh, ¿hemos obtenido este mismo dato antes?` Si es así, simplemente lo obtendrá inmediatamente de la caché y renderizará ese componente, pero si no, en realidad haría una solicitud a la red para obtener los datos. Entonces, eso es genial, ya que el cliente navega por el sitio, Apollo simplemente obtendrá las cosas de su caché si ya ha obtenido esos datos antes y solo se tomará el tiempo para hacer la solicitud si nunca ha obtenido los datos antes o si es demasiado antiguo, ya sabes, la caché no es válida o cualquier otra cosa. Entonces, el almacenamiento en caché es una gran característica, pero hay otras razones por las que podrías querer usar un cliente como Apollo. Pasaremos por cómo configurarlo. Este sería el siguiente paso para crear un sitio de WordPress sin cabeza. En nuestra página de enlaces aquí, si abres el número cuatro, están los documentos de inicio de Apollo Client. Realmente solo hay unos pocos pasos para esto, pero te mostraré qué necesitarías hacer aquí. Muy bien, esta página dice, Comienza con Apollo Client. Y te dice que necesitas instalar algunos paquetes. Entonces, necesitas hacer npm install, Apollo Client y luego GraphQL. Ya hemos hecho eso en nuestro proyecto aquí, pero si no lo hubieras hecho, necesitarías instalarlos. El siguiente paso es inicializar Apollo Client. Entonces, necesitas un código que se vea así. Permíteme ampliar esto de nuevo, ahí vamos. Necesitas llamar a new Apollo Client para instanciar un nuevo cliente y luego darle algunos datos. Le dices, aquí está la URI para el backend de GraphQL que quiero usar para obtener mis datos, y aquí está el tipo de caché que quiero usar. Aquí estamos diciendo que almacene las respuestas en memoria. Entonces, esto también lo hemos configurado en nuestra aplicación. Te mostraré dónde se hizo eso. Si vas al archivo _app.js en nuestra base de código, aquí es donde vive el proveedor. Veamos, supongo que sí, deberíamos abrir este. Muy bien, dentro de lib, y luego Apollo client, lo que hice fue simplemente crear este archivo ApolloClient.js y simplemente pegué esto aquí y dije, hice lo mismo, así que estoy diciendo que queremos instanciar Apollo Client. Usaremos la caché en memoria que viene con Apollo, pero para la URI, puedes ver que la estoy obteniendo de nuestra URL de API pública de WordPress siguiente. Entonces, lo que esto hace es decirle a Next.js que lo obtenga de nuestro archivo de variables de entorno. Recuerda cuando creamos .env.local, especificamos esta URL de API pública de WordPress siguiente. Y luego le dimos algo allí dentro de este archivo, simplemente estamos extrayendo ese valor. Entonces esto te permite tenerlo dinámico. Entonces, lo que podrías hacer es, en tu entorno local, podrías tenerlo configurado para un punto final, o tal vez en el entorno de preparación, si tienes un sitio de preparación, podrías configurarlo con el punto final de GraphQL de tu sitio de preparación. Entonces eso es lo que usaría. Pero luego, en tu entorno de producción, haría referencia al punto final de GraphQL de tu sitio de producción, por ejemplo. Y eso es lo que significa usar esto en tu código, por qué es útil, porque dependiendo del entorno, puedes obtener un backend de WordPress diferente. Entonces, esa es la configuración que recomendaría allí. Entonces, después de crear ese archivo y simplemente exportar ese cliente que creamos, tenemos que usarlo realmente. En los documentos de Apollo, si me desplazo un poco aquí, simplemente dice conectar tu cliente a React. Te dice que hagas algo como esto, donde tienes este proveedor de Apollo que te proporciona y espera una propiedad de cliente donde simplemente pasas este cliente que creaste. Eso es exactamente lo que hacemos en esta aplicación, en _app, simplemente importamos ApolloProvider de React. Y continuamos y envolvemos toda nuestra aplicación en eso y luego pasamos el cliente. Eso significa que, en el fondo, esto usa el contexto de React, utiliza la API de contexto para hacer que este proveedor de Apollo esté disponible en todo tu sitio. Eso significa que podrás ejecutar consultas GraphQL en cualquier página o desde cualquier componente. Eso es realmente todo. Una vez que hayas hecho eso, pasas el cliente que has creado como proveedor. A partir de entonces, podremos ejecutar todas las consultas que necesitamos en nuestras páginas aquí. Sí, los documentos se adentran más en detalle sobre cómo usar algunos de los hooks y cosas que proporciona Apollo, pero por ahora, para nuestra configuración, eso es realmente todo lo que hemos cubierto. Muy bien, eso fue todo para todos los pasos de configuración. Sé que aún no te has adentrado en el código y realmente has construido algo. Espero que no te importe y hayas estado escuchando pacientemente a través de las cosas, pero eso es hacia donde nos dirigimos. El siguiente paso es sumergirnos y comenzar a codificar aquí con el paso cinco después de haber hecho nuestras configuraciones. Así que haré una pausa y revisaré el chat por un minuto, a ver si tenemos alguna pregunta.

Muy bien, sí, alguien se unió tarde y solo necesita el enlace a las diapositivas. Oh, y alguien más lo proporcionó. Muchas gracias. Veamos, Victor preguntó, ¿por qué no usaste TypeScript? TypeScript es increíble, pero para este proyecto, tan simple, argumentaría que no es realmente necesario. Hay muy poco en marcha. Solo estamos obteniendo datos de un backend y luego ejecutándolos en la página. No es altamente interactivo y no es un código grande donde perderías el rastro de qué objetos tienen qué propiedades y así sucesivamente. En mi experiencia, es cuando TypeScript realmente es útil y valioso, cuando tienes un proyecto grande y complejo y quieres que se realice esa comprobación de tipos para asegurarte de que no estás pasando por alto cosas o cometiendo errores. Sin embargo, para un taller como este, no quiero agregar una capa adicional, otra razón para no usar TypeScript en esta demostración es que no quiero agregar una capa adicional de complejidad para que ellos lidien con ella. Si solo están tratando de aprender cómo hacer consultas de datos desde el backend de WordPress y renderizar en la página. Si agrego todo, y tienes que agregar todas estas anotaciones de tipo en todas partes, eso podría ser un poco confuso para que aprendan. Diría que si TypeScript, si tienes un proyecto complejo donde la comprobación de tipos te beneficiaría, definitivamente investiga TypeScript y puedes tomar el conocimiento que obtuviste en este taller como un primer paso o una base sobre cómo hacer WordPress sin cabeza. Y luego, una vez que aprendas TypeScript, puedes agregar TypeScript a esto y agregar tus anotaciones de tipo para obtener los beneficios de TypeScript. Sí, por eso no lo estamos usando para este proyecto. También preguntaron, ¿por qué se necesita Apollo Client en un proyecto del mundo real, pero no en el ejemplo actual?

7. Usando Apollo Client

Short description:

Utilizaremos Apollo Client para obtener datos en lugar de utilizar datos ficticios. Continuemos con la masterclass.

Esta aplicación utiliza Apollo Client, o lo utilizará tan pronto como lo conectemos. Esa es nuestra tarea. En lugar de 'blog' aquí, puedes ver que estoy importando dos cosas que aún no estamos utilizando. En nuestra página de blog en este sitio, estoy importando GQL de Apollo Client y también importando el cliente que creamos dentro de esta carpeta Lib, esta cosa que vimos, estoy importando ambas. Pero si te fijas, aún no estamos utilizando estas líneas en este momento. Eso se debe a que nuestros datos provienen de este archivo de datos ficticios. Nuestra tarea será eliminar estas líneas para dejar de utilizar datos ficticios y, en su lugar, utilizar Apollo Client para obtener los datos. Espero que eso sea útil. Sí, eso es a donde nos dirigimos. Utilizaremos Apollo Client para este proyecto. Genial, creo que eso es todo por el chat. Sigamos adelante.

8. Componiendo Consultas GraphQL con el IDE de GraphQL

Short description:

Para componer una consulta GraphQL utilizando el IDE de GraphQL, puedes utilizar la aplicación gráfica. Proporciona un entorno IDE agradable donde puedes componer consultas seleccionando los campos de datos deseados. A medida que seleccionas los campos, la consulta se compone automáticamente para ti. Una vez que la consulta esté completa, puedes ejecutarla y ver los datos que recibiría tu aplicación front-end. Esta es una herramienta útil para construir consultas y obtener una vista previa de los datos que se devolverán.

Muy bien, en las diapositivas, tenemos componer una consulta GraphQL utilizando el IDE de GraphQL. Entonces, una cosa que es fácil pasar por alto aquí es la I en esta palabra, ¿verdad? Puedes echar un vistazo rápido y pensar, oh, es GraphQL. En realidad no lo es, es graph IQL, pronunciado graphical. Correcto, y GraphQL es una popular aplicación JavaScript que se utiliza para componer consultas GraphQL. Permíteme mostrarte un ejemplo... Te mostraré un ejemplo.

Así que recuerda esto, sabes, el sitio WordPress que había iniciado anteriormente solo para mostrarte cómo se vería instalar y activar el complemento WP GraphQL. Si vuelvo al administrador de WordPress, en realidad proporciona un IDE de GraphQL para ti directamente en el administrador de WordPress. Entonces, si haces esto en tu sitio WordPress, lo que podrías hacer es pasar el cursor sobre GraphQL, ir a IDE gráfico y te brinda este entorno IDE realmente agradable que puedes utilizar para componer consultas. Y está yendo un poco lento aquí. Esta no es una gran demostración. ¿Qué está pasando? Vale, no sé por qué tardó mucho tiempo en cargarse en ese momento, no estoy seguro por qué, pero así es como se ve un gráfico. Entonces es una aplicación realmente útil para componer consultas para que puedas hacer cosas como estas.

Permíteme mostrarte. Si voy al compositor de consultas, y abro esto aquí, puedes darle un nombre a tu consulta. Así que diré, ya sabes, obtener publicaciones así. Y luego dentro de esto, puedes, déjame deshacerme de algunas de estas cosas. Puedes comenzar, puedes ver todo el gráfico de datos y comenzar a marcar casillas que indiquen qué datos quieres recibir. Entonces, si quieres publicaciones de blog, puedes ir a publicaciones. Y para cada uno de los nodos de esa publicación, quiero recibir, veamos. Entonces la fecha de esa publicación de blog y el contenido, por supuesto, vamos a querer el título de la publicación de blog, que estaría aquí. Puedes ver que a medida que hago clic en estas casillas, compone la consulta para mí en este panel aquí, lo cual es muy útil. Entonces, una vez que hayas seleccionado todos los campos que crees que quieres para esta página de tu aplicación front-end que estás construyendo y tu consulta se ve bien, entonces puedes hacer clic en este ícono de reproducción para ejecutar esto y ver a la derecha lo que tu aplicación front-end JavaScript recibiría si enviara esta consulta idéntica.

9. Componiendo consultas GraphQL para aplicaciones front-end

Short description:

En esta parte, compondremos una consulta GraphQL utilizando el IDE gráfico. Comenzaremos marcando las casillas para construir la consulta de las publicaciones de blog más recientes. Incluiremos campos como ID de base de datos, título, extracto, URI e imagen destacada. Esto nos permitirá obtener los datos necesarios para nuestra página de blog. ¡Sumergámonos y comencemos a codificar!

Entonces hagamos eso. Presionaré el botón de reproducción y listo. Aquí están los nodos de las publicaciones que recibo. Puedes ver que cada uno de estos objetos es, aquí está la fecha, aquí está el contenido de la publicación del blog, aquí está el título de esa publicación. Esto es muy útil. Puedes seguir modificando esto y seguir marcando casillas hasta que tu consulta se vea bien y los data que regresan sean los que necesitas para esta página o componente específico de tu aplicación front-end. Una vez que estés satisfecho con ello, simplemente puedes resaltar todo esto, esta consulta que has escrito y pegarla en tu aplicación front-end. Y eso es lo que le dices a Apollo que ejecute. Y luego sabrás la estructura de los data que puedes esperar recibir. Esto es muy útil. Este es un ejemplo del IDE gráfico que el complemento wp-graphical te proporciona. Puedes usarlo aquí mismo dentro del administrador de WordPress. Sin embargo, nosotros vamos a utilizar una versión gratuita alojada de GraphQL para construir nuestras consultas. Entonces, volviendo a nuestra página de enlaces, ese sería el número siete aquí. Si haces clic en el número siete en la página de enlaces, se abrirá esta página. Así que eso es graphicalonline.com. Esta es una pequeña y genial versión gratuita alojada de GraphQL que puedes utilizar. Entonces, para nosotros, ¿puedes adivinar qué vamos a usar como URL de punto final de GraphQL aquí? Si adivinaste la que está en nuestro archivo EMV, ganas, estás en lo correcto. Entonces hagámoslo. Copiaremos todo esto desde el archivo .emv.local. Esa es la URL de punto final de GraphQL que vamos a utilizar. Y la pegaremos aquí y luego presionaremos este botón. Muy bien, y puedes ver que se ve bastante similar a lo que te mostré en el administrador de WordPress. Todavía tenemos el explorador de consultas. Todavía tenemos esta área para componer nuestras consultas y esta área para ver los resultados de las mismas. Y tienes algunas otras opciones, como agregar encabezados o lo que sea, si así lo deseas. Muy bien, ahora estamos listos para utilizar ese punto final en este sitio de contenido. Y si tienes curiosidad, así es como se ve realmente WordPress. Si intentamos ir a este dominio, puedes ver que es un sitio de WordPress con WPGraphQL. Se ve así. Si dejas que WordPress se encargue de la representación utilizando un tema en particular, creo que este es el tema 2022 o algo así. Entonces, así es como se vería. Pero en lugar de eso, estamos diciendo que queremos acceder al punto final de GraphQL para obtener solo JSON sin procesar porque vamos a manejar toda la representación en nuestra aplicación Next.js. Así que de ahí viene eso. Muy bien, de vuelta en el gráfico alojado aquí, avísame si todos pudieron ir a este enlace y luego pegar este punto final de GraphQL porque vamos a pasar algún tiempo aquí componiendo nuestras consultas. ¿Pueden darme un pulgar hacia arriba, si llegaron a ese punto en el chat y están aquí? Muy bien, genial. Veo algunos pulgares hacia arriba. Muy bien, averigüemos qué necesitamos aquí. Entonces, volviendo a nuestra lista de tareas, ¿dónde estábamos aquí? Muy bien, componer una consulta GraphQL utilizando el IDE gráfico. Así que hagámoslo, ¿verdad? Ahora nos sumergiremos y haremos algo de codificación. Como te mostré antes, puedes marcar algunas casillas aquí para componer estas consultas. Así que todos, intentemos hacer esto, solo esto juntos aquí. Todos abran el Explorador. Si aún no está abierto, puedes presionar este botón aquí para abrir el Explorador de GraphQL. Y una vez que esté abierto, desplázate hacia abajo hasta que veas las publicaciones allí y luego haz clic para expandir las publicaciones. Y luego vamos a hacer clic nuevamente en nodos porque nos interesa obtener cada uno de los nodos de las publicaciones individuales. Haz clic nuevamente allí. Deberías ver esto, las consultas, comienza a componer la consulta por ti, y vamos a obtener algunas piezas de data. Así que solo pausa, ten paciencia un segundo aquí. Lo siento. Muy bien, comencemos a obtener los data que necesitaremos para nuestra página de blog. Dame un momento, solo un minuto de configuración aquí. De acuerdo, creo que estamos listos. Muy bien, volviendo aquí, íbamos a hacer publicaciones y luego nodos. Y dentro de eso, vamos a necesitar algunas piezas de data. Lo siento, uno, verifiqué el incorrecto. Admito que estoy utilizando una aplicación terminada que tiene los campos. Estoy usando una hoja de trucos aquí. Ahí está, de acuerdo. Ahora sé qué campos decirle a la consulta que busque. Muy bien, la consulta que vamos a intentar componer aquí es la que necesitamos para nuestra página de publicación de blog. Como recordatorio, esa es esta, ¿verdad? Vamos a componer una consulta para decirle al cliente de Apollo y en última instancia a WPGraphQL que la consulta que queremos ejecutar es para las publicaciones de blog más recientes aquí. Así que veamos cómo podemos construir eso. Muy bien, entonces necesitaremos publicaciones, nodos. Y dentro de eso, vamos a marcar algunas casillas. Así que haremos, la primera que haremos es ID de base de datos. Entonces, dentro de nodos, si te desplazas hacia abajo y encuentras las D, haz clic en ID de base de datos, verás que lo agrega a la lista. A continuación, obtendremos el título. Así que desplázate hacia abajo hasta las T y haz clic en título, ¿verdad? Si te gusta este flujo de trabajo de marcar las casillas o seleccionar las casillas, esto funciona muy bien. Otro truco es que puedes usar control espacio. Así que uso esto mucho. Por ejemplo, si estás anidado, si tu cursor está anidado así, puedes desplazarte en algún lugar dentro de tu consulta. Así que simplemente presionaré enter para obtener una nueva línea. Y luego desde aquí, si presiono control espacio, obtengo el autocompletado aquí. Así que puedes ver que puedo usar las teclas de flecha, puedo subir y bajar. Y luego, a medida que escribo, esta lista se acortará cada vez más e intentará autocompletar lo que estoy escribiendo. Entonces, lo siguiente que vamos a obtener es el extracto. Así que intentaré escribir eso. Entonces, si escribo ex, puedes ver que ya ha reducido la lista a extracto. Cree que sabe lo que estoy tratando de escribir. Y si el resaltado es correcto, ese es el que quieres. Y si presionas enter, verás que se agrega el extracto para ti. Entonces, esta puede ser una forma rápida, encuentro que si eres alguien que no siente que conoce muy bien cómo se ve el esquema de GraphQL, que WordPress te proporciona, entonces las casillas de verificación son realmente útiles porque puedes ver visualmente todas ellas. De lo contrario, si has hecho este tipo de cosas antes y estás algo familiarizado con el esquema de GraphQL, es cuando hacer esto, ya sabes, este autocompletado para llegar rápidamente a lo que deseas, es cuando es más útil, creo. Así que obtendremos el extracto. Lo siguiente es URI. Entonces U-R-I, esa es la URI o la URL de la publicación del blog, por ejemplo. Lo siguiente que obtendremos es la imagen destacada. Así que esta tendrá algunos campos anidados dentro de ella.

10. Consultando la imagen destacada en GraphQL

Short description:

Aquí te mostramos cómo consultar la imagen destacada en GraphQL. Puedes obtener la URL de origen y el texto alternativo de la imagen. Recuerda manejar los casos en los que la imagen destacada sea nula. GraphQL proporciona información explícita sobre los posibles tipos de valores, lo que te permite saber exactamente qué esperar en tu aplicación Front-End JS.

Esta es la primera vez que vemos esto. Aquí está la imagen destacada en el Explorador, y puedes ver que tiene un menú desplegable aquí. Si lo expando, aquí está la imagen destacada. Me dice que lanzará un error diciendo, oh, necesitas una selección de subcampos dentro de esto para decirle a GraphQL qué campos quieres. En nuestro caso, solo obtendremos algunos de ellos en el nodo de la imagen destacada. Así que imagen destacada, y ahora haz clic en nodo, así. Deberías estar en este punto. Y luego, dentro de nodo, solo obtendremos dos campos. El primero es la URL de origen. Así que ahí tienes, desplázate hacia abajo hasta las S y marca la casilla de verificación junto a URL de origen. Esa es la URL donde realmente se encuentra esta imagen, este archivo JPEG o PNG o lo que sea, esa es su URL. Y luego, por razones de accessibility, también necesitamos el texto alternativo. Así que desplázate hacia arriba y marca la casilla de verificación junto a texto alternativo. Así de simple. Y eso es todo para nuestra consulta aquí. Sí, puedo mostrarte, agregaremos tal vez una variable solo para especificar el número de páginas. Pero por ahora, si has construido esto, haz clic en el botón de reproducción para ejecutar esto y luego ve lo que obtienes al otro lado. Deberías ver algo como esto donde tienes cada uno de los nodos de las publicaciones y dentro de cada uno de ellos, ¿cuál es el ID de la database? ¿Cuál es el título? ¿Cuál es el extracto URI? Puedes notar que la imagen destacada para algunas de estas puede ser nula, ¿verdad? Puedes pensar, ¿es un error? ¿Es un error o algo así? Pero no lo es. Todo lo que significa es que esta publicación de blog en particular no tiene una. No hay una imagen destacada adjunta. Así que tendremos que tenerlo en cuenta en nuestra aplicación Front-End JS, tendremos que decir, ¿hay una imagen destacada? Si es así, entonces muéstrala en la página. De lo contrario, si no hay una, entonces no intentes mostrarla. Así que tenemos que tenerlo en cuenta. Muy bien, y GraphQL es muy genial porque es muy explícito sobre lo que cada valor podría ser. Así que si mantengo presionada la tecla comando, estoy en una Mac, si mantengo presionada la tecla comando y luego hago clic en imagen destacada, justo aquí, aparece en la documentación del esquema y puedes ver cuál es el tipo de esta cosa. Así que el tipo de nodo aquí para las imágenes destacadas es este media item, tipo en GraphQL. Si hago clic en eso, puedes ver todos los campos que tiene. Así que aquí está el texto alternativo, todos los posibles tipos que podría tener el texto alternativo, por ejemplo, siempre es una cadena, pero otras cosas aquí, puedes ver que, bueno, a veces podría ser nulo, otras veces podría ser una cadena, y así sucesivamente. Así que es muy útil porque es tan explícito y puedes saber exactamente cuáles son los posibles tipos en tu aplicación Front-End JS.

11. Componiendo la Consulta y Configurando la Paginación

Short description:

Vamos a pasar una variable para determinar cuántas publicaciones queremos recuperar. Por defecto, está configurado en 10, pero podemos aumentarlo para obtener más. Por ejemplo, podemos seleccionar las primeras 18 publicaciones especificando 'first: 18' en nuestra consulta. Si queremos comenzar desde una publicación específica, podemos usar el parámetro 'after'. En este caso, estamos comenzando desde la publicación más reciente estableciendo 'after: null'. De esta manera, obtendremos las primeras 18 publicaciones desde el principio de la lista.

Muy bien, esto es todo para componer nuestra primera consulta con una excepción. Como mencioné, vamos a pasar una variable aquí para determinar cuántas publicaciones. Por defecto, creo que son 10. Esto nos dará 10 publicaciones de blog. Digamos que queremos algunas más en nuestra aplicación Front-End, lo que podemos hacer es abrir paréntesis aquí. Después de 'posts', abrimos paréntesis, y en este punto puedes ver nuestras opciones son 'after', 'before', 'first', 'last', 'where', así que puedes hacer alguna paginación y algunas opciones de filtrado si quieres obtener solo ciertas publicaciones. En nuestro caso, seleccionemos 'first', y diremos que queremos las primeras 18 publicaciones. Así que en lugar de solo las primeras 10, que es el valor predeterminado, lo aumentaremos un poco. Queremos las primeras 18 publicaciones. Si estuviéramos haciendo paginación, podríamos decir 'after' y obtener las primeras 18 después de la que está en la página tres o más adelante en la lista, pero solo para ser explícitos, podemos decir 'after null', lo que significa comenzar desde el principio con la publicación más reciente. Así que lo dejaremos así solo para ser más explícitos, diremos 'after null'. Así que estamos obteniendo una publicación, las primeras 18 de ellas después de 'null', por lo que estamos comenzando desde el principio de la lista. Ahora, si ejecutamos eso, deberíamos obtener 18 o la cantidad que haya, si solo hay dos publicaciones de blog, entonces solo verás dos en esta lista, pero estamos obteniendo todas ellas hasta un máximo de 18 allí.

12. Obteniendo Datos Reales de GraphQL

Short description:

Vamos a definir la consulta que necesitamos en nuestra aplicación Front-End para obtener datos reales de GraphQL. Utilizaremos el literal de plantilla etiquetado gql de Apollo Client. Definiremos la consulta, la nombraremos 'obtener publicaciones' y la pasaremos a través de gql. A continuación, utilizaremos la constante de consulta que hemos definido para obtener datos del backend de WordPress utilizando el método de consulta de Apollo Client. Una vez que obtengamos la respuesta, accederemos a las publicaciones del blog y las pasaremos como una propiedad a nuestro componente. Por último, guardaremos el archivo y veremos los datos en vivo mostrados en nuestra aplicación Front-End.

Muy bien, entonces, volveré al chat, avísenme cómo están. ¿Puedo obtener algunos pulgares arriba, haré una línea divisoria en el chat. Ahí vamos. Si pueden componer esta consulta y luego marcar la casilla para ejecutarla y ver los resultados en el otro lado. Muy bien, genial. Excelente. Sí, esta es la consulta que necesitamos en nuestra aplicación Front-End y que vamos a utilizar para obtener nuestros data. Esto es emocionante. Vamos a hacer uso de eso ahora. Así que vuelve a abrir VS Code o cualquier editor de código que estés usando, y como he dicho varias veces, nuestro trabajo es eliminar los datos ficticios y hacer que esto funcione con datos reales de GraphQL. Así que hagamos eso.

Entonces, nuestra página Front-End, adiós página Front-End, se romperá tan pronto como hagamos esto, ¿verdad? Así que te pediré que resaltes estas líneas con los datos ficticios y las elimines y tan pronto como guardes eso, tu aplicación Front-End se estrellará y fallará si intentamos recargarla aquí ya que no tiene los datos que espera. Así que arreglemos esto dándole los datos reales del backend de WordPress. Así que te mostraré cómo hacerlo ahora. Lo que necesitamos hacer es usar esto gql. Esto es un literal de plantilla etiquetado de Apollo Client y dentro de eso, vamos a definir nuestra consulta. Así que hagamos esto. Justo encima de donde está el componente de blog, escribe esto. Haremos const y luego get posts en mayúsculas así, igual que eso, y luego un punto y coma después. Si lees la documentación de Apollo Client, verás esta convención que se utiliza. Te indica que uses este literal de plantilla etiquetado gql y luego pases dentro de las comillas invertidas la consulta que deseas ejecutar. Así que eso es de donde viene esto. Dentro de estas comillas invertidas, simplemente presionaré Enter dos veces para hacer un poco de espacio. Y lo que haremos es volver a Graphical y copiar todo esto que habíamos compuesto aquí. Copiaré eso y luego lo pegaré entre estas comillas invertidas así. Aquí tengo resaltado de sintaxis porque tengo una extensión de VS Code instalada. Tengo esta, Apollo GraphQL. Así que si te gusta trabajar con GraphQL y Apollo y quieres el resaltado de sintaxis dentro de estos literales de tipo GQL y otras funciones, entonces puedes instalarlo si quieres el Apollo GraphQL, pero de lo contrario, si solo ves un texto sólido aquí, si está todo en blanco o lo que sea, eso está bien. Seguirá funcionando muy bien. Muy bien, hemos definido la consulta que queremos aquí. Al crear esta consulta, pasándola a través de GQL, se convertirá en lo que se llama un AST (Árbol de Sintaxis Abstracta) que es lo que Apollo Client, ya sabes, espera recibir y puede usar para procesar la consulta. Así que realmente usamos esta constante que hemos definido aquí, ¿verdad?, ese sería el siguiente paso. Así que hagamos eso. Desplazaremos un poco hacia abajo. Así que ve a obtener propiedades estáticas aquí. Y para aquellos que no están muy familiarizados con Next.js, obtener propiedades estáticas es una convención de Next.js que te brindan. Dicen que si exportas una función asíncrona desde tu archivo de componente llamada obtener propiedades estáticas, entonces todo lo que esté dentro de esto, Next.js lo ejecutará en el momento de la construcción. Por lo tanto, efectuará cualquier obtención de datos y cualquier cosa que desees hacer en el momento de la construcción y luego pasará estas propiedades al componente cuando se renderice en el servidor de Next.js. Por lo tanto, esto no es algo que el visitante del sitio tenga que esperar. Esto se hace de antemano cuando se construye la página. Por lo tanto, este es un lugar perfecto para obtener nuestros datos. Por lo tanto, vamos a hacer uso de nuestro cliente que habíamos creado antes. Así que en la parte superior del archivo, recuerda que habíamos importado este cliente de lib, cliente de Apollo, así, justo así, eso es lo que vamos a usar. Así que en la parte superior de esto, simplemente presionaremos Enter un par de veces y luego definiremos otra constante. Así que hacemos const respuesta, escribimos eso. Igual a. Esperaremos la respuesta de esto. Así que esperaremos la respuesta de la consulta del cliente. Muy bien, comenzaré solo con eso. Esto significa que estamos tomando la instancia del cliente de Apollo que habíamos creado, y luego llamando al método .query en eso. Y vamos a pasar información sobre la consulta que queremos que Apollo ejecute. Y luego obtendremos la respuesta. Así que dentro de estos paréntesis, luego vamos a pasar un objeto. Así que adelante y abre unas llaves así, presiona Enter, y luego vamos a decir consulta: Y aquí es donde pasamos la consulta. Así que para nosotros, eso fue getposts, todo en mayúsculas, justo así. Así que eso pasa esta consulta que habíamos construido en la parte superior. Muy bien. Una vez que obtengamos la respuesta de eso, tenemos que hacer uso de ella. Así que en lugar de esta cosa de postposts, así que elimina eso. Y luego en su lugar vamos a profundizar en nuestras publicaciones de blog. Vamos a hacer respuesta.data.posts.nodes. Así, te doy un segundo para escribir todo eso. Si te preguntas en tu aplicación, cómo sabrías que tienes que profundizar tanto, GraphQL es realmente genial en cómo estructuras, los niveles de anidamiento aquí, cómo estructuras tu consulta, la respuesta que regresa coincidirá con eso, lo cual es muy genial. Así que si miras aquí, teníamos consulta, publicaciones, nodos, y luego los campos, la respuesta es data, publicación, nodos, y luego los campos. Así que si profundizamos hasta ese punto, y luego los campos, ¿verdad? Así que sigue esa misma estructura. Así es de donde vienen estas publicaciones y los nodos. Viene de nuestra propia consulta. Porque dijimos, agregaremos publicaciones y luego nodos, ¿verdad? Y ahí es donde vivirían nuestras publicaciones. Muy bien, estamos tratando de profundizar en cada uno de nuestros nodos de publicación individuales. Y lo pasaremos como una propiedad, llamada publicaciones, a nuestro componente. Nuestro componente luego está desestructurando, y extrayendo esa lista de publicaciones, y tratando de renderizar nuestra lista de publicaciones en la página. Así que guardaré este archivo, y volveré al Front-End, y cruzaremos los dedos. ¡Shazam, ahí está! Está funcionando. Puedes ver que ya no hay latín. Teníamos los títulos en latín, ya sabes, con nuestros datos ficticios. Ya no hay títulos en latín. Estos son los datos en vivo reales que provienen de un sitio de WordPress real. Así que esto es súper genial, ¿verdad? Puedes ver que tenemos los títulos y extractos que se muestran aquí. Y estos están enlazados. Así que si hago clic en uno de estos, intentará llevarme, ya sabes, a la página individual de la publicación del blog en la que hice clic.

13. Implementando la Página de Publicación Individual del Blog

Short description:

Especificamos un máximo de 18 también. Si te vuelves más avanzado, puedes hacer cosas de paginación. Si obtienes un error de tipo, intenta imprimir en la consola la respuesta. Asegúrate de que Apollo Client esté configurado correctamente. Si aún tienes problemas, utiliza el punto de control proporcionado. Hemos terminado de implementar la página de índice del blog. Pasemos a implementar la página de publicación individual del blog. Construiremos una consulta para usar en lugar de datos ficticios. Usaremos el URI para buscar la publicación del blog. Crea una nueva consulta para obtener una sola publicación del blog. Vamos al Explorador de GraphQL y busquemos 'posts singular'. Creemos una consulta que obtenga los campos de título y fecha. Deja en blanco el ID por ahora. Tu consulta debería verse así.

Y también especificamos un máximo de 18. Así que si los cuentas, debería haber, ya sabes, 18 de estos. Una vez que te vuelvas más avanzado, puedes hacer cosas de paginación, donde puedes hacer scroll infinito, donde cargas más de inmediato cuando el usuario se desplaza hacia abajo, o tener un botón de cargar más y cargar más. Pero para nosotros, nos detendremos aquí y mostraremos los 18. Muy bien, revisa el chat rápidamente. Entonces, Vaka, veo. Error de tipo, no se puede leer la propiedad data de indefinido. De acuerdo. Parece que eso viene de este punto del código, ¿verdad? Diciendo que estás intentando profundizar en data, pero la respuesta, esta cosa está indefinida. De acuerdo. Veamos. No sé por qué sería eso. Una de las primeras cosas que intentaría es simplemente imprimir en la consola. Probablemente solo haría un registro en la consola, la respuesta aquí, guardar eso. Y luego, si abres la terminal, deberías ver que se imprime data. Intentaré volver a cargar mi página de blog y veremos si se imprime. Sí, lo hace. Así que si intento volver a cargar mi página de blog con esa declaración de registro en su lugar, puedes ver que esto es lo que imprime para mí. Así que tienes cualquier data de publicaciones, y dentro de eso está mi matriz de nodos, y luego algunas otras cosas, carga falsa, estado de red siete. Así es como se espera que sea esa respuesta. Si estás obteniendo algo diferente, entonces debe ser un problema con Apollo Client, ya sabes, que no está configurado correctamente. Así que haría algunas comprobaciones, asegúrate de hacer todo esto correctamente y estás definiendo esta variable de entorno dentro del archivo .env exactamente como esto, debe verse exactamente así. Sí, y esto está escrito como debería ser, exactamente así. Así que espero que eso sea suficiente, si no puedes hacer que funcione, siempre puedes usar este punto de control aquí. Hemos terminado de implementar la página de índice del blog. Entonces, Vacha en el chat o cualquier otra persona, si estabas luchando aquí y tuviste problemas para hacer que la página de publicación del blog funcionara, en este punto podrías ejecutar git checkout y luego pegar este hash de confirmación y eso debería devolverte a la velocidad. Por lo tanto, deberías poder... Intentaría git checkout con ese hash de confirmación y tal vez hacer comando C o lo siento, control C solo para detener el servidor de Next.js y luego npm run dev nuevamente para que vuelva a funcionar. Y en ese punto, deberías ver que la página del blog funciona como esto. Muy bien, oh, increíble, arreglado. Bueno, me alegra escucharlo. Genial, está bien, seguiremos adelante entonces. Espero que todos se diviertan. El número cinco fue, vimos cómo podríamos componer una consulta usando GraphiQL y también hemos logrado el número seis, implementar la página de índice del blog. Usando esa consulta que habíamos compuesto, le dijimos a Next.js que la ejecutara en el momento de la construcción y luego la pasara como props a nuestro componente y la usara para renderizar la página, ¿verdad? Así que ahora pasamos al número siete, implementar la página de publicación individual del blog. Como recordatorio, veamos, oh, déjame eliminar mis líneas de depuración allí rápidamente. De acuerdo, como recordatorio, echemos un vistazo a nuestra página de publicación individual del blog. Así que era este punto suspensivo de ruta de captura de URI aquí. Entonces, si volvemos a eso, veremos, sí, solo recordémonos cómo se ve esto. Entonces, nuevamente, estamos sacando los datos ficticios, ya sabes, llamados publicación y dentro de obtener propiedades estáticas, simplemente los enviamos como props y eso es lo que usamos para renderizar el contenido. Así que solo son datos ficticios en este momento. Aquí seguiremos ese mismo patrón donde vamos a, ya sabes, eliminar nuestros datos ficticios y luego construir una consulta para usar en su lugar. Voy a eliminar esos datos ficticios y volvamos a nuestra instancia gráfica alojada aquí para construir otra consulta. Una cosa genial que te mostraré es que puedes definir múltiples consultas aquí, eso está permitido siempre que cada una tenga un nombre único. Entonces, como esta, habíamos llamado a nuestra consulta getPosts así. Y puedes tener múltiples aquí siempre que cada una tenga un nombre único. Entonces puedes hacer consulta getPost singular y luego tener dentro de aquí otra consulta. Y luego, cuando vayas a ejecutarlo, GraphiQL te preguntará, bueno, ¿cuál? Usarás este menú desplegable y dirás, ¿quieres ejecutar usePosts o usePosts? Y puedes decirle cuál quieres ejecutar. Así que esa es una forma genial. Si no quieres eliminar lo que habías trabajado en construir la primera vez, si quieres dejarlo en su lugar o estás probando o lo que sea, está bien tener múltiples siempre que tengan nombres únicos y se puedan ejecutar cada una de ellas. Sin embargo, para nosotros, simplemente eliminemos estos y comencemos desde una pizarra limpia. Entonces, este será uno divertido porque esta será nuestra primera consulta de GraphQL que acepta una variable. Entonces, en la última, simplemente dijimos, danos las primeras 18 publicaciones del blog y eso es todo. Supongo que técnicamente teníamos una variable porque dijimos que el número 18 es la cantidad que queremos, pero esta será una variable real donde pasaremos el slug, el slug de URL que está visitando el usuario. Lo usaremos para buscar la publicación del blog en particular que es la correcta, cuyos datos necesitamos, si tiene sentido. Permíteme mostrarte. Solo déjame poner los datos de nuevo por un segundo para mostrarte a qué me refiero. Entonces, lo que sucede es que si alguien está en la página del blog aquí y luego intenta hacer clic en una de estas publicaciones, esta es la estructura de URL, los envía... Ya sabes, tenemos como la fecha aquí y luego agregando pruebas de extremo a extremo a WordPress. Tenemos todo esto, que se llama slug en WordPress. Entonces tenemos como esta estructura de fecha y luego el slug después de eso, y todo esto, todo esto, la fecha más el slug, todo eso se llama URI. Y eso es lo que vamos a usar realmente para buscar la publicación del blog. Le diremos a WordPress, encuentra la publicación del blog que tiene todo esto como su URI. WordPress lo encontrará en la base de datos y luego proporcionará el título, el contenido, ya sabes, todos los datos que solicitamos. Entonces esto es lo que vamos a usar como nuestra variable que enviamos a nuestra consulta que vamos a construir aquí. Muy bien, hagámoslo. De acuerdo. Entonces, aquí, creemos una nueva consulta para obtener una sola publicación del blog. Así que en el Explorador de GraphQL, bajemos a las P, elemento de P y busquemos publicaciones singulares. Haz clic en eso. Y ya, ya sabes, al igual que la última vez, comenzará a construir la consulta por nosotros. E incluso sabe que la publicación requiere un ID porque pregunta, oh, bueno, ¿qué publicación quieres? Así que tendremos que abordar eso aquí. Entonces, para el ID, sí, podrías, si quieres, con fines de prueba, podrías ingresar un valor aquí. Incluso si escribes un valor, eso es lo que se usaría como ID. Sin embargo, para nosotros, queremos que esto sea dinámico. Pasará un valor de variable diferente, ya sabes, para cada publicación del blog. Así que lo dejaré en blanco por ahora. Te mostraré cómo convertirlo en una variable. O en realidad, supongo que podríamos usar este. Veamos si podemos hacer que eso funcione con fines de demostración. De acuerdo, si digo que ese es el ID y tengo llaves y digo obtener el título, ¿funciona eso realmente? Sí, no, el ID no está. Así que no intentemos hacer eso aquí. Dejaré en blanco el ID por ahora. Nos centraremos solo en los campos que necesitamos. Tu consulta debería verse así.

14. Componiendo la Consulta y Seleccionando Campos

Short description:

Para obtener el contenido de la publicación del blog, marca la casilla de Contenido. Para el nombre del autor, selecciona Nombre del Nodo de Autor. Para las categorías, selecciona el slug y el nombre de cada nodo de categoría.

Entonces, si te desplazas hacia abajo hasta las Ds, haz clic en Fecha justo allí, oh, y todavía tengo, sí, así que necesitaremos Título y Fecha. Ambos, así que título, hice clic en uno de esos, lo dejaremos y luego también obtendremos la fecha. Queremos el contenido de esta publicación del blog. Así que en las Cs, marcamos la casilla de Contenido así. Queremos el autor y aquí nuevamente, luego vemos que esto no es una casilla de verificación, sino que tiene un menú desplegable. Así que necesitaremos algunos campos anidados dentro de esto. Haz clic en el menú desplegable de Autor y luego en Nodo. Y para ese Nodo de Autor, solo obtendremos el nombre de esa persona para poder mostrar quién lo escribió. Así que me desplazaré hacia abajo hasta Nombre y marcaré esa casilla. Ahí está, Nombre del Nodo de Autor, se ve bien. Lo último que necesitamos son las categorías de la publicación del blog. Así que desplázate hacia arriba hasta las Cs y luego lo que tenemos son las Cs. ¿Dónde estoy? Todavía estoy dentro de Autores. Oh, maldición, mi error. De acuerdo, así que serían las Cs en esta lista. Los niveles de anidamiento me confunden. Ahí vamos. Así que aquí están las categorías que estoy buscando. Dentro de esto, vamos a ir a los nodos. Así que para cada uno de esos nodos de categoría, solo vamos a seleccionar dos cosas. El slug y el nombre. Así que dentro de este ahora, puedes marcar las casillas de slug y nombre, o nuevamente, si eres alguien que, ya sabes, usando el teclado le gusta el autocompletado, lo que podrías hacer en este punto es abrir llaves y hacer comando espacio, slug, enter, comando espacio, nombre, enter. Para autocompletar esos campos también. De cualquier manera, ya sabes, funciona muy bien.

15. Consulta Dinámica con Variable URI

Short description:

Para hacer la consulta dinámica, necesitamos aceptar una variable para la URI. Definimos la variable en la sección de variables de consulta y la pasamos a la consulta. Especificamos el tipo de la variable URI como ID. Luego podemos usar esta consulta dinámica para obtener diferentes publicaciones de blog según la URI proporcionada. Definimos la constante getPost usando una plantilla literal etiquetada gql y pegamos la consulta dentro de ella. Finalmente, obtenemos la URI del contexto de Next.js y la pasamos a la consulta para obtener la publicación de blog correspondiente.

Muy bien. En lugar de Mi Consulta, obtener publicación por slug. Y nuestra aplicación es como la llamamos, y aquí está nuestra consulta compuesta. Entonces, si intentamos ejecutar esto, fallará porque no tenemos un ID. Dice que la entrada del ID no es válida. Dado que estamos pasando solo una cadena vacía aquí, necesitamos darle algo válido. Así que deberíamos poder hacer que esto funcione usando esto. Oh, creo que olvidé una barra diagonal. Permíteme intentarlo una vez, y si funciona, lo pegaré en el chat y tú también puedes usarlo. Así que intentaré pasar esto para el ID de esa manera, y luego necesitamos decirle qué tipo de ID también. Así que haré coma y luego Control espacio, y puedes ver que además del ID, una de las otras variables que podría proporcionar es el tipo de ID. Y eso se debe a que hay varias formas en que WordPress podría identificar una publicación de blog. Puedes usar su ID de base de datos, puedes usar su URI, puedes usar su slug, hay algunos identificadores diferentes. El valor predeterminado es el ID global, en el mundo de GraphQL. Pero en cambio, lo buscaremos por su URI. Así que haré para el tipo de ID, se está volviendo un poco abarrotado, lo sé. Pero para el tipo de ID aquí, haré Control espacio nuevamente y aquí están mis opciones. Entonces, esto es una unión de GraphQL, donde solo tiene estas cuatro opciones. Y debes elegir una de estas o más bien un enumerado, esto es un enumerado. ¿Vamos a mirar un ID de base de datos, o su ID, o su slug o su URI? Entonces, en nuestro caso, estamos diciendo que queremos el URI. Así que presionaré Enter y eso agregará el URI. Muy bien, eso debería ser todo. Estamos diciendo, aquí está el ID que vamos a usar y el tipo de ID es URI. Así que déjame intentarlo una vez y luego te lo pegaré si funciona. Muy bien, presionaré el botón e intentaremos ejecutar esto. ¡Shazam, ahí está! Muy bien, esto funciona. Porque ves que ahora estamos codificando esto. Entonces, si resaltamos todo esto y lo pegamos en nuestra aplicación, eso es un problema, ¿verdad? Ya que cada página que extraemos de esta publicación de blog en particular. Necesitamos hacer esto dinámico aquí al aceptar una variable. Entonces eso es en lo que podemos trabajar a continuación. Para aceptar una variable, podemos hacerlo, como usando esta sección de abajo. Así que ve a las variables de consulta aquí. Si haces clic allí, si está colapsado así, deberías poder hacer clic en él y arrastrarlo hacia arriba así. Dentro de las variables de consulta, puedes abrir algunas llaves aquí y escribir nuestras variables. Así que eliminaré estas de aquí. Y si escribo ID dos puntos, lo que tendremos que hacer después para hacer esto dinámico es usar una variable con un signo de dólar. Entonces, el ID que vamos a pasar es nuestro URI. Así que lo haremos así. Entonces, para el ID, pasamos esta variable llamada URI, coma, y luego nuestro tipo de ID. Esto podemos codificarlo, ¿verdad? Ya que siempre lo buscaremos por su ID. Así que esa parte de ello, me siento cómodo, ya sabes, codificándolo, pero no este URI aquí. Dice que la variable URI, no está definida por esta operación aquí. Dice que no estás aceptando esta variable. Así que necesitamos hacer eso ahora. Al final de esta línea, debes agregar algunos paréntesis para decir, ya puedes ver que mi error, las líneas onduladas están desapareciendo. Así que en este punto podemos decir, vas a esperar una variable y la variable que vas a aceptar es URI. Y en GraphQL tenemos que ser muy explícitos sobre el tipo, el tipo de argumento que pasamos. Así que haremos URI dos puntos, y luego tenemos que decir que el tipo es un ID con un signo de exclamación. Así que si vas, puedes profundizar en la especificación de GraphQL si quieres ver todos los tipos admitidos y cosas así. Pero este ID es un tipo que se ha definido para nosotros y luego el signo de exclamación significa que es obligatorio. Así que puede ser, ya sabes, en algunas consultas de GraphQL puedes tener un argumento opcional donde podrías pasarlo, pero no tienes que hacerlo. En nuestro caso, sin embargo, estamos agregando el signo de exclamación porque esto siempre es necesario para que nuestra consulta pueda ejecutarse. Muy bien, ahora tenemos nuestra consulta definida, espera URI, y luego cuando ejecuta la consulta, pasará esa variable en este punto. Lo usará como, ya sabes, este ID para pasarlo a la publicación. Así que ahora, en las variables de consulta, si abro mis llaves y hago control espacio, puedes ver aquí, una vez más, obtengo autocompletado. Está mirando mi consulta, sabe que, oh, parece que has definido una variable llamada URI. Así que probablemente sea la que quieres, ya sabes, definir en esta sección de variables de consulta, y tiene razón. Correcto, así que resaltaré URI y simplemente presionaré enter, y luego se insertará URI aquí. Y nuevamente, en este punto, podemos intentar usar esta cadena larga. Así que solo pondré esto entre comillas así, y trataremos de ejecutarlo. Entonces esto simula, ya sabes, una variable de consulta que se pasa a la consulta y luego se usa. Así que déjame probar esto ahora. Así que presionaré play. ¡Ahí vamos! Funcionó de nuevo. Sí, todavía estamos obteniendo los data. Y esto nos brinda una consulta agradable, flexible, ya sabes, y dinámica para usar donde puedes simplemente pasarle cualquier URI, y buscará una publicación diferente según la URI que se haya pasado. Esto es bueno. Esto es todo lo que necesitamos para nuestra página de una sola publicación de blog. Así que vamos a usar esto ahora. Muy bien, de vuelta en tu editor de código, ve adelante y abre URI aquí, y seguiremos nuestro mismo patrón anterior. Vamos a eliminar estas líneas de datos ficticios. Ya no las necesitamos. Y necesitamos definir nuestra consulta. Esta vez, en lugar de definir nuestra consulta justo encima del componente, podemos hacerlo tal vez más abajo para que esté más cerca de donde realmente lo usamos. Sí, justo encima de getStaticProps. Hagámoslo así, será más fácil de ver, podrás ver el componente aquí y luego ver dónde lo usamos justo debajo también. Muy bien, en este punto, justo encima de getStaticProps, vamos a definir una constante nuevamente, así que haz constante y luego getPost. Adelante y escribe eso. Y al igual que la última vez, lo vamos a igualar a esta gql, plantilla literal etiquetada, y con dos puntos al final. Plantillas literales etiquetadas, si no estás familiarizado, puedes buscar eso en Google y encontrar la documentación de Mozilla sobre qué son, pero son como un tipo de función que espera una cadena. Entonces, puedes pensar en gql como una función y está pasando la cadena que está dentro de estas comillas invertidas y luego la usa como su argumento. Muy bien, dentro de eso, aquí es donde vamos a pegar nuestra consulta. Así que volveré a GraphiQL y copiaré toda la consulta que habíamos compuesto, copiar eso, y eso es lo que vamos a pegar en este punto. Entonces, getPost, eso es lo que lo llamamos. Muy bien, tenemos que hacer uso de esto. Entonces, una cosa que estamos haciendo aquí es obtener la URI de Next.js. Y Next.js tiene este argumento de contexto que se pasa aquí y estamos profundizando. Estamos diciendo que para el contexto de la página actual, queremos profundizar en los parámetros, profundizar en la URI, y luego unirlos con una barra diagonal.

16. Implementando la Página de Categoría Individual

Short description:

Para recuperar la URI, usamos Apollo Client para consultar el objeto. Si se recibe la publicación, verificamos si se recuperó correctamente. Si es indefinido, devolvemos 'not found true'. De lo contrario, pasamos la publicación recuperada como una propiedad a nuestro componente. Hemos implementado con éxito una consulta GraphQL que acepta un argumento y muestra las páginas de publicaciones de blog individuales. A continuación, debemos implementar la página de categoría individual. En el archivo de categoría, definimos la consulta 'git category', pasando el ID del slug y el nombre del slug como variables. Probamos la consulta y confirmamos que ambas variables son necesarias. Luego procedemos a componer la consulta y recuperar los datos ficticios, pasándolos a través de 'git static props' a nuestro componente.

Solo, porque de forma predeterminada separa todo esto. Ve las barras diagonales aquí e intenta dividirlas. Entonces, lo que vamos a hacer es simplemente unirlos para que nos quede solo una cadena con la que trabajar. Así es como está el join.

Entonces, después de hacer eso, recibimos, recuperamos la URI que, que nos dieron. Necesitamos intentar buscar esto en realidad. Entonces, usaremos Apollo Client nuevamente en este punto. Entonces, presionaremos enter un par de veces y obtendremos nuestra respuesta de Apollo. Entonces, escribe const response equals. Vamos a esperar la respuesta y luego vamos a llamar, client.query, como la última vez. Entonces, sigue adelante y escribe eso. Y luego dentro de la consulta, vamos a pasar ese objeto como lo hicimos la última vez. Así que abre algunas llaves y aquí necesitamos decirle qué consulta usar. Correcto, así que en nuestro caso, esa es la que definimos arriba. Es git post, así que copiaré eso y eso es lo que vamos a pasar como nuestra consulta. Pero a diferencia de la última vez, aún no hemos terminado. Necesitamos presionar enter una vez más y luego pasar las variables que queremos que esta consulta use. Así que sigue adelante y escribe variables aquí, dos puntos y luego esto es un objeto donde necesitamos pasar cualquier variable para usar. Entonces, en nuestro caso, eso es URI. Entonces, esta URI que habíamos extraído del contexto de las páginas actuales. Esa URI es lo que necesitamos pasar en este punto como la variable. Muy bien, una vez que hayas compuesto todo eso, ahora le estamos diciendo a Apollo Client, aquí está la consulta para usar y aquí están las variables para pasar y estamos esperando la respuesta que regresa. Entonces, en este punto solo tengo que verificar si se recibió la publicación o no. Entonces, necesitamos definir, necesitamos verificar, verificar si se recibió y tratar de extraer la publicación. Hagamos const post equals, y luego intentaremos profundizar en esto. Esto sería response.data.post, así, y recuerda esta estructura data, aquí este nivel de anidamiento es igual a lo que habíamos definido. Entonces, esto sería data y eso sería post, por eso es solo data y luego.post. Entonces, intenta profundizar en ese nivel, pero si hay algún error, si no pudimos buscar las props estáticas, entonces esto podría ser indefinido, ¿verdad? Como Vaka dijo en el chat, para la última consulta, estaba recibiendo un mensaje indefinido. Entonces, esto podría suceder aquí bastante fácilmente si alguien simplemente va a nuestra aplicación front-end y hace esto, ¿verdad? Si escriben algo inválido o intentan ir a alguna página donde la URI es inválida, esto podría fallar fácilmente aquí. Entonces, vamos a verificar eso. Usaremos el encadenamiento opcional en JavaScript para hacer eso. Entonces, diremos response interrogación, si es así, sigue adelante, intenta acceder a data. Y luego diremos, si hay data, entonces sigue adelante e intenta profundizar en la publicación. Entonces, si en algún momento de esta cadena, algo es indefinido, eso haría que la publicación sea indefinida. Entonces, nuestra verificación aquí simplemente dice, si la publicación es falsa, lo que significa que no se definió, adelante y devuelve not found true. Y esto le dirá a Next.js que renderice nuestra página 404 para esta aplicación diciendo que esta página no se encontró. De lo contrario, lo haríamos pasar esta verificación y la publicación es verdadera, eso significa que la encontramos, ¿verdad? Entonces, en ese punto, estamos diciendo, estamos pasando props a nuestro componente y aquí está la prop para usar. Es esta publicación que obtuvimos. Muy bien, creo que eso debería hacerlo. Veamos si podemos hacer que esto funcione. Entonces, guardaré todo eso y veamos si podemos hacer que esto funcione. Entonces, solo voy a hacer una pequeña verificación. Mi aplicación todavía se está ejecutando en el front-end, así que intentaré hacer clic en esta publicación. ¿Qué tal construir una librería? Ahí vamos, funcionó. Genial, ya no tenemos latín en esta página, ¿verdad? En lugar de nuestro título en latín en el contenido ficticio. Ahora, cuando alguien visita esta URL construir una librería, están obteniendo los datos reales de la publicación de blog, por lo que fue escrito por esa persona en esta fecha, aquí está todo el contenido y cualquier categoría a la que esté asignado al final. Entonces, puedes ver que ahora tenemos dos, tutoriales en WordPress. Muy bien, eso es todo. Así que eso fue nuestra primera consulta GraphQL que aceptó un argumento. Espero que haya sido interesante ver eso y luego copiamos esto en nuestra aplicación y lo conectamos para mostrar las páginas de publicaciones de blog individuales. Entonces, eso fue, conquistamos el número siete. ¿Cómo nos sentimos? Denme algunos pulgares arriba, pulgares abajo en el chat. ¿Cómo les fue con el número siete? Excelente, veo algunos pulgares arriba. De acuerdo. Veamos, ¿cómo voy de tiempo? De acuerdo, sí, bastante bien, creo. Así que sigamos aquí. Muy bien, si todavía estás conmigo y quieres ver más acción, sigamos adelante. Veamos, de acuerdo, así que en este punto, acabamos de terminar el número siete, como dije, en la lista, ¿verdad? Implementar página de publicación de blog individual. Entonces, a continuación, debemos implementar nuestra página de categoría individual, ¿de acuerdo? Como recordatorio, al final de nuestras páginas de publicaciones de blog individuales, tenemos estos enlaces, ¿verdad? Tutoriales y WordPress. Si hago clic en tutoriales, todavía es ese contenido ficticio, ¿verdad? Todavía dice el nombre incorrecto de la categoría y tiene el contenido ficticio aquí. Entonces, vamos a conectar esto para que funcione realmente. Muy bien, de vuelta en nuestra aplicación front-end, ¿dónde necesitamos buscar esto? Eso sería dentro de las páginas y luego categoría, tenemos esta ruta dinámica de slug aquí. Entonces, si alguien intenta navegar a slash categoría slash algún slug así, eso se mapearía a este archivo, ¿verdad? Y al igual que, al igual que hemos visto muchas veces antes, estamos extrayendo el contenido ficticio y luego pasándolo a través de git static props a nuestro componente. Así que será nuestro trabajo eliminar eso. Muy bien, al igual que la última vez, necesitamos componer una consulta. Y creo que esta vez, podríamos ir aún más rápido ya que todos ustedes son expertos en este punto en GraphQL y consultas y todo eso, ¿verdad? Entonces, veamos qué podemos hacer. Entonces, vamos a definir una consulta y llamémosla git category. Entonces, ve adelante y vuelve al IDE de GraphQL conmigo y escribe consulta git category, así como así. Con algunas llaves y veamos. Sí, ¿qué tal si esta vez hacemos las variables primero ya que eso está fresco en nuestra mente desde la última vez? Esta vez, nuevamente aceptará una variable que usará para buscar la categoría. Entonces, en lugar de git category o después de git category, abriremos algunos paréntesis y diremos, vamos a aceptar, lo siento, no puedo hablar ahí. Vamos a aceptar un ID de slug así con el signo de dólar, dos puntos. Y el tipo de esta cosa es un ID con un signo de exclamación, así como así. Y luego también vamos a pasar, oh, espera aquí, hay un error. De acuerdo, para esto vamos a aceptar dos, de acuerdo, haremos slug ID y luego slug name, y eso será una cadena. Con un signo de exclamación, espera aquí. Vamos a probar algo con esta consulta, creo que podríamos simplificarla. Déjame ver, entonces la categoría, el ID es, solo voy a hacer algo de codificación en vivo aquí para ver, en realidad no necesitamos ambas variables. Creo que podemos arreglárnoslas con solo una, quiero confirmarlo rápidamente sin embargo. Entonces, el tipo de ID es slug, y luego dentro de eso, solo obtendré el nombre de la categoría. Entonces, déjame ver si puedo hacer que esto funcione con solo una variable así. Entonces, en las variables de consulta, voy a abrir algunas llaves, hago control espacio para obtener mi autocompletado, enter para slug ID. Ahora intentaré pasar un slug válido. Entonces, como tutoriales, solo lo copiaré, e intentaré usarlo como ID. De acuerdo, sí, eso funciona. Entonces creo que mi, en la base de código original, estaba pasando dos por alguna razón, pero en realidad no necesitamos hacerlo. Oh no, sí lo necesitamos. Lo siento, probablemente estoy confundiendo a todos en este punto.

17. Construyendo Consultas Anidadas de GraphQL para Categorías

Short description:

Vamos a incluir slug ID y luego slug name. Vamos a hacer get category. Vamos a pasar solo el slug ID de esta manera y luego para el slug ID, pasaremos 'tutoriales'. También necesitamos obtener las publicaciones dentro de esta categoría. Estamos creando una categoría, obteniendo el nombre de esa categoría y luego diciendo: y para las publicaciones asociadas con esta categoría, aquí está toda la información que necesitamos sobre ellas. Intentémoslo. Esto está funcionando muy bien. Tenemos el nombre del tutorial que usaremos para mostrar en la parte superior de la página para indicar a las personas de qué categoría se trata. Y luego también obtenemos nuestra matriz de nodos con la información que solicitamos aquí. Genial. Creo que esto funcionará bien. Verifiquemos en el chat. Todos están bien. Avísame si tienes algún problema con esto. Si puedes componer esta consulta, eso es exactamente lo que necesitamos. Así que volvamos a nuestra página de categoría y slug.js aquí. Y haremos uso de esto. Primer paso, al igual que la última vez, eliminaremos los datos ficticios. No los necesitamos más. Y luego justo encima de git static props aquí, aquí es donde definiremos nuestra consulta. Así que en este punto, haremos const git category. Lo llamaremos todo en mayúsculas así. Y GQL con nuestras comillas invertidas. Así que comencemos con eso. Y luego dentro de nuestras comillas invertidas, ahí es donde pegaremos todo esto. Y ahora necesitamos usarlo realmente. Ahora, necesitamos usarlo para buscar nuestra categoría. Justo debajo de esto, presionaré enter un par de veces, haré const response equals await client.query, como hemos hecho varias veces antes. Y dentro de esto, vamos a abrir nuestras llaves, y adivina qué vamos a hacer a continuación. Para la consulta que vamos a usar, vamos a decir que use esa consulta, y luego vamos a presionar enter y pasar la variable que espera. Así que diremos variables, y eso será un objeto, la variable que espera es el slug ID. Así que pasaremos slug ID, y lo que vamos a pasar es este slug que hemos extraído de los parámetros. Un mejor nombre, podríamos haber elegido llamarlo simplemente slug probablemente, podría haber sido una mejor opción para que coincida con lo que estamos extrayendo de aquí, pero nombrar es difícil, y esto funcionará muy bien porque lo que realmente se mapea es pasar como el campo ID, campo de entrada en GraphQL. De todos modos, esto debería funcionar muy bien para nosotros. Estamos pasando la consulta aquí, y luego para las variables, pasamos el slug de la página actual, ¿de acuerdo? Y al igual que la última vez, necesitamos verificar si esta categoría es válida. ¿Pudimos encontrar esta página? Así que haremos eso, muy similar a lo que hicimos la última vez. Haremos const category equals response.data.category. Si no podemos profundizar hasta el final, sabremos que no es válido y renderizaremos nuestra página 404. De lo contrario, si no es falsa, lo pasaremos a nuestro componente como props. Y eso es lo que realmente renderizaremos en la página. Creo que estamos bien con esto. Así que guardaré eso. Y veremos cómo lo hicimos. Sí, está funcionando. Ahora, cuando visito /category/tutoriales, obtengo un nombre adecuado para esta categoría que está visitando el usuario. Y luego las publicaciones dentro de ella son todas las que están en esa categoría. Bien, bien.

Veo por qué lo estaba haciendo. De acuerdo. Entonces vamos a volver a nuestros tutoriales porque tenemos una consulta anidada para las publicaciones. De todos modos, de acuerdo. Vamos a incluir slug ID y luego slug name. Espera, mentí. De acuerdo, cambié de opinión tres veces ahora. Crees que estoy loco. Lo siento. Creo que podemos usar solo la que es como un pensamiento. Entonces esto es lo que vamos a hacer. Vamos a hacer get category. Vamos a pasar solo el slug ID de esta manera y luego para el slug ID, pasaremos 'tutoriales'. De acuerdo. Entonces eso funciona para obtener el nombre de vuelta. Y ahora necesitamos obtener las publicaciones dentro de esta categoría también. Entonces, en este punto, si comienzas a escribir P O S, verás que aparece el autocompletado. Así que solo presiona enter y luego necesitaremos una subselección aquí. Así que algunos campos anidados dentro de las publicaciones. Así que abriré algunas llaves y dentro de esto, necesitamos nodos de publicaciones. Así que escribiremos nodos, abriremos eso. Volveré a presionar control espacio para obtener el autocompletado y comenzaré a escribir ID de la database. Ese es el primero que necesitamos. El siguiente es el título de la publicación. El siguiente es el extracto. Ahí vamos. El siguiente es el URI así. Y el siguiente tendremos otra subselección, que será nuestra imagen destacada. Así que si comenzamos a escribir imagen destacada allí y luego abrimos algunas llaves dentro de eso, diremos para el nodo de la imagen destacada, necesitamos dos cosas, solo la URL de origen y luego el texto alternativo. Lo mismo que la última vez que intentamos esto. Sí, solo texto alternativo así. De acuerdo, esto es bastante bueno. Así que estamos creando una categoría, obteniendo el nombre de esa categoría, y luego diciendo, y para las publicaciones asociadas con esta categoría, aquí está toda la información que necesitamos sobre ellas. Así que intentémoslo. Ahí estamos. De acuerdo, bien. Lo siento, estaba indeciso allí tratando de decidir si necesitábamos el segundo argumento, pero creo que esto funcionará muy bien para nosotros. De acuerdo, esto está funcionando muy bien. Así que tenemos el nombre del tutorial que usaremos para mostrar en la parte superior de la página para indicar a las personas de qué categoría se trata. Y luego también obtenemos nuestra matriz de nodos con la información que solicitamos aquí. Genial. Creo que esto funcionará bien. Verifiquemos en el chat. Todos están bien. De acuerdo. Así que avísame si tienes algún problema con esto. Si puedes componer esta consulta, eso es exactamente lo que necesitamos. Así que volvamos a nuestra página de categoría y luego slug.js aquí. Y haremos uso de esto. De acuerdo. Así que el primer paso, al igual que la última vez, eliminaremos los datos ficticios. Ya no los necesitamos. Y luego justo encima de git static props aquí, aquí es donde definiremos nuestra consulta. De acuerdo, así que en este punto, haremos const git category. Lo llamaremos todo en mayúsculas así. Y GQL con nuestras comillas invertidas. Así que comencemos con eso. Y luego dentro de nuestras comillas invertidas, ahí es donde pegaremos todo esto. Así que copiaremos toda esa consulta que habíamos compuesto y la pegaremos dentro de nuestras comillas invertidas. De acuerdo, y ahora necesitamos usarla realmente. Entonces puedes ver aquí una vez más, estamos profundizando en contextos y luego en params y luego en slug para extraer el slug de la URL de la página en la que se encuentra actualmente el usuario. Ahora, necesitamos usar eso para buscar nuestra categoría. De acuerdo, justo debajo de esto, presionaré enter un par de veces, haré const response equals await client.query, como hemos hecho varias veces antes. Y dentro de esto, vamos a abrir nuestras llaves, y apuesto a que puedes adivinar qué vamos a hacer a continuación. Para la consulta que vamos a usar, vamos a pasar esto que acabamos de construir, ¿verdad? Entonces, para la consulta que vamos a usar, vamos a decir que use esa consulta, y luego vamos a presionar enter y pasar la variable que espera. Entonces diremos variables, y eso será un objeto, la variable que espera es el slug ID. Así que pasaremos slug ID, y lo que vamos a pasar es este slug que hemos extraído de los parámetros. Sí, de acuerdo, sí. Un mejor nombre, podríamos haber elegido llamarlo simplemente slug probablemente, podría haber sido una mejor opción para que coincida con lo que estamos extrayendo de aquí, pero nombrar es difícil, y esto funcionará muy bien porque lo que realmente se mapea es pasar como el campo ID, campo de entrada en GraphQL. De todos modos, esto debería funcionar muy bien para nosotros. Estamos pasando la consulta aquí, y luego para las variables, pasamos el slug de la página actual, ¿de acuerdo? Y al igual que la última vez, necesitamos verificar si esta categoría es válida. ¿Pudimos encontrar esta página? Así que lo haremos, muy similar a lo que hicimos la última vez. Haremos const category equals response.data.category. Entonces intenta escribir eso, pero en caso de que fuera inválido, algunos de estos podrían ser indefinidos. Entonces, al igual que la última vez, usaremos el encadenamiento opcional. Y haremos un signo de interrogación, y luego un signo de interrogación justo aquí. Entonces, si no podemos profundizar hasta el final, sabremos que no es válido y renderizaremos nuestra página 404. De lo contrario, si no es falso, lo pasaremos a nuestro componente como props. De acuerdo, y eso es lo que realmente renderizaremos en la página. Así que creo que estamos bien con esto. Así que guardaré eso. Y veremos cómo lo hicimos. De acuerdo, así que recargaré tutoriales. Ahí vamos. Sí, está funcionando. Así que ahora cuando visito /category/tutoriales, obtengo un nombre adecuado para esta categoría que está visitando el usuario. Y luego las publicaciones dentro de ella son todas las que están en esa categoría. Hacemos una pequeña verificación, supongo, podemos abrir una publicación, desplazarnos hasta el final y luego, sí, exactamente. Así que todas estas están dentro de la categoría de tutoriales. Bien, bien.

18. Implementando la Página de Búsqueda

Short description:

Ahora pasaremos a la página de búsqueda, que es nuestra primera página que implica solicitudes del lado del cliente. Hasta ahora, hemos estado haciendo solicitudes en tiempo de compilación en el servidor de Next.js. Sin embargo, para la página de búsqueda, necesitamos hacer solicitudes de GraphQL sobre la marcha desde el navegador a nuestro backend de WordPress. Comenzaremos componiendo nuestra consulta en GraphiQL, especificando el término de búsqueda y los campos que queremos recuperar. Una vez que la consulta esté completa, pasaremos dinámicamente el término de búsqueda y realizaremos la solicitud desde el navegador. Manejaremos los casos en los que el término de búsqueda no devuelva resultados mostrando un mensaje correspondiente. Procedamos a implementar la consulta en el archivo search.js.

Eso fue todo para la página de tutoriales. ¿Cómo te sientes? ¿Puedo obtener algunos pulgares arriba, pulgares abajo de todos? Bien. Pulgares arriba, gracias. Muy bien, genial. Gracias. Muy bien. Me siento bien. Hemos logrado mucho, ¿verdad? En un período de dos horas o algo así, hemos creado nuestra página de índice de blog, nuestra página de publicación única, nuestra página de categoría única, y aún no hemos terminado. Lo siguiente es la página de búsqueda. Así que esta debería ser divertida, como dije, porque es nuestra primera página en la que hacemos solicitudes del lado del cliente. Es la primera en la que hacemos solicitudes del lado del cliente. Hasta este punto, solo hemos estado haciendo solicitudes en tiempo de compilación. Dentro de, ya sabes, git static props aquí que proporciona Next.js, hemos estado enviando consultas, ya sabes, en tiempo de compilación en el servidor de Next.js, cuando la página se está pre-renderizando, se está construyendo. Ahí es cuando hemos estado enviando nuestras solicitudes de datos, pero para la página de búsqueda, no podemos hacer eso, ¿verdad? No sabemos qué término de búsqueda va a intentar el usuario de antemano. Así que tenemos que hacer solicitudes de GraphQL sobre la marcha desde el navegador para acceder a nuestro backend de WordPress y luego volver a representar la lista. Así que esto debería ser interesante para ver cómo funciona. Muy bien, entonces nuestra primera página, nuestra página de búsqueda, cerraré mis pestañas abiertas aquí en VS Code, y luego, para recordarnos, volveremos a la página de búsqueda, veremos cómo se ve. Así que esta es la página, y nuevamente, como vimos la última vez, actualmente no funciona. Intentamos enviar el formulario. Todos estos datos se mantienen sin cambios. Así que dentro de las páginas, abriremos search. Ahí está. Y lo haremos funcionar. Compongamos nuestra consulta primero. Creo que eso será útil. Muy bien, como antes, volvamos a GraphiQuel. Así que podemos borrar nuestras variables de consulta y nuestra consulta aquí. Así que no las necesitaremos más. A continuación, vamos a hacer una nueva para las búsquedas. Así que hagamos esto. Escribe la palabra consulta y luego escribe el tipo de búsqueda de publicaciones. Así, consulta de búsqueda de publicaciones. Esta espera un argumento, por supuesto, necesitamos el término de búsqueda del usuario que quieren usar. Así que haré signo de dólar, término de búsqueda, dos puntos. Y luego el tipo de variable que queremos aceptar aquí es una cadena. Así que escribimos S mayúscula, cadena, y queremos decir que es obligatorio para que esta consulta pueda ejecutarse. Así que agregaré el signo de exclamación para indicarle a GraphQL que esto debe pasarse. Muy bien, con eso, abriremos unas llaves y luego en el siguiente nivel, vamos a consultar las publicaciones y usar ese término de búsqueda. Así que comenzaré a escribir publicaciones aquí. Y dentro de esos paréntesis, necesitamos usar nuestro argumento where. Hay otras opciones aquí para hacer paginación, como mencioné, podrías hacer, dame las primeras 10 después de esta otra publicación o lo que sea, hacer paginación basada en cursor. Sin embargo, vamos a hacer uso del argumento where, que se utiliza para filtrar las publicaciones y decir en lugar de todas ellas, filtrar solo la publicación en esta categoría o que coincida con este término de búsqueda o lo que sea. Así que haremos eso. Ahora haremos where, dos puntos, y esto es un objeto aquí. En lugar de where, que espera un objeto. Dentro de aquí, aquí están todas las formas en que podrías filtrar una publicación. Para nosotros, lo haremos por búsqueda. Así que si empiezo a escribir eso, se autocompletará. Búsqueda, dos puntos, y este es el punto en el que queremos que nuestra consulta sea dinámica y pasar ese término de búsqueda que el usuario nos ha dado. Así que para la búsqueda aquí, pasaremos el término de búsqueda. ¿De acuerdo? Y luego a partir de ahí, necesitamos unas llaves después de las publicaciones. Y aquí nos adentraremos en los nodos. Abre más llaves. En este punto, necesitamos algunos de nuestros campos. El primero es ID de la base de datos. El siguiente es el título, así que escribe título. El siguiente es el extracto. El siguiente es el URI. El siguiente es la imagen destacada. Y esto tiene subselecciones, haremos una llave y luego para el nodo de esa imagen destacada, al igual que la última vez, haremos URL de origen y texto alternativo. Y solo una nota al margen aquí. Es posible que estés mirando estos campos y pensando, hombre, los hemos escrito tantas veces. Esta imagen destacada que siempre tiene un nodo y siempre tiene una URL de origen y un texto alternativo, ya lo hemos escrito como tres veces diferentes, ¿verdad? Parece que hay algo de repetición allí. Y tienes razón, la hay. Y ahí es donde más adelante en el taller, entraremos en el uso de fragmentos de GraphQL. Eso es lo que pueden ayudar a resolver. Es donde tienes parte de una consulta, en algún lugar de tu base de código lo has definido como un fragmento, y luego lo insertas en los puntos dentro de otras consultas donde quieres usarlos. Así que mantente atento para ver cómo puedes reducir algo de la repetición en tus consultas. Muy bien, esto debería ser suficiente, creo. ¿Si intento enviar esto, funcionará? La respuesta es no, ¿verdad? Porque no hemos proporcionado este término de búsqueda que espera aquí. Así que en las variables de consulta, abriré unas llaves, presionaré Control Espacio para obtener el autocompletado y me dirá que cree que quiero término de búsqueda, lo cual es correcto. Y aquí, esto es realmente libre, ¿verdad? Esto es bastante divertido porque podemos buscar cualquier cosa en este punto. Así que el punto final de GraphQL que estamos usando es para un blog de WPGraphQL y probablemente hablen sobre temas interesantes de WordPress sin cabeza como React, ¿qué tal? Así que escribiré React aquí, eso es lo que vamos a buscar y lo enviaré. Ahí vamos, mira, la primera publicación, crear una aplicación usando React y el complemento de API de GraphQL para WordPress, ¿verdad? Resulta que es una publicación escrita por mí en el blog de WPGraphQL. Así que esto es genial. Nuestra búsqueda funciona para encontrar publicaciones con React. Podemos intentar encontrar casos extremos como qué pasa si solo escribo un montón de palabras sin sentido y trato de buscar aquí. Ahí vamos. Sigo obteniendo una respuesta exitosa, pero los nodos que regresan son solo una matriz vacía. Así que tengo que tener eso en cuenta en nuestro front-end y decir, ya sabes, si ejecutamos la búsqueda y los nodos están vacíos, tal vez mostrar un mensaje que diga que no se encontraron resultados, ¿verdad? Pero para otros temas, hagamos algo como GraphQL o algo así. Para otros temas, parece funcionar muy bien para encontrar las coincidencias. Así que esto es genial, eso es exactamente lo que necesitamos. Podrías componerlo así si te gusta que la búsqueda esté en una línea separada o podrías ponerlos en la misma línea si prefieres ese aspecto. Pero de cualquier manera, esta es la consulta que necesitamos. Así que vayamos a hacer uso de eso dentro de search.js. Eliminaremos nuestros datos ficticios como de costumbre al principio aquí y definiremos nuestra nueva consulta.

19. Implementando la Búsqueda Dinámica con Apollo Client

Short description:

Vamos a utilizar el hook useQuery de Apollo Client para ejecutar la consulta en el lado del cliente. Pasaremos la consulta y las variables necesarias, como el término de búsqueda. El hook useQuery se encargará de los estados de carga, error y datos por nosotros. Renderizaremos la lista de publicaciones en función de los datos obtenidos de la consulta. Si hay un error, mostraremos un mensaje de error. Si no se encuentran publicaciones, mostraremos un mensaje correspondiente. El usuario puede enviar el formulario para buscar publicaciones basadas en el término de búsqueda ingresado. El hook useQuery recuperará los datos en función del nuevo término de búsqueda y provocará una nueva representación de la lista de publicaciones. Hemos implementado una página de búsqueda funcional que permite a los usuarios buscar publicaciones basadas en un término especificado.

Entonces haremos const, lo llamaremos searchPost. O posts, quiero decir, todo en mayúsculas así igual a GQL. Ya sabes cómo funciona esto a estas alturas y luego dentro de nuestras comillas invertidas es donde vamos a pegar nuestra consulta que construimos. Así que copia eso, pégalo, ahí vamos. Y ahora vamos a hacer uso de esto pero no lo haremos en tiempo de compilación. Como dije, si te fijas en este archivo no hay get static props. Eso es porque no lo necesitamos. Vamos a ejecutar estas consultas sobre la marcha desde el cliente. Para hacer eso, vamos a usar un hook que proporciona Apollo client. Así que por eso aquí arriba estamos importando este hook useQuery de Apollo client. Tienen su propia documentación. Si buscas en la documentación de Apollo client tienen useQuery, useLazyQuery, useMutation y toda la documentación sobre cómo usar esos hooks. En este taller te familiarizarás con el uso del más común que es el useQuery para ejecutar solicitudes de GraphQL en el lado del cliente. Así que eso es lo que vamos a usar. Te mostraré cómo en lugar de nuestro componente en lugar de tener estos datos ficticios, decíamos que const loading siempre es falso. Const error siempre es falso. Y luego para los datos pasábamos nuestros datos ficticios, en lugar de todo esto vamos a usar los valores reales, ya sabes los valores reales de carga, error y datos que el hook useQuery de Apollo nos devuelve. Así que vamos a eliminar todo esto y en su lugar usaremos query. Entonces, ¿qué pasó ahí? Ok, así que comienza escribiendo const y luego vamos a desestructurar algunas cosas que vamos a obtener de useQuery. Así que vamos a hacer, vamos a extraer ese estado de carga, vamos a extraer un error si lo hubiera y luego vamos a intentar acceder a los datos. Esas tres cosas vamos a desestructurar y extraer de los resultados de nuestra llamada al hook useQuery. Oops, ahí vamos, así. Muy bien, y luego useQuery acepta dos argumentos. El primero es la consulta y el segundo son las opciones que quieras definir. Así que para nosotros, si nos desplazamos hacia arriba, nuestra consulta es search posts, ¿verdad? Ese es el nombre, copiaré el nombre de esa constante y lo pegaré aquí. Así que le diré a useQuery qué consulta ejecutar. Y ahora necesitamos pasar el array de opciones para decirle acerca de nuestras variables que necesitamos. Así que abre unas llaves justo así y dentro de ellas, haremos variables, dos puntos y abriremos un objeto dentro de aquí. Necesitamos proporcionar el término de búsqueda. Así que lo que vamos a hacer es almacenar ese término de búsqueda en el estado de React así te mostraré cómo funciona en un minuto pero así que copiaré término de búsqueda y eso es lo que vamos a pasar a nuestra consulta justo aquí como término de búsqueda. Otra cosa que vamos a poner aquí es este notifyOnNetworkStatusChange que viene con Apollo. Eso es mucho para escribir, pero si comienzas a escribir N-O-T debería aparecer para ti. Lo vamos a establecer en verdadero, muy bien. Y la razón de esto es si no lo estableces en verdadero, Apollo solo establecerá loading en falso la primera vez que se ejecute la consulta. Sé que es extraño, pero así es como funciona. Así que si ejecutas la consulta una vez, loading será verdadero mientras se resuelve y luego se establecerá en falso. Y luego a partir de ese momento, si vuelves a ejecutar la misma consulta y pasas diferentes variables, loading se mantendrá en falso a menos que hagas esto. A menos que digas notifyOnNetworkStatusChange verdadero entonces loading alternará entre verdadero y falso cada vez que es lo que queremos. Sé que es una peculiaridad extraña pero por eso se especifica aquí. Muy bien, eso es todo. Así que nuestro hook useQuery le dirá a Apollo que ejecute esta consulta en el cliente y le estamos pasando la consulta y las variables que necesitamos y obteniendo todos estos valores de carga, error y datos ahora. Muy bien, debajo de esta línea de posts debería seguir funcionando bien. Puedes ver lo que estamos haciendo aquí estamos tratando de profundizar en data.posts.nodes.length y lo estamos convirtiendo en un booleano. Así que si data es indefinido en algún punto aquí y eso se convertiría en falso. Así que no tenemos publicaciones o si la longitud está vacía, ¿verdad? Recuerda cuando ejecuté esa consulta y pasé una palabra sin sentido donde la matriz de nodos estaba vacía. Si ese es el caso donde post.nodes.length es una longitud de cero, entonces en ese caso have posts también será falso, ¿verdad? Ya que no tenemos ninguna, de lo contrario, si profundizamos en este nivel y la longitud es verdadera cuando la convertimos en un booleano como uno, dos, tres, u otro entero positivo entonces have posts será verdadero allí. Y vemos más abajo donde lo estamos usando. Así que veamos esta página real por un momento y veamos cómo funciona esto. Así que ya viste en la parte superior, estamos usando useState de React, pasando una cadena vacía. Así que decimos cuando este componente se carga por primera vez, no hay término de búsqueda, ¿verdad? Solo mantenlo vacío. Y luego estamos extrayendo de eso, el término de búsqueda actual y luego la función que necesitamos para poder establecerlo. Estamos proporcionando al usuario este formulario aquí en la parte superior de la página donde deberían poder escribir algo. Y luego cuando hacen clic en buscar, tenemos un controlador de envío aquí. Decimos cuando la persona escribe algo y luego envía el formulario, estamos proporcionando el envío de formulario predeterminado en la web. Estamos usando estos datos de formulario que están integrados en la plataforma web aquí. Solo decimos que queremos nuevos datos de formulario para este elemento en particular, o para este elemento HTML que se envió, estamos extrayendo los datos de eso y luego hacemos object.fromEntries para extraer cada uno de los valores individuales de los campos, que en nuestro caso es este aquí el campo de búsqueda. Y una vez que hemos hecho eso, hemos extraído los valores. Estamos profundizando en el valor del término de búsqueda y llamando a nuestra función set search term aquí que obtuvimos de useState para establecer eso ahora como el nuevo valor del término de búsqueda. Tan pronto como hagamos eso, tan pronto como se establezca en el nuevo valor, React volverá a representar este componente y la variable del término de búsqueda será nueva, ¿verdad? Se actualizará y reflejará este, el nuevo término de búsqueda. Y luego Apollo verá eso en su nuevo useQuery aquí, verá todo este valor del término de búsqueda es este nuevo valor después de que ocurra la nueva representación, mejor voy a buscar estos datos y luego proporcionar los nuevos estados de carga, error y datos ahora. Sí, eso es cómo funciona todo eso. El usuario envía el formulario, lo que establece el término de búsqueda en algo nuevo. Y luego el useQuery dispara una solicitud utilizando esa nueva cosa. Y eso provoca una nueva representación de nuestra lista de publicaciones aquí. Muy bien, y luego debajo de eso, solo tenemos para fines de visualización, tenemos algunas opciones, así que decimos, ¿estamos cargando actualmente el mensaje de carga? o ¿tenemos actualmente un error para decir que se ha producido un error? Podrías hacer un manejo de errores más robusto aquí, por supuesto, y deberías investigar como error.message y mostrar el error real que se devolvió. Para nosotros, simplemente diremos que se ha producido un error, cara triste. Si no tenemos publicaciones, entonces decimos no se encontraron publicaciones, o finalmente, si llegamos hasta aquí, entonces sabemos que no estamos cargando, no hay error y tenemos publicaciones, ¿verdad? Así que si llegamos hasta aquí, vamos a intentar representar nuestra lista de publicaciones y pasarlas ahí. Muy bien. Así que con toda esa explicación, guardaré esto y espero lo mejor. Hooray. Creo que está funcionando. Muy bien. Así que cuando esta página se carga por primera vez, así es como se ve ahora con nuestra página de búsqueda funcional. Así que cuando esta página se carga por primera vez, ves que obtenemos una carga momentánea. Y luego aparecen los resultados. Podrías hacer algunas cosas allí. Podrías obtener la lista predeterminada de antemano en el servidor y mostrar eso hasta que el usuario realice su primera consulta y luego cambiarlo por los resultados o algo así para evitar esa carga momentánea o simplemente no mostrar ningún resultado hasta que realicen una búsqueda, ¿verdad? Podrías hacer eso de varias formas diferentes. Pero lo tenemos configurado ahora. Tan pronto como se monta el componente, obtiene las publicaciones utilizando el término de búsqueda actual, que en nuestro caso es una cadena vacía, ¿verdad? Así que solo busca todas las publicaciones. Aquí están los resultados, así que intentemos actualizar esto ahora. Si escribo, si escribo la palabra React buscar carga, y ahí está, obtengo los resultados de React. Eso es genial. Si escribo mi cadena sin sentido nuevamente, ya sabes, algo así, buscar, no se encontraron publicaciones como se esperaba así. Esto es genial. Ahora tenemos nuestra página de búsqueda funcional. Muy bien, así que me detendré aquí y revisaré el chat. Ver cómo estamos. Oh, Patricia, sí, absolutamente. Lamento que hayas tenido que esperar tanto tiempo por esto.

20. Apollo Client y Políticas de Caché

Short description:

Tenemos una página de búsqueda funcional que permite a los usuarios buscar publicaciones basadas en un término especificado. Las Apollo DevTools pueden ser útiles para verificar la caché y componer consultas sobre la marcha. WPGraphQL se puede ampliar para integrarse con otros complementos de WordPress, como campos personalizados avanzados y Yoast SEO. Apollo Client te permite definir políticas de caché para personalizar el almacenamiento en caché en tu aplicación JavaScript. Las políticas de recuperación, como caché primero, solo caché, caché y red y solo red, brindan flexibilidad en cómo manejas la caché.

¿Dijiste que podría mostrar el código una vez más para la respuesta? ¿Eso fue para nuestro componente de búsqueda o el... Probablemente no, ¿verdad? Eso habría sido el anterior, la página de categoría. ¿Fue esta? Sí, lo siento por eso. Si pasé por eso un poco rápido. Genial, lo tienes, gracias. Sí, me detendré en este punto para recordar al grupo. Si en algún momento sientes que te quedaste atrás o no escribiste algo lo suficientemente rápido u otra cosa, tenemos estos puntos de control, ¿verdad? Entonces, en este punto, acabamos de terminar la página de búsqueda. Entonces, si quieres ponerte al día con nosotros en este punto, solo tienes que escribir Git checkout con este hash de confirmación justo ahí en tu base de código hasta el punto actual. Y luego, si algo está mal después de ese punto solo puedes presionar Control-C para detener tu aplicación de Next.js y luego npm run dev para volver a ejecutarla y luego deberías estar listo junto con el resto del grupo en ese punto. Muy bien, tenemos una página de búsqueda funcional, así que ahora sabes cómo se ve ejecutar consultas desde el cliente, lo cual es genial. Sí, incluso podemos ver eso, solo para emocionarnos por un minuto en nuestra página de búsqueda aquí. Sabes, incluso puedes ir a la red y puedes mostrar todo o decirle que lo filtre por solicitudes de recuperación y puedes ver cada una de estas solicitudes de GraphQL. Entonces, nuevamente, si escribo, prueba o búsqueda de React. Oh, ¿sabes por qué? Entonces, esta es en realidad una buena lección. No vi una solicitud de red. ¿Quién sabe por qué? ¿Alguien puede decírmelo en el chat? Por alguna razón, no tuve que enviar una solicitud al servidor. Sí, exactamente. Sí, veo a la gente diciendo caché. Eso es exactamente correcto. Así que tengo las Apollo DevTools instaladas aquí. Entonces, si voy a Apollo y luego busco publicaciones, puedes ver, aquí está la consulta. Y si voy a datos de caché, puedes ver lo que Apollo ha almacenado en caché. Sí, aquí está. Entonces, Apollo ha almacenado en caché los datos para esta consulta y ya está en la caché de memoria. Entonces, cuando escribí React y hice clic en buscar, simplemente verificó su caché y vio, oh, tengo estos siete nodos de publicación aquí ya en mi caché de veces anteriores, de veces en que esta misma consulta se ejecutó previamente. Los voy a devolver de inmediato. Por eso no hubo ningún cargador en absoluto y apareció de inmediato y tampoco hubo ninguna solicitud de red en absoluto al backend para esa. Así que eso fue genial. ¿Qué pasa si hago algo que no hemos buscado? ¿Qué pasa si escribo ver o algo así, buscar? Entonces ahora ves que hay una solicitud de GraphQL real aquí. Es bastante interesante, puedes ver cómo se ve. Y luego aquí está el encabezado que se envió. Entonces aquí está la carga útil que se envió. Es interesante, puedes ver el nombre de la operación, la consulta, que es toda esa cadena que proporcionamos y luego las variables, que eran las variables que pasamos. Y luego puedes ver la respuesta que vuelve y ver que es data, nodos de publicaciones. Está en la misma forma nuevamente que definimos cuando escribimos la consulta. Está en la misma forma aquí cuando vuelve. Sí, es bastante interesante. Entonces, si eres alguien que quiere trabajar con esta pila, es posible que desees consultar las Apollo Dev Tools. A veces pueden ser útiles para ver lo que está actualmente en la caché. E incluso puedes componer y ejecutar consultas sobre la marcha aquí para probar rápidamente cosas o lo que sea. Así que eso puede ser bastante útil. Además de prestar atención a las solicitudes de red aquí. Si estás haciendo algo del lado del cliente como esto, puedes ver cuándo se envían las solicitudes y cómo se ven esas cargas útiles cuando se envían. Cosas divertidas, muy bien, vuelvo a mirar el chat nuevamente. Veamos. Entonces, Victor, ¿podemos consultar datos a través de GQL de la misma manera para complementos en WordPress? Sí, absolutamente puedes. Si están en el esquema de GraphQL, ese sería el inconveniente. Entonces, si vas a wpgraphql.com y luego haces clic en extensiones aquí, dice que WPGraphQL se puede ampliar para integrarse con otros complementos de WordPress. Aquí hay una lista de complementos de extensión de WPGraphQL. Muchos de estos complementos son mantenidos por contribuyentes de la comunidad. Entonces, aquí puedes ver algunos populares. Entonces, alguien mencionó campos personalizados avanzados, ¿verdad? Uno de los complementos más populares en todo el espacio de WordPress, que en realidad, anunciaron ayer, fue adquirido por mi empresa, WP Engine, acaba de comprar campos personalizados avanzados, así como varios otros complementos que Delicious Brains había estado manteniendo. Pero de todos modos, aquí hay una extensión de WPGraphQL 4 campos personalizados avanzados. Entonces, lo que necesitas hacer es instalar dos cosas. WPGraphQL en sí mismo y luego esta extensión, siempre y cuando hagas ambas cosas y las tengas activadas, entonces proporciona algunas características nuevas en la interfaz de usuario para ACF donde puedes definir un grupo de campos, ya sabes, con todos tus campos en él, y hay una casilla de verificación en la parte inferior que dice, exponer en GraphQL. Entonces, si marcas eso, ya sabes, y luego guardas tu grupo de campos, en ese momento agrega, ya sabes, esta extensión agrega todos los campos de ACF al esquema de GraphQL. Entonces, cuando estás en GraphiQL como esto y estás, ya sabes, tratando de consultar los datos sobre publicaciones, solo verías todos los campos de ACF, los verías, ya sabes, estarían allí a tu disposición. Sí. Entonces eso está ahí para ACF y varias otras cosas. Hay Ninja Forms, WooCommerce, Gravity Forms, ya sabes, varias otras cosas. Entonces puedes consultar esa lista si es útil. Sí, de nada. Veamos. Sí. Yoast SEO, ese es otro. Yoast se usa en casi todos los sitios de WordPress, ¿verdad? Si estás en el espacio de WordPress, sabes lo prevalente que es. Sí. Ash Hitchcock, que es muy activo, construye muchos sitios de Gatsby para sus clientes, lo sé. Construyó una extensión de Yoast SEO para WPGraphQL que muchas personas usan. Entonces, Yoast también está en la lista. Sí. Veamos. Entonces, Stefan, estás preguntando, ¿cuánto tiempo se mantiene en caché la data? ¿Hay alguna forma de borrar la caché desde el backend cuando hacemos un cambio en el CMS? Sí. Excelente pregunta. Apollo Client te permite definir políticas de caché. Sí. Entonces, te brinda todo tipo de opciones. Puedes personalizar cómo quieres hacer el almacenamiento en caché. Sí. Podemos pasar un minuto revisando esto si queremos. Personalización de IDs. Estoy tratando de recordar dónde, dónde está la página. Veamos. Política de caché de Apollo Client, creo que el nombre de algunas de ellas es como Network, creo que el nombre de otra es caché primero. Política de recuperación, ahí vamos. Lo estaba llamando política de caché, en realidad se llama Política de recuperación. Sí, veamos, Políticas de recuperación admitidas. De acuerdo, aquí vamos. Sí, lo que puedes hacer en tu aplicación de JavaScript si estás trabajando con Apollo Client, es definir qué política de recuperación quieres usar, por lo que puedes hacer Cache first, que le dice a Apollo que consulte primero la caché y luego recurra a la red, Solo caché, que es la única que siempre usas, Caché y red, solo red.

21. Caching, Invalidez de Caché y Fragmentos

Short description:

Apollo Client ofrece opciones para el control de caché y la invalidez de caché. Puedes controlar la caché con políticas de recuperación y especificar cuánto tiempo se debe almacenar en caché los datos. La invalidez de caché se puede hacer volviendo a ejecutar consultas después de una mutación. La función de regeneración estática incremental de Next.js permite servir páginas obsoletas mientras se regeneran en segundo plano. Si WordPress está inactivo, Next.js puede recurrir a servir páginas en caché. Sin embargo, algunas funciones dinámicas como la búsqueda pueden no funcionar en esos casos. Los fragmentos en GraphQL permiten colocar las necesidades de datos del componente junto con el propio componente, mejorando la organización y reutilización del código.

Entonces, si haces esto, y básicamente le dices a Apollo que nunca almacene en caché nada con los datos más recientes, ya sabes, no lo almacenes en caché en absoluto. Puedes hacer eso, sin caché, o en espera. Hay algunas opciones diferentes allí. Entonces, así es como puedes tener cierto control sobre, ya sabes, qué está en caché, y así sucesivamente, y durante cuánto tiempo. Hay algunas opciones para eso. Más allá de eso, sin embargo, estás preguntando sobre la invalidez de caché, ¿verdad? Es como, bueno, si algunos datos han cambiado, ¿cómo puedo borrar la caché, ya sabes, y decirle a Apollo que lo vuelva a buscar? Y también puedes hacer eso. Entonces, eso sería como cuando haces una mutación. Veamos si podemos encontrar la documentación rápidamente. Veamos. Sí, aquí vamos. Entonces, volver a ejecutar consultas o volver a buscar después de una actualización. Sí, puedes hacer esto si tienes una mutación que estás haciendo en tu aplicación JavaScript amiga donde el usuario está agregando una tarea en este caso o haciendo alguna actualización en los datos. Puedes decirle a Apollo client, después de que se ejecute esta mutación, ya sabes, ejecuta esta función de devolución de llamada. Le das una función de devolución de llamada y dices, que quieres, ya sabes, volver a buscar algo en particular. Obtienes una consulta específica y dices después de esta mutación, se ejecuta, agregaste una tarea, y vuelve a buscar esta consulta aquí, que es responsable de obtener la lista de tareas, ¿verdad? Entonces, si haces eso, entonces sabe, está bien, volveré a buscar esa lista. Y luego react volverá a representar la lista de tareas para mostrar, ya sabes, la lista actualizada, que incluye la nueva que acaban de agregar. Y luego puedes decir, está bien, tengo mi consulta. Sé que la volveré a ejecutar. Y luego sigo adelante y volveré a representar la lista que acaban de agregar a la lista. Entonces, puedes hacer cosas como esas. Si es el propio usuario, como hacer mutaciones, puedes decirle a Apollo client que borre parte de la caché o vuelva a buscar parte de la caché para que obtenga los nuevos datos allí. En cuanto a cualquier otra caché de solo datos del servidor, eso lo puedes controlar con las políticas de recuperación. Entonces, si quieres buscar solo políticas de recuperación y ver eso, esa página que habíamos visto, así es como lo controlarías. Muy bien, creo que estamos bien entonces. ¿Cómo vamos de tiempo? Podemos adentrarnos en nuestros fragmentos si todavía tenemos tiempo. Creo que nos quedan 30 minutos. Sí, de nada Stefan, espero que haya sido útil. Sus documentos son realmente muy buenos. Encontré los documentos de Apollo. Si ves que me adentro en ellos, generalmente puedes encontrar tu respuesta. Muy bien, entonces en este punto podríamos adentrarnos un poco en los fragmentos, a menos que vea en el chat que el grupo quiere ir a otros temas en los que estoy feliz de usarlo. Tengo un tema. Bien, ¿qué sucede cuando WordPress está inactivo? Esta es una pregunta interesante. Sí, si estás haciendo esta arquitectura desacoplada que se ve así, ¿verdad? Es una buena pregunta. Como, bueno, ¿qué pasa si Next.js intenta usar esta capa de API para contactar a WordPress y obtener datos? WordPress está inactivo, ¿verdad? El servidor no está ahí. Entonces esto se puede manejar de varias formas. Una forma es en Next.js, si estás usando su función de regeneración estática incremental para regenerar tus páginas en un intervalo de tiempo, si no puede regenerar la página, simplemente seguirá sirviendo la página obsoleta, lo cual es una característica realmente genial. Entonces puedes decirle a Next.js, y si no estás familiarizado, si simplemente buscas la regeneración estática incremental de Next.js. Si buscas eso, si no estás familiarizado te explicará qué es eso. Pero básicamente le dices a Next.js, quiero que esto sea una página estática, pero solo debe durar un cierto tiempo, puedes especificar y decir, regenerar cada 10 minutos, cada hora, una vez al día, lo que quieras. En ese intervalo, Next.js seguirá, sigue un modelo de obsoleto mientras se valida, donde si llega una solicitud y se da cuenta de que la página ya no es válida, ya sabes que ha transcurrido ese tiempo. Seguirá sirviendo esa página obsoleta a ese último usuario. Pero luego en segundo plano, iniciará el proceso para volver a buscar los datos y regenerar esa página. Tan pronto como esté disponible la nueva versión de la página, reemplaza la nueva por la antigua. Entonces, cualquier visitante nuevo que llegue al sitio obtendría esa nueva versión de la página en caché. Entonces, para ellos, sigue siendo una respuesta muy rápida, ya sabes, como si fuera una página estática, pero puedes agregar algo de dinamismo allí y actualizar en intervalos utilizando esta función. Pero de todos modos, si estás haciendo ese tipo de cosas, Next.js no reemplazará la página en caché por la nueva si no puede realizar ninguna recuperación de datos. Entonces, esa sería una solución a esto. Entonces, si WordPress está inactivo y Next.js está intentando, ya sabes, comunicarse con WordPress y regenerar la página para una publicación de blog o lo que sea, y no puede, está bien. Seguirá sirviendo la página obsoleta hasta, ya sabes, en un momento posterior cuando WordPress vuelva a estar en línea y lo intente nuevamente en ese momento, simplemente comenzará a regenerar las páginas nuevamente. Entonces, esa es una solución realmente genial y sólida donde puedes hacer que tu aplicación de front-end simplemente vuelva a las páginas en caché, ya sabes, cuando tus fuentes de datos en nuestro caso, WordPress, están inactivas. Entonces, esa es una solución genial. No maneja todos los casos, por supuesto, como nuestra página de búsqueda, ¿verdad? Si alguien va a la página de búsqueda e intenta realizar una búsqueda y WordPress está inactivo en ese momento, entonces, por supuesto, no podemos, ya sabes, no podemos hacer mucho al respecto porque necesitamos los datos reales, ya sabes, de WordPress. Entonces, lo mejor que puedes hacer allí es fallar de manera elegante, ¿verdad? Como en nuestra página de búsqueda, simplemente tenemos, si ocurre un error, en nuestro caso, Apollo llamaría a esto un error de red, como si intentara enviar la solicitud a la API del backend y obtuviera, ya sabes, un error 500 o si estaba fuera de línea o cualquier otra cosa. Entonces, simplemente te caes, ya sabes, y fallas de manera elegante y dices, lo siento, no se pueden realizar búsquedas en este momento o lo que sea y simplemente muestra un mensaje así. Entonces sí, definitivamente una preocupación real si WordPress está inactivo, pero sí, hacer la representación estática de las páginas realmente puede salvarte a veces de que sea un problema. Sí, buena pregunta ahí. De acuerdo. Podemos adentrarnos en algunas consultas o en algunos fragmentos por un rato entonces. Los fragmentos de GraphQL son realmente geniales. Permíteme mostrarte qué son a grandes rasgos. Entonces, digamos que, así que teníamos esta consulta de búsqueda de publicaciones que habíamos compuesto, ¿verdad, así como eso? Lo que podemos hacer con los fragmentos es dividir esto y definirlo en otros lugares. Permíteme mostrarte a qué me refiero. Entonces, si puedo escribir fragmento y le daremos un nombre. Entonces esto será, así que el fragmento de la imagen destacada. Probablemente voy a equivocarme en la sintaxis de esto. Quiero engañarme a mí mismo. Obtén mi hoja de trucos para poder ver mi propia aplicación en la sintaxis aquí. Mira la lista de publicaciones, oh sí. Tuve que refrescarme en la sintaxis. Entonces, la imagen destacada es un fragmento donde vamos a definir, y en realidad, vamos a hacer uno diferente que realmente usaremos en nuestra aplicación. Entonces, esta especie de ficticio que iba a hacer en la página de búsqueda, vamos a sumergirnos en eso y comenzaremos con los reales en la página del blog, ¿qué tal? Muy bien, en nuestra aplicación, limpiemos las cosas, comencemos de nuevo. En nuestra aplicación, vamos a ir a la página del blog, oh no, sí, hay una barra diagonal blog. La página de la barra diagonal blog así. Muy bien, esta es la que obtuvimos las primeras 18 publicaciones y las mostramos en una cuadrícula, ¿verdad? Esta, digamos que estos nodos aquí, no queremos que estos datos vivan aquí porque en realidad, si miras este componente, ¿cuánto de esos datos le importa? Ninguno, ¿verdad? Simplemente obtiene las publicaciones y las envía directamente al componente de la lista de publicaciones. Este componente en realidad no le importa todos los campos que estamos definiendo aquí. La única razón por la que los estamos poniendo en este archivo es porque eventualmente necesitamos esos datos aguas abajo para el componente de la lista de publicaciones. Entonces, un patrón realmente poderoso es colocar las necesidades de datos de tus componentes junto con el propio componente. Entonces, lo que podrías hacer es crear algunos fragmentos para que estos datos vivan y se definan tal vez con el componente de la lista de publicaciones, si es el que se preocupa por esos datos o de lo contrario con el componente de la tarjeta de publicación. Ya que es el que se preocupa por algunos de esos datos, ¿por qué no definir un fragmento en el mismo archivo donde definimos los campos que necesitamos y luego inmediatamente debajo de él dentro del componente, seguir adelante y destruirlo y usar esos mismos campos. Como, ¿no sería eso más agradable, una base de código más organizada para nosotros, ¿verdad? Y eso es lo que te permiten hacer los fragmentos. Entonces, podemos hacer eso, como con la página del blog y luego la lista de publicaciones y luego la tarjeta de publicación. Entonces comenzaré con, como la tarjeta de publicación ya que es la más detallada, supongo. Eso es como, no se muestra nada más. Simplemente se muestra en la lista de publicaciones, que a su vez se muestra en los blogs.

22. Creación de Fragmentos en GraphQL

Short description:

En esta sección, aprenderemos cómo crear fragmentos en GraphQL. Los fragmentos nos permiten definir los campos específicos que necesitamos para los requisitos de datos de un componente. Definiremos un fragmento llamado 'campos de tarjeta de publicación' para el tipo 'publicación', especificando el título, extracto, URI e imagen destacada. Al utilizar fragmentos, podemos organizar las necesidades de datos de nuestro componente en un archivo separado y realizar cambios fácilmente en los campos sin salir del archivo. También exploraremos cómo utilizar el fragmento en una consulta mediante la propagación de los campos utilizando la sintaxis de los tres puntos. Este enfoque mejora la organización y reutilización del código.

Comencemos con la tarjeta de publicación. Te mostraré a qué me refiero creando estos fragmentos. Esto es lo que harías, como arriba de esta cosa, harías, así que exportaremos una constante desde este archivo. Haremos export const y cualquiera de ustedes que quiera probar los fragmentos, pueden escribir esto junto conmigo, lo trabajaremos juntos. Es como, tenemos las otras páginas. Así que hago export const y luego en mayúsculas, haremos campos de tarjeta de publicación así GQL. Nuestra canción y baile habitual así. En lugar de definir una consulta aquí dentro, ahora, sin embargo, vamos a definir un fragmento. Así que vamos a escribir fragmento campos de tarjeta de publicación así en publicación. Esto es, la especificación de GraphQL dice que si quieres definir fragmentos, debes decirle a GraphQL en qué tipo se encuentra. Así que estamos diciendo que hay este tipo en el esquema de GraphQL llamado publicación y los campos que vamos a definir son los campos que nos gustaría obtener en ese tipo, si tiene sentido. Si no estás seguro de qué son estos tipos, puedes verlos en la documentación aquí mismo. Así que si hago una consulta para obtener publicaciones y obtener los nodos y luego para cada uno de ellos, obtengo el título o algo así. Digamos que esta es la consulta que he compuesto aquí y te preguntas, ¿qué tipos de GraphQL están detrás de esto aquí? Si haces clic en publicación, se abrirá la documentación aquí mismo o nodos, puedes ver que nodos es una matriz de este tipo publicación, con P mayúscula, en el esquema de GraphQL. Y si haces clic en eso, entonces eso a su vez te diría, bien, el tipo publicación, aquí está toda la información dentro de él, autor, categoría, etc. Así es de donde viene esto. Estamos diciendo en este tipo publicación con P mayúscula en el esquema de GraphQL, vamos a definir un fragmento con algunos campos para los datos que nos importan. Así es de donde viene esto. Nuestro fragmento se llama así, está en el tipo publicación. Luego abre unas llaves o abre las llaves dentro de esto. Necesitamos preguntarnos, como, ¿qué le importa realmente a este componente? ¿Cuáles son sus necesidades de datos, verdad? Puedes ver que necesita el título. Así que escribamos eso. Necesita el extracto, escríbelo. Necesita URI, bien. Y también necesita la imagen destacada. Y ese es el que, recuerda que necesitamos una subselección. Así que haremos llaves. Y luego las llaves del nodo, y en eso, la URL de origen y el texto alternativo. Muy bien, ahora que hemos definido este fragmento, vemos lo bien organizado que está esto. Es como, aquí están las necesidades de datos de este componente. Le importa el título, el extracto, la URI y la imagen destacada. Y luego aquí está el componente, título, extracto, URI, destacado, imagen destacada. Simplemente toma todos los mismos datos que se definen arriba, lo que hace que las cosas estén bien organizadas. Así que estamos exportando esto desde este archivo, pero no lo estamos usando en ningún lugar. Así que debemos ir y hacer eso. Así que campos de tarjeta de publicación, título, extracto, URI. Así que podemos hacer eso aquí. Sí, te lo mostraré primero. Así que aquí están. ¿Verdad, si volvemos aquí a blog? Título, extracto, URI, imagen destacada, este componente en este archivo realmente no le importa ninguno de estos datos. Así que podríamos eliminar todas estas cosas y obtenerlas del fragmento en su lugar. Así que déjame mostrarte cómo se ve eso. Así que sería importar, déjame tomar el nombre de eso, importar campos de tarjeta de publicación. Así que no escribas esto, porque en realidad no dejaremos este fragmento aquí. Solo lo estoy haciendo con fines de demostración. Así que espera un momento antes de escribirlo si estás siguiendo junto conmigo. Así que si importo ese fragmento de campos de tarjeta de publicación, así, espera un momento, solo tomará un minuto. ¿Dónde estaba eso, campos de tarjeta de publicación? De acuerdo, ahora hemos importado nuestro fragmento. Así que necesitamos insertar esto dentro de esta plantilla de etiqueta literal. Y podemos hacer eso simplemente pegándolo al final. Así que si presionas Enter y luego usas esta sintaxis, esto y JavaScript, esto le dice a JavaScript que interpole algunos datos aquí dentro de esta cadena. Así que abriré eso para interpolar algunos datos, y luego pegaremos el nombre de nuestro fragmento aquí. Así que lo importamos y luego lo interpolamos aquí. Ahora seguimos adelante y lo usamos dentro de esta consulta. Así que en lugar de obtener para cada uno de nuestros nodos, en lugar de obtener solo el ID de la base de datos, ahora podemos usar nuestro fragmento que hemos nombrado. Así que la sintaxis para eso es tres puntos y luego el nombre del fragmento. Así que tres puntos, tres puntos, tres puntos. Y luego podemos tomar los nombres que llamamos campos de tarjeta de publicación. Así que copiaré eso. Y aquí, campos de tarjeta de publicación. Esto le dice a GraphQL que, como, expanda o inyecte los campos que hemos definido en ese fragmento en este punto de la consulta, ¿verdad? Así que guardaré eso. Espero haberlo hecho todo bien. Veamos. Blog, creo que sí. Intentemos hacerlo sin. Así que lo eliminaré por completo y luego debería romperse. Sí, ahí lo tienes. El fragmento campos de tarjeta de publicación no se usa nunca. Además, no tiene ningún, los datos que necesita no están ahí. Pero si sigo adelante y uso nuestro fragmento y expando esos campos o los inyecto en este punto de la consulta y guardo eso ahora, funciona, ¿verdad? Así que esto es bueno para la organización. Como dije, las necesidades de datos de tus componentes pueden estar ubicadas en el mismo archivo para que sean fáciles de administrar. Así que si alguna vez en el futuro, si alguna vez haces cambios en esta tarjeta de publicación y te das cuenta, oh, ya sabes qué, necesito otra pieza adicional de datos en la publicación, entonces simplemente puedes ir arriba aquí e insertar cualquier campo adicional o hacer los cambios aquí. Y luego tu componente, sigue adelante y los utiliza de inmediato sin tener que salir nunca de este archivo, lo cual es realmente bueno. De acuerdo. Dije que esperaras para escribir esto. Y la razón de eso es que hemos omitido un nivel. Tenemos listas de publicaciones aquí que creo que vamos a usar. Déjame ver mi producto terminado. Sí. Entonces, si quieres ser técnico, podríamos ir aún más lejos con esto. Porque ahora mismo estamos diciendo que para cada uno de los nodos de publicación, necesitamos el ID de la base de datos, pero luego si miras abajo, este componente tampoco se preocupa por el ID de la base de datos. Solo se preocupa por la colección de publicaciones realmente es todo lo que le importa. Porque simplemente lo va a pasar. ¿Sabes? Así que incluso este ID de la base de datos, a este componente no le importa. Así que si quieres continuar con este patrón de dividir las cosas en fragmentos, podemos hacerlo también para la lista de publicaciones. Así que hagamos esto. Voy a eliminar algunas de estas cosas. Así que ya no uses este fragmento en este campo en absoluto. Solo lo dejaré en este estado por ahora. Así que ahora continúa si estás escribiendo junto conmigo, continúa en este punto.

23. Fragmentos y Comparación de CMS

Short description:

Definimos fragmentos en GraphQL para colocar las necesidades de datos del componente junto con el propio componente. Este patrón permite una fácil gestión y sincronización de los requisitos de datos a medida que crece la base de código. WordPress es un CMS robusto y popular, mientras que otras opciones de CMS sin cabeza como Contentful, Sanity y Prismic ofrecen una moderna modelización de contenido y capacidades desacopladas en el front-end. Sin embargo, estas opciones de CMS son propietarias, lo que puede generar preocupaciones sobre cambios de precio o licencias. Strapi es un CMS de código abierto basado en JavaScript que vale la pena explorar. Next.js se puede utilizar como generador de sitios estáticos para sitios completamente estáticos pre-renderizados si no hay elementos dinámicos como formularios o comentarios. Es posible construir un sitio estático utilizando Next.js y una instalación local de WordPress sin cabeza, pero puede que no sea adecuado para clientes en producción.

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. 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 en la publicación, ¿verdad? Entonces, si defines el tipo como hablamos, abre algunas llaves y realmente todo este componente se preocupa es 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. Así que 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 haremos esta sintaxis de signo 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 que 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, podemos exportarlos a su vez y usarlos finalmente en la página del blog. Así que veamos cómo podemos hacer eso. Así que volvamos a la página del blog, ahora, 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 comenzando en el nivel más alto como el blog, estamos diciendo aquí están los requisitos de datos de este componente. Realmente todo lo 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 se 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 me 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, suena bien, vamos a hacer eso, vamos a ir a la tarjeta de publicación. Componente de tarjeta de publicación, ¿qué necesitas? ¿Cuáles son tus requisitos de datos, verdad? Y dice que necesito estos campos específicos en el objeto de la publicación para satisfacer mis 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 se vuelve bastante fácil mantener estos dos sincronizados en comparación con si tuvieras estas necesidades de datos definidas, ya sabes, en varios componentes en el árbol de componentes que se definen en 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 divide en fragmentos y luego los compone también, tal vez la página de categoría también. 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 otros ejemplos, como puedes ver este compromiso aquí desde nuestro punto de control para verlo, y eso sería como la aplicación final en ese punto. Sí, creo que casi se nos 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 el React Summit. 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 la modelización 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 desacoplado 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 algunas partes de ella ya no sean accesibles, pueden hacerlo en cualquier momento. Así que me gusta que WordPress sea gratuito y de código abierto donde si construyes algo sobre WordPress sin cabeza, siempre es gratuito y de código abierto y no tienes que preocuparte por la empresa 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 a muchos equipos de marketing y personas les gusta realmente les encanta por su interfaz de edición y la experiencia que brinda a los creadores de contenido. Entonces te permite, si haces WordPress sin cabeza, seguir dándoles 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 y otras. Así que sí, no puedo hablar profundamente sobre las comparaciones, pero sí, admiro algunas de las cosas que están haciendo otros CMS, 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 esas cosas. Si no tienes nada de eso y tu sitio es solo contenido estático, como destinado para el consumo, entonces sí, esa podría ser una buena, esa podría ser una opción interesante. Y como decías, incluso te refieres a ejecutar el sitio de WordPress localmente, ya sabes, entonces Next.js, cuando se 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 el propio WordPress 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 en 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.

Watch more workshops on topic

GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Featured WorkshopFree
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
React Advanced Conference 2022React Advanced Conference 2022
95 min
End-To-End Type Safety with React, GraphQL & Prisma
Featured WorkshopFree
In this workshop, you will get a first-hand look at what end-to-end type safety is and why it is important. To accomplish this, you’ll be building a GraphQL API using modern, relevant tools which will be consumed by a React client.
Prerequisites: - Node.js installed on your machine (12.2.X / 14.X)- It is recommended (but not required) to use VS Code for the practical tasks- An IDE installed (VSCode recommended)- (Good to have)*A basic understanding of Node.js, React, and TypeScript
GraphQL Galaxy 2022GraphQL Galaxy 2022
112 min
GraphQL for React Developers
Featured Workshop
There are many advantages to using GraphQL as a datasource for frontend development, compared to REST APIs. We developers in example need to write a lot of imperative code to retrieve data to display in our applications and handle state. With GraphQL you cannot only decrease the amount of code needed around data fetching and state-management you'll also get increased flexibility, better performance and most of all an improved developer experience. In this workshop you'll learn how GraphQL can improve your work as a frontend developer and how to handle GraphQL in your frontend React application.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
WorkshopFree
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
WorkshopFree
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
We all love GraphQL, but it can be daunting to get a server up and running and keep your code organized, maintainable, and testable over the long term. No more! Come watch as I go from an empty directory to a fully fledged GraphQL API in minutes flat. Plus, see how easy it is to use and create directives to clean up your code even more. You're gonna love GraphQL even more once you make things Redwood Easy!
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
How many times did you implement the same flow in your application: check, if data is already fetched from the server, if yes - render the data, if not - fetch this data and then render it? I think I've done it more than ten times myself and I've seen the question about this flow more than fifty times. Unfortunately, our go-to state management library, Vuex, doesn't provide any solution for this.For GraphQL-based application, there was an alternative to use Apollo client that provided tools for working with the cache. But what if you use REST? Luckily, now we have a Vue alternative to a react-query library that provides a nice solution for working with server cache. In this talk, I will explain the distinction between local application state and local server cache and do some live coding to show how to work with the latter.
React Summit 2023React Summit 2023
27 min
The New Next.js App Router
Next.js 13.4 recently released the stable version of the "App Router" – a transformative shift for the core of the framework. In this talk, I'll share why we made this change, the key concepts to know, and why I'm excited about the future of React.
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.