Desarrollo API-first con WordPress sin cabeza

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Cuando se elimina la carga de renderizado de WordPress, se convierte en una plataforma de API de código abierto. Con algunos complementos como WPGraphQL, puedes crear un backend extensible para tus aplicaciones de React para consumir, lo que permite arquitecturas modernas y prácticas de desarrollo en WordPress.

This talk has been presented at React Summit Remote Edition 2021, check out the latest edition of this React Conference.

FAQ

El desarrollo API-first con headless WordPress implica usar WordPress como backend sin utilizar su parte frontal (front-end) predeterminada. Se maneja la gestión de contenido a través de APIs, como GraphQL, permitiendo usar tecnologías de frontend modernas como React para construir interfaces de usuario.

Considerar WordPress para desarrollo API-first es beneficioso porque es una plataforma conocida que maneja cerca del 40% de la web, es gratuita, de código abierto y tiene una gran cantidad de extensiones disponibles que facilitan su integración y uso en proyectos headless.

No es necesario saber PHP para usar headless WordPress, especialmente si se usa en conjunto con tecnologías modernas de frontend como React, donde se puede interactuar con WordPress a través de APIs como GraphQL.

Para trabajar con headless WordPress, es esencial usar plugins como WPGraphQL para manejar consultas GraphQL, así como Custom Post Type UI y Advanced Custom Fields para gestionar tipos de contenidos y campos personalizados.

Puedes obtener recursos y soporte para headless WordPress visitando developers.wp-engine.com, uniéndote al canal de Slack de WP Engine, y siguiendo las sesiones de programación en vivo y podcasts que ofrecen.

El framework headless de WP Engine es un proyecto de código abierto que facilita la integración de WordPress con tecnologías de frontend modernas, permitiendo a los desarrolladores construir aplicaciones más eficientes y rápidas.

Usar WordPress en modo headless permite mayor flexibilidad en el desarrollo frontend, mejora la seguridad al separar la interfaz de usuario del backend, y puede mejorar el rendimiento y la escalabilidad al reducir la carga del servidor y facilitar la implementación global.

Matt Landers
Matt Landers
33 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla discute el desarrollo API-first con WordPress sin cabeza, destacando sus beneficios y la disponibilidad de recursos. Explora el uso de complementos y frameworks como WPGraphQL y el framework sin cabeza de WP Engine para crear tipos de publicaciones personalizadas y realizar llamadas GraphQL. La charla también cubre la construcción de sitios web, la consulta y el almacenamiento en caché de datos, la implementación de aplicaciones con la plataforma Atlas y la mejora de la experiencia del usuario. Se aborda la autenticación, la eficiencia, los recursos del backend y la integración de WooCommerce en WordPress sin cabeza, así como la accesibilidad y la optimización SEO de WordPress.

1. API-first development with headless WordPress

Short description:

Hola, React Summit. En esta sesión, hablaremos sobre el desarrollo API-first con headless WordPress. WordPress es una excelente opción para el desarrollo de API porque es ampliamente utilizado, gratuito y de código abierto. También es ideal para el desarrollo headless y no necesitas conocer PHP. Tenemos recursos disponibles en GitHub y developers.wp-engine.com. Vamos a sumergirnos y construir un sitio que liste desarrolladores en Twitter según su lenguaje.

Hola, React Summit. Soy Matt Landers, jefe de relaciones con desarrolladores en WP Engine. Y en esta sesión, vamos a hablar sobre el desarrollo API-first con headless WordPress. Nuestra agenda es muy sencilla. Voy a hablar un poco sobre lo que vamos a hacer y luego haremos una demostración. Solo tenemos 20 minutos, así que no quiero perder mucho tiempo hablando. Quiero mostrarte cómo hacer realmente el desarrollo API-first con WordPress. Puede que estés pensando, ¿por qué WordPress? Hay muchas opciones diferentes para hacer desarrollo de API. ¿Por qué usaría WordPress? Bueno, una muy buena razón es que el 40% de la web es WordPress y eso está creciendo. Y eso significa que tus usuarios probablemente ya conocen WordPress. Así que se sentirán cómodos en el panel de administración, como tus productores de contenido y especialistas en marketing sabrán cómo moverse en WordPress, lo cual es una ventaja para ti porque ya conocen el software. También es gratuito y de código abierto, así que ¿por qué no aprovechar eso? Y ya hay muchas extensiones integradas en WordPress que lo hacen realmente genial para el desarrollo headless. Y el headless WordPress es increíble, así que no necesitas conocer PHP. Creo que ese es el miedo de algunas personas, como yo no quiero hacer PHP, así que no voy a usar WordPress, especialmente en un evento como este donde todos son desarrolladores de React. Bueno, te alegrará saber que no sé PHP y uso headless WordPress casi todos los días. Soy un desarrollador de TypeScript, JavaScript y paso mi tiempo en Node, TypeScript, Deno, esos tipos de lugares. No hago PHP. Tú tampoco tienes que hacerlo. Para esta sesión, hay algunos recursos disponibles para ti. El código que voy a usar y desplegar en esta sesión se puede encontrar en mi GitHub en matt-lander o slash followa.dev repository. El framework que vamos a usar para el headless WordPress es de WP Engine. Así que si vas al GitHub de WP Engine, verás un proyecto de código abierto llamado headless-framework. Eso es lo que vamos a usar para iniciar nuestros proyectos y comenzar. También puedes ir a developers.wp-engine.com y obtener un montón de recursos de mí y mi equipo sobre headless WordPress y cómo hacer cosas específicas. Vamos a sumergirnos y hacer desarrollo de API con WordPress. Para esta demostración, vamos a construir un sitio que liste diferentes desarrolladores en Twitter a los que podemos seguir. Queremos poder encontrar desarrolladores según el lenguaje que suelen utilizar porque si soy un desarrollador y quiero seguir a otro desarrollador, probablemente estoy buscando a alguien que trabaje en el mismo lenguaje y frameworks o tecnologías que yo conozco para poder obtener más información y aprender más al respecto. Eso es lo que vamos a construir en el sitio. Vamos a utilizar headless WordPress como la plataforma que utilizaremos para nuestra API y también donde nuestros usuarios podrán ingresar los datos para el sitio web. Lo que he hecho es utilizar Local para crear un sitio WordPress en mi máquina local.

2. Developers and GraphQL

Short description:

Puedes usar LocalWP.com para crear rápidamente sitios de WordPress y trabajar en ellos localmente. Instala el plugin WPGraphQL para tener una mejor experiencia de API con WordPress. Los plugins Custom Post Type UI y Advanced Custom Fields convierten a WordPress en una plataforma de creación de API. Con el framework headless de WP Engine, podemos hacer llamadas a GraphQL y obtener datos estructurados sobre desarrolladores. Creemos un tipo de contenido personalizado para desarrolladores y configuremos para que aparezca en GraphQL.

Puedes obtener esto en LocalWP.com. Es realmente genial para crear rápidamente sitios en WordPress y trabajar en ellos localmente. Luego puedes subirlos a algún lugar en vivo.

De acuerdo. Ya tengo esto en funcionamiento y también tengo algunos plugins que siempre uso ya instalados. El plugin número uno que siempre uso es WPGraphQL. Debes tenerlo porque necesitas una API sólida cuando vayas a trabajar con WordPress. Ya hay una API REST, pero encuentro que es mucho más fácil usar una API GraphQL, especialmente porque hay tantas relaciones en nuestros datos.

También hay otros dos plugins que realmente convierten a WordPress en una plataforma de creación de API. Eso sería Custom Post Type UI y Advanced Custom Fields. También hay extensiones para esos dos para WPGraphQL que también tengo instaladas, y también tengo instalado el framework headless de WP Engine, que es un plugin.

Veamos qué nos ofrece primero. Si vamos al playground de GraphQL aquí, veremos que podemos hacer llamadas a GraphQL directamente a nuestros datos y obtener contenido. Por defecto, WordPress tiene publicaciones y páginas. Este contenido se muestra como HTML sin formato, como podemos ver aquí. En el frontend y desde una API, eso no es realmente lo que quiero obtener todo el tiempo. Por ejemplo, en este caso, quiero obtener una lista de desarrolladores y algunos datos estructurados sobre ellos. Quiero construir una API que me devuelva los datos en el frontend de la forma en que quiero que se vean.

Entonces, hagamos eso. Lo primero que vamos a hacer es crear ese tipo de contenido personalizado, que en WordPress se llama tipo de publicación personalizada. Lo llamaremos desarrolladores, y nuestra etiqueta en plural será desarrolladores y desarrollador. Veremos por qué necesitamos eso en un segundo. Desplazaremos hacia abajo y nos desharemos de algunas de las cosas predeterminadas que aparecen en esta publicación. Solo queremos el título, y queremos que aparezca en GraphQL. Así que tengo que decirle cómo quiero que aparezca en GraphQL. Voy a agregar ese tipo de publicación. Tan pronto como lo agregue, notarás que ahora hay una sección de desarrolladores en nuestro menú, lo cual es genial. Ahora tengo una forma de ver los desarrolladores que he ingresado. Ahora tengo algunos que ingresé anteriormente, y vuelven a aparecer. Así que no quiero tener que ingresarlos de nuevo.

3. Adding developer fields and custom post types

Short description:

Pero si hago clic en uno, solo puedo ver el nombre. Esto no es muy útil, ¿verdad? Ahora podemos ir a nuestro editor gráfico y extraer estos datos. Podemos decir 'desarrolladores' y solo obtener el título. Y ahora podemos obtener esos datos. Tenemos el título, pero necesitamos más datos que esto. Necesitamos extraer su GitHub, su nombre de Twitter, todas esas cosas. Así que vamos a agregar eso. Vamos a los campos personalizados.

Pero si hago clic en uno, solo puedo ver el nombre. Esto no es muy útil, ¿verdad? Ahora podemos ir a nuestro editor gráfico y extraer estos datos. Podemos decir 'desarrolladores' y solo obtener el título. Y ahora podemos obtener esos data.

Tenemos el título, pero necesitamos más data que esto. Necesitamos extraer su GitHub, su nombre de Twitter, todas esas cosas. Así que vamos a agregar eso. Vamos a los campos personalizados. Y decimos campos de desarrollador. Puedes ponerle el nombre que quieras. Y luego solo quiero que aparezcan en ese tipo de publicación personalizada de desarrollador, no quiero que aparezcan en mis publicaciones de blog o mis páginas, solo quiero que aparezcan en mi tipo de publicación personalizada de desarrollador. Y luego podemos agregar campos de manera muy sencilla. Voy a agregar un nombre y quiero que aparezca en GraphQL, así que me aseguro de que esté marcado aquí. También quiero agregar Twitter. Así que quiero su nombre de usuario de Twitter, que también será texto. Ahora también quiero saber en qué lenguajes trabajan. Lenguajes. Y haremos una taxonomía. En WordPress, las taxonomías son cosas como etiquetas o categorías. Y para esto, vamos a usar etiquetas. También queremos obtener su blog personal. Esto será una URL. Y veremos cómo se utiliza en un momento. Y queremos obtener su GitHub. Otra vez, otra URL. Y eso debería ser suficiente. Muy bien. Así que vamos a ir al final aquí, y queremos asegurarnos de que esto aparezca en GraphQL de nuevo. Y generalmente prefijo el nombre del grupo de campos con ACF y mi desarrollador, lo que quiera llamarlo. Muy bien.

4. Building the website and pulling data from the API

Short description:

Vamos a volver al principio y vamos a publicar esto. Ahora mira, tenemos todos estos campos y un buen editor para que alguien pueda editar. Estamos extrayendo todos esos datos de una manera estructurada. No estamos obteniendo contenido sin procesar como lo hicimos con una publicación, estamos obteniendo contenido real como esperaríamos de una API. El siguiente paso es construir el sitio web. Así que vamos a hacer eso.

Vamos a volver al principio y vamos a publicar esto. Ahora volvamos a nuestro editor. Y ahora mira, tenemos todos estos campos y un buen editor para que alguien pueda editar. Así que puedo entrar aquí y decir, bueno, sé que Will también sabe C-sharp. Así que agregaré una nueva etiqueta aquí. Y llamaré a eso. Él no tiene un blog. Y luego estamos bien, podemos actualizar eso. Así que ahora tengo un buen editor. Puedo agregar un nuevo desarrollador y agregar todo eso. Y luego queremos, ahora lo que voy a obtener es una buena API, ¿verdad? Así que si voy a mi IDE gráfico, ahora puedo extraer todo esto. Nombre, y también podemos desplazarnos hacia abajo aquí. Y veremos que van a aparecer en ese grupo de desarrolladores de ACF. Sabes, hay GitHub, nombre, blog personal, Twitter, qué lenguajes tienen, así que vamos a ejecutar esto. Muy bien, bastante genial. Así que ahora estamos extrayendo todos esos data de una manera estructurada. No estamos obteniendo contenido sin procesar como lo hicimos con una publicación, estamos obteniendo contenido real como esperaríamos de una API, ¿verdad? Incluso podemos cambiarle el nombre, así que le daremos un alias, lo llamaremos data en lugar de ACF. Ahora tenemos algo bueno que podemos usar en nuestro sitio web. Así que el siguiente paso es construir el sitio web. Así que vamos a hacer eso.

5. Using the Headless Framework and Making Queries

Short description:

Para el sitio, estamos utilizando el framework headless de WP Engine, que facilita la conexión a WordPress y la obtención de contenido. El proyecto está configurado y el sitio ha sido personalizado. Tenemos variables de entorno para configurar la instancia de WordPress y un secreto de WordPress headless. Ahora podemos utilizar la funcionalidad del framework para realizar llamadas a WordPress. Comenzamos obteniendo GQL de Apollo y guardando nuestra consulta. Luego proporcionamos la consulta a la página de inicio, que requiere el tipo de desarrolladores.

Para el sitio, vamos a utilizar el framework headless de WP Engine, es un proyecto de código abierto que facilita la conexión a WordPress y la obtención de contenido. Así que vamos a utilizar eso. Si vamos a ese proyecto en GitHub y nos desplazamos hacia abajo, hay un comando npx que puedes ejecutar que configurará ese proyecto para ti. Ya lo he ejecutado en aras del tiempo y lo tengo configurado. Veamos cómo está en este momento.

He eliminado mucho del código base que está ahí, así que hay todo un sitio que muestra publicaciones y tiene un blog. Lo he eliminado y he añadido mi propio CSS y algunos componentes. Así es como se ve el sitio en este momento. Tenemos este modo oscuro genial, que hemos hecho puramente con variables CSS, definitivamente revisa el código si te parece interesante. Y luego, vamos a ver el código y lo que vamos a hacer aquí.

De acuerdo, tenemos este archivo de variables de entorno, donde le decimos al framework dónde está nuestra instancia de WordPress. Por ahora, solo estamos mirando nuestra instancia local, lo cambiaremos cuando lo implementemos en una instancia en vivo. Y luego tenemos nuestro secreto de WordPress headless, que proviene de WordPress en sí. Así que si vuelvo aquí, voy a configuración, puedes ver que el secreto está aquí, no puedes hackearme, esto es local, no podrás ver el real. Puedes intentarlo. De acuerdo, tenemos eso configurado. Y eso significa que el framework está listo, sabe cómo comunicarse con WordPress, solo tenemos que utilizar la funcionalidad del framework para realizar esas llamadas. Así que hagámoslo. Y lo primero que queremos hacer es obtener GQL de Apollo. Y vamos a usar esto para guardar nuestra consulta. Así que diremos obtener todo esto, vamos a tomar eso de aquí que hicimos antes. Y simplemente lo pegamos. De acuerdo, ahora tenemos nuestra consulta, lo cual es genial. Ahora necesitamos hacer la consulta y proporcionarla a la página de inicio. Así que determinemos qué va a necesitar la página de inicio desde el punto de vista del tipo. Vamos a crear una interfaz, home props. Y va a tener un developers, necesitamos pasar desarrolladores. Y será del tipo developers, que ya he definido. Y puedo mostrarte eso.

6. Mapping out and displaying developer data

Short description:

Tenemos el tipo y el array listos para los desarrolladores. Vamos a mapearlos y ponerlos en un componente de tarjeta. El componente de tarjeta espera las props de desarrollador, que podemos pasar usando developer.data. También tenemos un componente puro para mostrar la tarjeta. Ahora, proporcionemos datos a la página de inicio exportando getStaticProps y obteniendo el cliente Apollo usando GetApolloClient.

Aquí mismo, tengo este tipo. Esto se parece exactamente a lo que obtendremos de la consulta. Así que si vas aquí, son los mismos campos, solo escritos en TypeScript. Y luego tengo el array. Y como está bajo esa propiedad data, como tenemos aquí, lo hemos extendido así para los desarrolladores. Muy bien, genial. Entonces eso es lo que vamos a pasar aquí. Así que vamos a darle un tipo, React.fc y pasaremos home props. Y ahora tendremos esos desarrolladores listos para nosotros. Genial.

Adelante y mapeemos esto. Entonces developers.map. Y los pondremos en un componente de tarjeta. Tenemos este componente creado. Lo mostraré en un segundo. Necesitamos una clave, que será developer.data.twitter porque eso debería ser único. Y luego la tarjeta solo espera esas props de desarrollador. Así que vamos a hacer developer.data. Y echemos un vistazo a ese componente rápidamente. Lo importaremos. Y es solo un componente puro que tiene algunos estilos y cosas así para nosotros. No tenemos que escribir todo esto para la demostración. Pero es solo un componente puro que mostrará una tarjeta de cada uno de los desarrolladores.

Entonces estamos recorriendo eso, pero aún no hemos proporcionado datos a esta página de inicio. Estamos usando Next, y podemos hacer que esta sea una página estática si simplemente exportamos getStaticProps. Así que hagámoslo. GetStaticProps, y tiene un contexto. Y vamos a escribir eso, getStaticProps.context. Y luego queremos obtener el cliente Apollo. Así que podemos hacer eso con un método del framework llamado GetApolloClient.

7. Querying and Caching Data

Short description:

Obtenemos los datos de Client.Query usando GetAllDevs. Devolvemos las props con Developers como Data.Developers.Nodes. Pasamos Revalidate1 para actualizaciones constantes de datos. Hacemos una llamada de framework a GetNextStaticProps para almacenar en caché la consulta. Obtenemos el cliente del proveedor headless del framework. Consultamos para obtener todos los desarrolladores y guardamos la caché. Devolvemos las props y mostramos los desarrolladores. Agregamos un nuevo desarrollador, Dan Abramov.

Y simplemente pasamos el contexto. Eso, cuando pasamos el contexto, almacenará la caché de esa consulta en el contexto Así que no terminamos haciendo la llamada varias veces. El framework se encarga de todo eso por nosotros. Y queremos hacer la consulta. Así que vamos a obtener los data de Client.Query. Necesitamos esperar esto, porque devuelve una promesa. Y pasaremos GetAllDevs.

Muy bien, genial. Ahora tenemos nuestros data. Necesitamos devolver eso. Así que vamos a devolver props, que tendrá Developers, y será Data.Developers.Nodes. Y la razón de eso está aquí. Así que volverá como Developers.Nodes. Por eso lo estamos pasando de la manera en que lo estamos haciendo. También queremos pasar Revalidate1 aquí, para que obtengamos constantemente nuevos data a medida que agregamos esos desarrolladores a nuestro sitio headless de WordPress. Y hay otra cosa que quiero hacer aquí, que es hacer una llamada de framework a GetNextStaticProps, y simplemente paso el contexto. Esta es la última cosa que necesito hacer para asegurarme de que se almacene en caché esa consulta. Y voy a importarlo del framework. De nuestra siguiente sección del framework.

Muy bien. Entonces ahora lo que estamos haciendo es obtener el cliente, que ha sido agregado a nuestra aplicación por el framework. Si miramos en esta aplicación aquí, tenemos un proveedor headless, y esto hace toda la magia de asegurarse de que Apollo esté configurado y listo para funcionar. Hacemos la consulta para obtener todos los desarrolladores. Llamamos a este método del framework solo para guardar la caché de Apollo en el contexto. Y luego devolvemos nuestras props, las pasamos a nuestra página de inicio y simplemente mostramos estas tarjetas. Así que veamos si funciona. Actualizamos esto, y ahí están. Tenemos nuestros desarrolladores saliendo de WordPress headless, así que vamos a crear otro solo para mostrar cómo funciona esto. Luego entramos aquí, agregamos uno nuevo, digamos Dan Abramov. Bastante seguro de que esto es solo Dan Abramov...

8. Deploying the App with Atlas Platform

Short description:

Podría no serlo. Trabaja en Facebook y conoce React. Ahora que tenemos nuestro sitio en funcionamiento, el siguiente paso es implementarlo utilizando la plataforma Atlas de WP Engine. Podemos implementar sitios de WordPress y front-ends de Node escritos en varios frameworks como NextJS, Gatsby, Vue o Angular. Creemos una nueva aplicación en Atlas, nombremosla 'Follow a dev' y configuremos los ajustes del entorno. Proporcionemos el repositorio de GitHub, la variable de entorno y la URL del sitio. Guardemos los ajustes y hagamos clic en 'Crear aplicación'.

Podría no serlo. Trabaja en Facebook y conoce React, diría yo. Y esas cosas. Lo publicaremos, volvemos aquí, actualizamos. Tengo que actualizar dos veces. No esta vez. Y ahí está Dan. Muy bien, genial. No era el identificador correcto.

Ahora que tenemos nuestro sitio en funcionamiento, el siguiente paso que queremos hacer es implementarlo y ponerlo en vivo. Estoy emocionado de mostrar un poco de lo que he estado trabajando en WP Engine, que es la plataforma Atlas, donde puedes implementar tu sitio de WordPress y tu front-end de Node, sin importar en qué lo hayas escrito. En este caso, estamos usando NextJS, pero podríamos usar Gatsby o Vue o Angular o lo que sea. Y podemos implementarlo en Atlas. Así que vamos a hacer eso.

Si voy a mi portal de WP Engine, ya tengo este sitio en funcionamiento. Tengo un sitio de WordPress, y ahora solo quiero implementar mi aplicación. Así que voy a Atlas y voy a crear una nueva aplicación. Y simplemente le daré un nombre a la aplicación. Follow a dev. Y vamos a usar nuestro entorno headless que se llamará producción. No necesitamos nada más, ¿verdad? Y luego queremos que follow a dev sea nuestro entorno de WordPress. Lo ejecutaremos en el centro de EE. UU. En nuestra configuración de GitHub, esto se ejecuta en Matt-lander/follow a dev, y está en la rama principal. Y necesitamos darle esa variable de entorno que creamos anteriormente. Justo aquí. Y necesitamos darle la URL de nuestro sitio, que ya lo tengo funcionando aquí. Así que solo necesito copiar esta URL. Ya tengo más desarrolladores configurados. Guardaremos eso. Haremos clic en crear aplicación.

9. Deploying the App and Improving User Experience

Short description:

Se implementará, obtendrá nuestro código de GitHub, lo descargará. NPM install, ejecutará un script de compilación, npm run wpe-build es el script que se ejecuta. Nuestro sitio está en funcionamiento, está bien. Le hemos dado una URL. También le he asignado un dominio personalizado. En WPENGINE, hemos estado trabajando para hacer de WordPress sin cabeza un CMS sin cabeza realmente excelente, y parte de eso es mejorar la experiencia del usuario. Así que hemos estado trabajando en nuestro marco de código abierto para crear un modelador de contenido, que le permite crear modelos de contenido de una manera mucho más fácil de usar.

Se implementará, obtendrá nuestro código de GitHub, lo descargará. NPM install, ejecutará un script de compilación, npm run wpe-build es el script que se ejecuta. Y una vez que haga eso, ejecutará next build, que creará todas nuestras páginas estáticas y luego lo implementará donde se ejecutará npm start. Donde lo iniciamos en el puerto 8080. Y luego la plataforma sabe cómo ejecutarlo. Pero una vez que esté en funcionamiento, estará listo para funcionar. Y veremos que eso está construyendo aquí. Y cuando termine, volveremos y estaremos en funcionamiento.

De acuerdo, nuestro sitio está en funcionamiento, está bien. Le hemos dado una URL. También le he asignado un dominio personalizado. Y ahora podemos salir y echar un vistazo. Así que en realidad está en follow-up dev, y viste lo rápido que es. Simplemente se está ejecutando. Es instantáneo. Se está ejecutando de forma estática. Y también hemos agregado más funcionalidad aquí, puedes verlo en el código, pero podemos filtrar por diferentes palabras clave aquí, o diferentes idiomas. Y es súper rápido y rápido. Así que échale un vistazo, revisa el código, revisa Atlas y déjame saber qué piensas.

De acuerdo, antes de terminar, tengo una cosa más que mostrarte. En WPENGINE, hemos estado trabajando para hacer de WordPress sin cabeza un CMS sin cabeza realmente excelente, y parte de eso es mejorar la experiencia del usuario. Probablemente hayas notado que mientras creábamos esos tipos de contenido personalizados, no se sentía muy orientado a sin cabeza. Porque hay muchos campos que simplemente no tenían sentido. Así que hemos estado trabajando en nuestro marco de código abierto, que está aquí. Asegúrate de marcarlo para que puedas seguirlo en algún código para crear un modelador de contenido, que estoy demostrando ahora mismo. Esta es la primera vez que alguien ve esto, pero te permite crear modelos de contenido de una manera mucho más fácil de usar. Podríamos crear ese mismo modelo de contenido, desarrollador, desarrolladores, que creamos anteriormente de una manera mucho mejor. Tenemos diferentes campos que podemos crear, así que podemos poner nuestro nombre como un campo de texto, podemos agregar otro campo para los idiomas, que es un repetidor, por lo que es como una matriz. Podemos crear estos campos y podemos crear este tipo de contenido de una manera muy sencilla y luego también podemos tener una experiencia diferente para nuestros editores, que saldrá pronto. Aún no puedes obtener esto, pero asegúrate de seguir nuestro proyecto para que sepas cuándo estará disponible.

10. Keeping track and building with Headless WordPress

Short description:

Si quieres estar al tanto de lo que estoy haciendo con Headless WordPress, visita developers.wpengine.com. Únete a nuestro canal de Slack y echa un vistazo a nuestro contenido semanal, que incluye Headless WordPress Live en YouTube y el podcast Decode en iTunes y Spotify. Construye cosas geniales con Headless WordPress y ¡feliz codificación!

Y finalmente, si quieres estar al tanto de las cosas que estoy haciendo, que mi equipo está haciendo con Headless WordPress, ve a developers.wpengine.com. Puedes unirte a nuestro canal de Slack, donde tenemos mucha gente que está hablando de Headless WordPress y haciendo diferentes proyectos relacionados con ello. También creamos mucho contenido semanalmente. Así que tenemos Headless WordPress Live, donde hacemos programación en vivo en YouTube todos los viernes a la 1PM Central, échale un vistazo. De hecho, construimos este sitio followdev durante una de nuestras sesiones de programación en vivo. Y también tenemos el podcast Decode, así que ven y échale un vistazo. Está disponible en iTunes, Spotify, en todas partes. Pero hablamos de todo, desarrollo de front-end y algunas cosas sobre Headless WordPress también. Así que échale un vistazo. Déjame saber qué piensas y construye cosas geniales con Headless WordPress. ¡Feliz codificación!

11. Resultados sorprendentes de la encuesta

Short description:

Me sorprende que todavía haya personas que utilizan REST en lugar de GraphQL. Algunos están atrapados en el pasado y la infraestructura está ligada a REST. Migrar a GraphQL puede ser difícil.

De hecho, estoy muy sorprendido por esta encuesta. Esperaba que todos quisieran utilizar GraphQL, pero parece que todavía hay personas que utilizan REST. Me alegra haber hecho esta pregunta, porque es un resultado sorprendente.

Sí, pero piensa que tal vez algunos están simplemente atrapados en el pasado, más o menos. Y no porque no quieran utilizar GraphQL, sino porque toda la infraestructura está realmente ligada a REST en general. Tal vez eso sea una razón. Y también los componentes dependen de REST. Es bastante difícil pasar a GraphQL. Puede serlo. Sí, eso es cierto. Sin duda.

12. Authentication in Headless WordPress

Short description:

WordPress tiene su propio mecanismo de autorización, lo que te permite hacer solicitudes autenticadas agregando un token de autorización. El marco de código abierto proporciona un flujo de autenticación similar a OAuth. Permite a los usuarios iniciar sesión en el front-end, intercambiar un código de acceso por un token y usar ese token para acceder a datos autorizados. También es posible iniciar sesión con terceros, como GitHub o Auth0. La validación de los tokens de acceso y la decodificación de la información del usuario generalmente ocurre en el backend.

De acuerdo, recibimos un par de preguntas. Y comenzaré con la pregunta de Yuri. Se pregunta acerca de la autenticación en Headless WordPress. ¿Viene incluida de serie o aún debemos integrarnos con servicios de terceros como Auth0 a través de complementos, como se implementó anteriormente en la API REST de WordPress? Bien, WordPress tiene su propio mecanismo de autorización. Si te sientes cómodo con eso, definitivamente puedes usarlo. Lo único que tienes que hacer para hacer solicitudes autenticadas es agregar el token de autorización a la solicitud a WP-GraphQL o a la API REST también.

Entonces, en nuestro complemento que hemos creado, el marco de código abierto, hemos implementado un flujo de autenticación. Es similar a OAuth. Entonces, si accedes a una página en tu sitio de front-end donde necesitas autorización, como un enlace de vista previa, por ejemplo, de alguien que está escribiendo un blog y quiere previsualizarlo antes de publicarlo. Cuando acceden al enlace en el front-end, los redirigirá a WordPress para iniciar sesión, lo cual los redirigirá de vuelta al front-end con un código de acceso. Ese código se intercambiará por un token, y luego puedes usar ese token en tu solicitud para obtener cualquier data que necesites para la autorización. Pero si deseas iniciar sesión con terceros, como iniciar sesión con GitHub o algo así, o Auth0, también puedes hacerlo. No lo he probado, pero es un escenario interesante que debería revisar. Sí. Pero como discutimos anteriormente, también estoy luchando con este token de acceso para asegurarme de que no provenga de un hacker, por ejemplo. Me gustaría codificar o decodificar y ver al usuario real. Esto es algo que ocurre en el backend. Entonces, realmente es algo en lo que tal vez un tercero o WordPress, si lo está haciendo, es algo en lo que realmente vale la pena confiar. Correcto. En ese caso, también podrías usar tu backend para tu frontend. Entonces, si estás utilizando un tercero e integrándolo en WordPress, si necesitabas usar ese token para acceder a data, definitivamente podrías hacerlo. Sí, exactamente. O tal vez una personalización, ¿verdad? Correcto.

13. Efficiency of WP GraphQL

Short description:

WP GraphQL es muy eficiente con sus consultas, mucho más eficiente que la API REST. Las demostraciones han demostrado que la API GraphQL tarda solo 20 milisegundos en recuperar datos, en comparación con los 8 segundos de la API REST.

Otra pregunta viene de Renee Goretzka. Si tienes consultas anidadas de GraphQL, ¿el complemento recupera los datos en una sola solicitud SQL Genie o realiza varias solicitudes a la base de datos SQL? No estoy cien por ciento familiarizado con el funcionamiento interno de WP GraphQL, pero puedo hacer esa pregunta a Jason Ball, quien está en nuestro equipo y lo mantiene. Diré que es muy eficiente con sus consultas, mucho más eficiente que la API REST. Hay algunas demostraciones que hemos hecho donde golpeamos un servidor con muchas publicaciones y taxonomías como etiquetas y categorías, y tarda, ya sabes, ocho segundos en responder con la API REST. Y luego, cuando usamos la API GraphQL, tarda, ya sabes, 20 milisegundos. Así que es mucho más eficiente que usar la API REST, sin duda alguna.

QnA

Data Loader, Types, Performance, and Dashboards

Short description:

Sí. Hay un cargador de datos involucrado. Optimizaciones. Carlos Barraza pregunta sobre la generación de tipos para operaciones. Navis pregunta sobre complementos para mejorar el rendimiento. WordPress sin cabeza ofrece opciones de escalabilidad y rendimiento. Marcus Young pregunta sobre paneles personalizados y el uso del panel de WordPress. Los complementos existentes en el lado del administrador seguirán funcionando.

Sí. Creo que también hay un cargador de datos involucrado, ¿verdad? Y habrá, básicamente, para, aunque estés usando WordPress o no, va a tomar algo o va a unir las solicitudes tal vez. Y sí, otra pregunta. Exactamente. Sí. Sí. Así que optimizaciones.

Otra pregunta viene de Carlos Barraza. ¿Cómo generaste los tipos para las operaciones? Creamos los tipos. Bueno, el complemento viene con tipos estándar. Entonces, si tienes una publicación regular o algo así, esos tipos estarán, el complemento los tiene disponibles para ti. Pero si tienes un tipo de publicación personalizado, deberás proporcionar esos tipos. Probablemente no los viste en la presentación, pero esos tipos estaban allí. O los proporcionas tú.

Otra pregunta viene de Navis. ¿Hay complementos para mejorar el rendimiento? ¿Hablamos anteriormente sobre el rendimiento? Tal vez haya complementos para mejorarlo. Una de las razones por las que optarías por WordPress sin cabeza en primer lugar es por la escalabilidad y el rendimiento. Ya sabes, WordPress tradicionalmente, cuando tienes la representación mezclada con la API y los datos, diferentes complementos hacen cosas diferentes y no tienes mucho control sobre eso. Es un poco difícil escalar WordPress, pero cuando divides la arquitectura en donde tienes la API y el front-end, te brinda muchas más opciones sobre cómo escalar esa plataforma. Entonces puedes hacer caché en la capa de nodo. Entonces, si tienes una publicación que se accede mucho y estás haciendo representación en el servidor o algo así, puedes hacer caché en la capa de nodo y solo comunicarte con WordPress cuando realmente lo necesites. Y también puedes distribuir ese front-end globalmente, lo cual no podrías hacer con WordPress, ya que está tan ligado a la base de datos. Así que hay muchas opciones cuando vas sin cabeza para la escalabilidad, simplemente abriendo esa arquitectura.

Genial. Otra pregunta viene de Marcus Young. En primer lugar, a él o ella le encanta tu presentación. Así que felicidades por eso. Y la pregunta es, ¿también creas paneles personalizados para clientes con este enfoque sin cabeza, o solo usas el panel de WordPress? ¿Paneles personalizados en el lado del administrador, supongo? Creo que sí, ¿verdad? Si ya tienes complementos que estás usando, sí, si ya tienes complementos que funcionan en el lado del administrador, esos seguirán funcionando. Entonces, si tienes algo que funciona desde una perspectiva de panel, diría que te quedes con eso. ¿Por qué reinventarlo? Cuando vas sin cabeza, pierdes todos los complementos que modifican el front-end.

Backend Resources and WooCommerce Integration

Short description:

Aprovecha los recursos del backend para reducir la carga de desarrollo. WooCommerce tiene APIs que se pueden utilizar para la integración de comercio electrónico. Aunque aún no se han creado integraciones específicas sobre WooCommerce, es posible utilizarlo en lugar de Shopify. Recientemente se llevó a cabo una masterclass que muestra la integración de Shopify con WordPress. La creación de soluciones listas para usar para WooCommerce es una oportunidad potencial.

Definitivamente deberías aprovechar todo lo que puedas en el backend para reducir la carga de desarrollo, sin duda. Sí, tiene sentido.

Bueno, llegó una gran pregunta. Es de Giannakis87. ¿Qué hay del complemento de WooCommerce o ya tienes alguna integración más específica para el e-commerce? Sí, WooCommerce tiene APIs que puedes aprovechar. Aún no hemos construido nada específicamente sobre WooCommerce. De hecho, he realizado algunas sesiones de codificación en vivo donde uso Shopify mezclado con WordPress. Así que mezclo contenido y comercio, y en realidad hay una masterclass que es parte de esta conferencia que hicimos la semana pasada. Creo que se volverá a transmitir la próxima semana donde construimos una tienda de e-commerce de Shopify. Pero no sería diferente usar WooCommerce en lugar de eso. Solo queríamos mostrar el uso de diferentes fuentes de datos en eso. Pero definitivamente hay una oportunidad ahí para construir algunas cosas listas para usar para WooCommerce, sin duda.

WordPress Accessibility and SEO

Short description:

Por defecto, la instancia de WordPress es accesible públicamente, pero el frontend se puede poner fuera de línea por motivos de seguridad y SEO. Yoast tiene un complemento para WP GraphQL para consultar las etiquetas de encabezado. No es posible crear campos a través de la API de forma predeterminada, pero se puede habilitar con la extensibilidad de WP GraphQL.

Otra pregunta, una larga, pero muy buena. La hace CW. Dado que tanto el Frontend estático como WordPress están alojados en WEngine, ¿la instancia de WordPress es accesible públicamente o es una VPC de algún tipo para que puedas acceder al Frontend estático e interactuar con él a través de Apollo? ¿O alguien aún puede llegar accidentalmente al sitio de WordPress? Correcto, por defecto, la instancia de WordPress está disponible en Internet porque muchas personas quieren acceder a ella desde el navegador. Entonces, si vas a hacer cosas del lado del cliente es posible que desees acceder a tu instancia de WordPress desde el navegador. Pero es posible poner tu backend completamente fuera de línea y solo hacerlo accesible desde el lado del nodo si así lo deseas. Una cosa que hacemos en el complemento es quitar el frontend de Internet. Por lo tanto, no está indexado por un motor de búsqueda o algo así. Entonces, si accedieras al frontend de WordPress esa persona sería redirigida al frontend que está en nodo para evitar, ya sabes, múltiples SEO potenciales como ser indexado y también para reducir la superficie de ataque desde un punto de vista de seguridad. Por lo tanto, solo podrían acceder a wp-admin lo cual sería mucho más difícil de vulnerar que algún complemento que esté afectando tu frontend.

Muy bien. Hablando de SEO, Zach Winnie preguntó, ¿hay alguna forma de consultar cosas como etiquetas de encabezado para SEO con WordPress Engine Headless? Sí. Y lo hicimos en nuestro taller de React para esta conferencia. Así que Yoast tiene un complemento para WP GraphQL para que puedas extraer todos los datos de Yoast de WordPress. Y luego Will Johnston, que está en mi equipo en WP Engine, creó un componente de React al que puedes pasar esos datos y simplemente enchufarlo en el componente de React y lo colocará en el encabezado por ti. Lo hará tanto en el renderizado estático como en el del lado del servidor, como prefieras hacerlo también.

Y creo que tenemos tiempo para una pregunta más. Luis Zardon está preguntando, ¿hay alguna forma de crear campos a través de la API en WordPress? ¿Hay alguna forma de crear nuevos campos a través de la API? Esa es una buena pregunta. No creo que de forma predeterminada puedas hacer eso, pero es algo que podrías habilitar fácilmente con WP GraphQL. WP GraphQL es muy extensible y lo he utilizado para crear campos sin duda. Y también, he utilizado la extensibilidad de WP GraphQL para crear un formulario en el que solo puedes enviar datos al formulario, pero no leer los datos del formulario, lo cual es una buena manera de crear, como un formulario de contacto. Es bastante genial.

Y muchas gracias, Matt. Tuvimos muchas preguntas, pero se acabó el tiempo. Y, quiero, pero tal vez la gente aún pueda contactarte. ¿Vas a estar disponible en la llamada? Sí, voy a unirme al chat espacial en un minuto. Así que si quieres unirte allí, estaré allí. Pero también puedes contactarme a través de mi GitHub o Twitter o donde quieras encontrarme. Matt Undershorelander está en Twitter. Increíble. Muchas gracias una vez más, y disfruta el resto del día, Matt. De acuerdo, gracias por tenerme.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Construyendo Mejores Sitios Web con Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Construyendo Mejores Sitios Web con Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Compilador React Forget - Entendiendo React Idiomático
React Advanced 2023React Advanced 2023
33 min
Compilador React Forget - Entendiendo React Idiomático
Top Content
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Uso efectivo de useEffect
React Advanced 2022React Advanced 2022
30 min
Uso efectivo de useEffect
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Enrutamiento en React 18 y más allá
React Summit 2022React Summit 2022
20 min
Enrutamiento en React 18 y más allá
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js para Desarrolladores de React.js
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js para Desarrolladores de React.js
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
En esta avanzada masterclass de Next.js, profundizaremos en conceptos clave y técnicas que permiten a los desarrolladores de React.js aprovechar al máximo Next.js. Exploraremos temas avanzados y prácticas prácticas, equipándote con las habilidades necesarias para construir aplicaciones web de alto rendimiento y tomar decisiones arquitectónicas informadas.
Al final de esta masterclass, serás capaz de:1. Comprender los beneficios de los Componentes del Servidor React y su papel en la construcción de aplicaciones React interactivas, renderizadas por el servidor.2. Diferenciar entre el tiempo de ejecución de Edge y Node.js en Next.js y saber cuándo usar cada uno en función de los requisitos de tu proyecto.3. Explorar técnicas avanzadas de Renderizado del Lado del Servidor (SSR), incluyendo streaming, fetching paralelo vs. secuencial, y sincronización de datos.4. Implementar estrategias de caché para mejorar el rendimiento y reducir la carga del servidor en las aplicaciones Next.js.5. Utilizar Acciones React para manejar la mutación compleja del servidor.6. Optimizar tus aplicaciones Next.js para SEO, compartir en redes sociales, y rendimiento general para mejorar la descubrabilidad y la participación del usuario.
Aventuras de Renderizado Concurrente en React 18
React Advanced 2021React Advanced 2021
132 min
Aventuras de Renderizado Concurrente en React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Con el lanzamiento de React 18 finalmente obtenemos el tan esperado renderizado concurrente. Pero, ¿cómo va a afectar eso a tu aplicación? ¿Cuáles son los beneficios del renderizado concurrente en React? ¿Qué necesitas hacer para cambiar al renderizado concurrente cuando actualices a React 18? ¿Y qué pasa si no quieres o no puedes usar el renderizado concurrente todavía?

¡Hay algunos cambios de comportamiento de los que debes estar al tanto! En esta masterclass cubriremos todos esos temas y más.

Acompáñame con tu portátil en esta masterclass interactiva. Verás lo fácil que es cambiar al renderizado concurrente en tu aplicación React. Aprenderás todo sobre el renderizado concurrente, SuspenseList, la API startTransition y más.
Consejos sobre React Hooks que solo los profesionales conocen
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
Consejos sobre React Hooks que solo los profesionales conocen
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
La adición de la API de hooks a React fue un cambio bastante importante. Antes de los hooks, la mayoría de los componentos tenían que ser basados en clases. Ahora, con los hooks, estos son a menudo componentes funcionales mucho más simples. Los hooks pueden ser realmente simples de usar. Casi engañosamente simples. Porque todavía hay muchas formas en las que puedes equivocarte con los hooks. Y a menudo resulta que hay muchas formas en las que puedes mejorar tus componentes con una mejor comprensión de cómo se puede usar cada hook de React.Aprenderás todo sobre los pros y los contras de los diversos hooks. Aprenderás cuándo usar useState() versus useReducer(). Veremos cómo usar useContext() de manera eficiente. Verás cuándo usar useLayoutEffect() y cuándo useEffect() es mejor.
Presentando FlashList: Construyamos juntos una lista performante en React Native
React Advanced 2022React Advanced 2022
81 min
Presentando FlashList: Construyamos juntos una lista performante en React Native
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
En esta masterclass aprenderás por qué creamos FlashList en Shopify y cómo puedes usarlo en tu código hoy. Te mostraremos cómo tomar una lista que no es performante en FlatList y hacerla performante usando FlashList con mínimo esfuerzo. Usaremos herramientas como Flipper, nuestro propio código de benchmarking, y te enseñaremos cómo la API de FlashList puede cubrir casos de uso más complejos y aún así mantener un rendimiento de primera categoría.Sabrás:- Breve presentación sobre qué es FlashList, por qué lo construimos, etc.- Migrando de FlatList a FlashList- Enseñando cómo escribir una lista performante- Utilizando las herramientas proporcionadas por la biblioteca FlashList (principalmente el hook useBenchmark)- Usando los plugins de Flipper (gráfico de llamas, nuestro perfilador de listas, perfilador de UI & JS FPS, etc.)- Optimizando el rendimiento de FlashList utilizando props más avanzados como `getType`- 5-6 tareas de muestra donde descubriremos y solucionaremos problemas juntos- Preguntas y respuestas con el equipo de Shopify
React, TypeScript y TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript y TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS es extremadamente popular y, por lo tanto, ampliamente soportado. TypeScript está ganando popularidad y, por lo tanto, cada vez más soportado.

¿Los dos juntos? No tanto. Dado que ambos cambian rápidamente, es difícil encontrar materiales de aprendizaje precisos.

¿React+TypeScript, con los IDEs de JetBrains? Esa combinación de tres partes es el tema de esta serie. Mostraremos un poco sobre mucho. Es decir, los pasos clave para ser productivo, en el IDE, para proyectos de React utilizando TypeScript. En el camino, mostraremos el desarrollo guiado por pruebas y enfatizaremos consejos y trucos en el IDE.