 A mi ponencia, a Taller, programando un Bloque Gutenberg en React desde cero. Vamos a intentar ser un poco ágiles porque empezamos un poco tarde. Bueno, lo primero gracias a los miembros de la organización por elegir mi ponencia. El objetivo de esta ponencia es sobre todo para todos aquellos que vengáis del mundo WordPress, PHP, etc., que muchas veces comentamos, ¿no?, que suele haber cierta tendencia al miedo a meternos en React, a programar bloques, etc. Pues, esta ponencia es para que os quitéis todos esos miedos y veáis que con ciertos conceptos que vamos a aprender hoy se puede hacer sin ningún problema. Bueno, lo primero me presento, no soy Troy McClure, ¿vale? Pero me podréis recordar de otras ponencias de la Work on Zaragoza. Mi nombre es Joaquín Ruiz, soy ingenio informático con más de 12 años de experiencia. Estoy especializado en desarrollo web. Bueno, y actualmente trabajo como CTO en Flath 101 y también soy profesor en grado superior en el Centro San Valero, ¿vale? Con esta introducción, vamos a ver hoy. Lo hemos dividido en tres partes. En una primera parte, vamos a ver el concepto de SPA. Vamos a diferenciar que es una SPA y que es una web tradicional. Luego, en la segunda parte, vamos a ver los conceptos clave de React que necesitamos para ver los bloques Gutenberg. Hay más, pero vamos a ver los tres conceptos clave. Y, por último, haremos aquí en directo un bloque Gutenberg desde cero en React, ¿vale? Pues empezamos. Lo primero, ¿qué es una SPA? Antes de empezar a ver lo que es una SPA, vamos a recordar un poco cómo funciona una web tradicional. Una web tradicional, ¿qué es lo que pasa cuando yo introduzco en la barra de direcciones del navegador una URL? En ese momento, mi navegador le manda una petición a un servidor. Ese servidor le devuelve el HTML. El navegador lee el HTML, lo renderiza y lo tenemos. Yo luego clico en cualquier elemento del menú, en cualquier enlace y mi navegador vuelve a hacer otra petición al servidor. El servidor le envía otro HTML. Mi navegador, el HTML que tenía antes, lo tira y lo reemplaza por completo por este HTML. Y, entonces, tenemos una sensación como que se recarga la página, ¿vale? Hemos clicado en algo, se ha puesto en blanco y ha aparecido otra cosa nuevo. ¿Por qué? Porque mi navegador está reemplazando todo el contenido. Con SPA, eso no ocurre, ¿por qué? Cuando yo introduzco algo en la URL, ¿vale? Mi navegador, la primera petición, es exactamente igual que la de la web tradicional, pero el servidor, además de nuestro HTML, nos envía una serie de framework JavaScript, ¿vale? Que va a ser muy importante luego. ¿Por qué? Porque luego, cuando yo hago clic en cualquier otro elemento de mi web, la petición la va a hacer este framework JavaScript, ¿vale? No la hacemos directamente desde una petición HTTP, sino que le hace el framework JavaScript y, simplemente, el servidor nos está devolviendo datos. Esos datos pueden contener HTML también, pero es nuestro framework JavaScript el que se dedica a ciertas páginas de nuestro HTML que tengo inicialmente a cambiarlo. Por lo tanto, no estoy cambiando todo el HTML, sino ciertas partes, ¿de acuerdo? Por lo tanto, no tenemos esa sensación de que se me recarga la página. De hecho, nuestra página sigue siendo en todo momento, incluso si todavía nuestro servidor no nos ha devuelto lo que hemos dicho, sigue siendo completamente receptiva a que yo siga haciendo clic o siga funcionando con la página, ¿vale? Por lo tanto, aquí tendríamos la comparativa, la web tradicional, estamos haciendo peticiones, una vez recibo el HTML, lo reemplazo y vuelvo a recargar la página, y con una SPA, pues es el propio componente, los propios componentes, los que se comunican con el servidor, y no se me recarga y, por lo tanto, en el navegador yo tengo un tipo de usabilidad mucho más atractiva, ¿vale? No estoy viendo todo el rato recargarse la página, ¿sí? Pues esto es el primer concepto, fácil, ¿vale? Vamos a ver cómo hacer esto con React. ¿Qué es lo que hemos estado comentando? Que nuestro framework JavaScript se dedica a cambiar zonas del HTML con lo que le ha dicho el servidor, ¿de acuerdo? ¿Cómo hacemos esto? Si muchos de los que estáis aquí sabréis utilizar JavaScript o jQuery para coger elementos del HTML y cambiarles el contenido, añadirles clases, cambiarles lo que sea, ¿vale? Eso como lo solemos hacer, lo solemos hacer con lo que llamamos browserdom, ¿de acuerdo? Cogemos y decimos, por ejemplo, document.getElementByClassName, lo que sea y cogemos ese elemento de HTML. En este caso, el div que tiene como nombre de clase, commentbox, y tenemos funciones como HTML que es para ponerle contenido a nuestro commentbox, ¿sí? Esto con React no se hace así, ¿vale? Porque si lo tuviéramos que hacer así, pues sería un tanto complejo. ¿Cómo lo hacemos con React? Utilizando lo que llamamos virtualdom, ¿vale? Primero concepto que tenéis que tener claro es que cuando estamos utilizando una SPA no estamos accediendo directamente al HTML renderizado, sino que utilizamos el virtualdom. Este HTML está en memoria, ¿de acuerdo? Por lo tanto, es mucho más fácil implementar funciones de cambio de propiedades, etcétera. Aquí en este ejemplo, tenéis un bloque Gutenberg, ¿vale? En este caso, tenemos un trozo de sudo HTML, luego veremos un poquito más en detalle, con ciertas partes de lógica, variables, etcétera. Vamos a verlo un poquito más en detalle. Por lo tanto, tenemos componentes en todos lados, ¿vale? En vez de tener nuestro HTML tal cual, pues tendremos componentes. Estos componentes es la unidad básica para crear elementos en el virtualdom y es HTML más lógica, ¿sí? Tenemos el JavaScript y el HTML en el mismo sitio. Y esto es lo que llamamos código JSX, ¿de acuerdo? Aquí veis, por ejemplo, en este trozo de componentes tenemos HTML. Si veis, este HTML es un poco raro. Tenemos div classname, el HTML normal sería div class, ¿vale? ¿Por qué? Pues hay ciertos cambios porque al final esto no deja ser JavaScript y classname, por ejemplo, es una palabra reservada en JavaScript. Y luego tenemos aquí NAMI, ¿vale? Esto es una variable de JavaScript, de React. Estas variables es lo que llamamos props, props que viene de properties o valores de entrada. Estos valores de entrada, lo que nos permiten es cuando estamos declarando un componente poder meterle distintos tipos de contenido, ¿vale? Pues le ponemos unas variables, unos parámetros distintos, entonces nos aparecerá y nos renderizará el mismo componente con otros valores, ¿vale? Y estos props es lo que nos permite pasar intercambiar datos entre componentes. Ahora bien, yo tengo, por ejemplo, este componente y yo lo quiero modificar, ¿vale? ¿Qué pasa si yo quiero modificar sus datos? Vamos a poner un ejemplo, no sé si me va a cargar el vídeo, pero bueno, el ejemplo, mira, sí, es, yo tengo un campo de texto y luego simplemente quiero que se muestre por debajo, ¿vale? Por lo tanto, yo tendré un campo de texto en el cual yo meteré un valor y quiero que ese valor se me pinte debajo en un div. ¿Cómo podemos hacer esto? Gracias a los states, ¿vale? Los states, después de props, es el conjunto de datos que se manejan a nivel interno, ¿vale? Permite crear y gestionar nuestros propios datos. Los states, lo que nos permiten es aplicarle la lógica para modificar estos props. Yo, por ejemplo, aquí teníamos nuestro div.com.enbox con name y simplemente le hemos añadido aquí un componente que sería un input, ¿de acuerdo? En el cual el valor lo va a tener el name igual que aquí y cuando esté cambiando este valor, ¿vale? Change name, simplemente lo que estoy diciendo es que me asigne a ese valor a name. Ya está, con esto ya podemos crear nuestro bloque bootenware, ¿de acuerdo? Tenéis el ejemplo, este es el que acabamos de ver y a partir de aquí podemos hacer muchas cosas y lo vamos a ver ahora en directo, vamos a ver algo de código. Vamos allá, ¿qué es lo primero que tenemos que hacer? Vale, lo primero que tengo aquí se ve bien, lo hago un poquito más grande. Los del fondo se ve bien, regular. Venga, pues lo iré poniendo así y lo iré quitando, ¿vale? Venga, pues vamos a... ¿y eso cómo se cambia? ¿Dónde? ¿Preferencias? Lo cambiamos enseguida. Venga, perfecto, perfecto. Bueno, pues lo primero que tenemos aquí, nuestro plugin, nuestro plugin Work on Zaragoza 2023, ¿vale? Simplemente, aquí he declarado el nombre del plugin, la descripción, etcétera, etcétera y he incluido una clase donde voy a meterle todo la lógica, ¿vale? Hasta aquí no me voy a extender mucho porque entiendo que todos sabemos más o menos crear plugins, ¿vale? Entonces, aquí tengo mi clase donde voy a meter la lógica de mi plugin, ¿vale? Siempre recordad hacerlo en clases para que podamos añadir testing, etcétera. Y añado una funcionalidad tanto a los editor assets, ¿vale? Que son aquellos assets que se me van a cargar dentro de mi panel de administración como a los block assets, ¿vale? Que son aquellos assets que se me van a cargar en mi instalación de WordPress en general, ¿vale? Entonces, lo primero que tengo que hacer es en backend. Bueno, vamos a hacerlo. Primero, en general, voy a registrar un bloque boot ember, ¿vale? Para ello, tengo por aquí la chuleta, me la hace un segundo. Voy a coger y voy a registrar un bloque. ¿Cómo se registra el bloque? Llamando a la función de WordPress nativa, register block type. Aquí le tengo que poner un tipo de bloque, el nombre que yo quiera, le llamo hokeyread-workupblock y después le tengo que decir el script, el javascript, que va a cargar la lógica de este bloque. Por lo tanto, lo siguiente que tengo que hacer es meter el javascript, que va a meter la lógica de este bloque. Ese javascript lo voy a meter a nivel de backend. Le llamo workup scripts, que es el que le digo aquí, ¿sí? Le digo que me lo cargue en la url del plugin, donde va a estar mi fichero react, va a estar en build-index.js. Me tendré que crear en index.js toda la lógica de react. Ahora se explico cómo. Y luego le tengo que poner qué dependencias va a tener. Para un bloque boot ember normal, hay que poner estas dependencias de javascript, ¿vale? Simplemente yo cargo esto y ya voy a tener un javascript con react y en la memoria del WordPress, en el PHP, le voy, va a ir a buscar este bloque, ¿vale? Yo puedo ir a mi instalación, activar mi plugin, work on Zaragoza 2023 y yo cuando vaya ahora a editar un post que tengo por aquí, me va a decir, este caso sí porque sí que existe, lo voy a quitar para que lo veáis, me dirá que build-index.js no existe porque todavía no lo hemos creado, ¿vale? Hasta aquí todo es bien. Estamos metiendo assets en la parte global, le estamos registrando y en el otro le estamos diciendo que va a haber un fichero javascript por ahí en el que vamos a tener la lógica del bloque boot ember. Ahora tengo que empezar a montar el entorno para poder montar este bloque boot ember. ¿Cómo se hace eso? Yo tengo que instalar node en mi ordenador, ¿de acuerdo? Y tengo que crear un proyecto de node. Un proyecto de node, tenemos que ejecutar npm init, ¿vale? Cuando ejecutamos npm init nos va a crear un fichero como este, package.json. En este fichero yo puedo añadir dependencias para añadir librerías externas. Esto es como por ejemplo composer, exactamente que composer en PHP, ¿vale? Pues package.json sería el composer.json, añado las dependencias. ¿Qué dependencia tengo que añadir? La de WordPress Scripts, ¿vale? Es una dependencia de node que ha creado ya WordPress para nosotros, donde tenemos muchísimos componentes base para toda la funcionalidad que queramos añadir de los bloques boot ember. Una vez yo tengo esto le daré a npm install, npm install, que es igual que composer install, ¿de acuerdo? Una vez me va a crear una carpeta no de modules, donde vamos a tener todas las librerías que me han creado estos WordPress Scripts. Esto es como el vendor de composer. Una vez yo tengo eso tengo que crearme dos carpetas. La carpeta src, donde tendré la declaración de mi bloque boot ember original, y una carpeta build, que es la carpeta donde se pondrá el ndjs que yo voy a cargar. ¿Por qué? Porque el react hay que compilarlo, ¿de acuerdo? No puedo cargar el original, tengo que cargar el compilado. Para compilarlo tenemos aquí unos Scripts, que nos da propio WordPress, que es wpscript-start y wpscript-build, que lo que hacen es compilarmelo. Lo que tengan el src me lo pone en el build, ¿sí? Y entonces el build.js, ndjs, es el fichero que yo he metido aquí, ¿vale? Pues vamos allá. Sí, tienes que estar al nodi. La librería que te mete WordPress, the WordPress Scripts, esa ya tiene cositas de ría, exacto. Todo lo que necesito, exacto. Exacto, exacto. Simplemente con nodi, tú en el package.json le dices npn-require de WordPress Scripts, y lo tienes, efectivamente. Todo lo necesario para hacerlo. Entonces, en nuestro ndjs, vamos a crear, esto es lo que habéis visto en la presentación, ¿vale? Simplemente un test control, un input con nuestro name, que llama la función changeName, que simplemente en el changeName le estoy diciendo que el name, que es uno de los props, que le hemos añadido este componente, se me muestre en el visor, ¿vale?, en el div que tenemos por debajo. Para ello, ¿qué es lo primero que tenemos que hacer? Llamar a la función registerBlockType. La función registerBlockType está dentro de las librerías que acabamos de instalar con nodi. Por ello, tenemos que hacer input, import registerBlockType de WordPress blocks. Y, por ejemplo, yo he añadido un input que ya trae WordPress, que es el test control. ¿Vale? Tienen varios, hay varios. Luego instalaremos otro, para que lo veáis. Y este lo traemos de WordPress components. Entonces, yo registro mi tipo de bloque, le doy un título, le doy una descripción, le digo en qué categoría de bloques quiero que aparezca. Ahora lo veremos en el panel de administración, más claro. Y aquí le meto los props que yo voy a utilizar. En este caso, el nombre. Name. Y después tengo dos funciones que tengo que rellenar. La función edit, que es lo que yo voy a ver en el panel de administración cuando estoy añadiendo el bloque. Y la función save, que es lo que voy a ver en el front. ¿Vale? Que es lo que voy a ver por pantalla. Aquí, por ejemplo, hemos metido el input y lo que veríamos, nuestro name. Y aquí, lo que yo veo por pantalla, solo he metido el name. Porque en la parte frontal no quiero que se me vea ninguna opción ni nada. Quiero que se me vea renderizado. ¿Vale? Entonces, aquí simplemente ejecutaremos en bienroom build. Y esto lo que me hace es coger y llamar a-wp-scree-build. Y aquí en build me aparecerá mi fichero indes.js. Entonces, yo aquí vengo a la página. Aquí me salió un error porque no estaba. ¿Vale? Recargo. Le doy a añadir bloque. Digo que vamos a ver todos. Y en text, que es donde le he dicho que quiero que me aparezca, me aparece un bloque que es work on Zaragoza. Y es el que acabamos de ver. ¿Vale? ¿Sí? Hasta aquí, todos claro. Pues vamos a, lo primero, si veis aquí el bloque tiene un icono un poco feo, ¿verdad? Vamos a cambiarle el icono. ¿Cómo podemos cambiar el icono? Le vamos a poner muchos iconos que ya vienen en la librería de WordPress. Pero también podemos meterles iconos propios si lo sacamos a SVG, ¿vale? Pues, por ejemplo, yo he cogido... ¿Dónde lo tengo por aquí? Bueno, el icono, ¿vale? He cogido este icono. Me lo he guardado en una variable de JavaScript y lo voy a meter... Voy a meter primero esta variable, ¿de acuerdo? Que es un SVG, ¿vale? Los SVG, no sé si sabéis, son tipos de imágenes que no son mapas de bit, sino que son conjunto de objetos, ¿vale? Por eso se pueden meter de esta forma. Y voy a ponerle, le voy a decir, aparte de decirle en mi register block type con el nombre, la categoría, etcétera, etcétera, le voy a decir que utilicé este icono. Entonces, yo aquí le doy otra vez a compilar. Voy a recargo la página. Y ahora mismo, cuando venga aquí, pues tendré un icono, ¿vale? Para mí, block Gutenberg. Y me aparece aquí, aquí y en todos lados. Vale, siguiente paso. Vamos a añadirle estilos, ¿vale? Para añadirle estilos, simplemente le tengo que decir un archivo CSS que quiero que se me meta en los assets, de la misma forma que hemos metido en el archivo JS, ¿vale? Eso es código de WordPress, de PHP, ¿vale? Por lo tanto, vamos a ponerle en nuestro, donde hemos metido el script, vamos a meterle un style, ¿vale? Que va a ser el plugin URL editor.css. Por lo tanto, yo aquí me vendré, me crearé un editor.css y le voy a meter unos estilos. Voy a meter ciertos estilos, que yo quiero que aparezcan en mi bloque Gutenberg. Entonces, yo simplemente aquí recargo la página, añado mi bloque Gutenberg y ya me aparecen ciertos estilos. Entonces, digo aquí hola WordPressers y me aparecen estos estilos. Yo esto le doy a update, ¿vale? Y vengo aquí y veis que aquí no me aparecen esos estilos. ¿Por qué puede ser esto? Bueno, pues porque aquí hemos metido estos estilos en la parte de los assets del editor, ¿vale? Si metemos este css en la parte de los estilos del frontend, vamos a cambiar este nombre, vamos a llamar frontend, le podemos poner otros estilos distintos, ¿vale? Pero sí que tiene sentido que los tengamos encapsulados en el mismo y así vemos lo mismo, lo que vamos a ver en nuestro editor, lo que vamos a ver en la parte del frontend. Recargo la página y ya me salen los estilos. Vamos a meterle algo más de funcionalidad, ¿vale? Esto es lo que habíamos visto hasta ahora en la ponencia. Vamos a ponerle también que podamos cambiar la imagen de fondo, ¿vale? ¿Cómo hacemos eso? Muy fácil. Tenemos en nuestro indes.js al igual que hemos cogido el test control, hay otro tipo de componente que me permite subir imágenes, ¿vale? Otro componente que es propio de Wordpress. Ese componente es el media upload, ¿vale? Entonces lo importo aquí y yo lo puedo añadir en nuestro panel de administración debajo de nuestro test control, ¿vale? Cojo aquí y introduzco nuestro media upload. Ahora bien, ahora aparte de un texto de lo que hemos llamado NAMM, vamos a tener una imagen. Esa imagen la tenemos que añadir a los props, ¿vale? Tenemos que añadir esta imagen a los props. Lo primero que tenemos que hacer es añadirla aquí en los atributos del bloque Utenber, la vamos a llamar IMGURL, que va a ser un tipo string, va a ser la URL, que va a ser el SRC de nuestro IMG. Después tenemos que meter esta IMGURL dentro de las propiedades o props de nuestro componente, tanto el componente que estamos haciendo en el editor como el del frontend. Por lo tanto vendremos aquí y diremos que metemos IMGURL, sacamos de nuestros props IMGURL y aquí igual. Una vez tenemos esto en nuestro media upload, tenemos ciertas informaciones, ¿vale? Igual que teníamos aquí que cuando cambiamos le damos a change name, aquí le decimos que cuando subamos, esto es el preview y aquí tenemos que cuando seleccione una imagen le dea selectImage, ¿sí? Pues aquí yo me tendré que crear una función selectImage, ¿vale? Igual que teníamos la de change name, ¿vale? La tengo por aquí, que hace prácticamente lo mismo. Le hice set atributes, ¿vale? En este caso en vez de aname le cambia el atributo a IMGURL y aquí si vamos a la documentación de este módulo, ¿vale? de media upload nos dirá que el valor de la URL es esta cadena, ¿vale? También lo podemos inspeccionar con un console log y mirar a ver qué nos devuelve value y coger aquel parámetro o aquel valor que nos interesa. Y por aquí tendríamos todo, como veis, bueno, me faltaría el alo web media types, ¿vale? que le vamos a decir aquí, que es imagen, hay que ponerlo con un array, perfecto, ¿sí? Entonces con esto tendríamos, vamos a compilarlo primero si no nos aparece en el build, ¿vale? Se compilar correctamente, así que eso es que lo hemos hecho bien y venimos al editor y como veis nos aparece aquí el sube imagen de fondo yo puedo coger una imagen y puedo subir cualquiera de las imágenes que tenga en la galería, ¿vale? Selecciono, pero ahora quiero que me aparezca aquí esta imagen por lo tanto tendremos que ir al visor y añadirle un estilo para que nos aparezca como background imagen. Entonces venimos aquí, tengo aquí la chuleta, vamos primero a la parte de aquí y me creo una constante style, ¿vale? que simplemente le estoy diciendo que el background imagen sea uno de mis props, el imgurl y directamente cojo aquí y en mi visor le digo que style sea style, ¿vale? Venimos aquí, compilamos, mira, ahora me pide la contraseña, pues la pondremos y aquí cuando subimos una imagen, vamos a subir otra distinta por ejemplo, esta de la label, pues me parece la imagen que acabo de seleccionar y el texto que estoy poniendo, ¿vale? Entonces yo aquí le doy update, se me actualiza, vengo aquí y como veis aquí no me aparece la imagen porque no la hemos cambiado, efectivamente. Tenemos que venir aquí abajo en el save y hacer exactamente lo mismo. Cogemos el style, venimos aquí atrás, debajo de, nos sacamos los props y aquí en mi div le decimos que style sea mi parámetro style o mi... pues aquí recargamos y ya lo tendríamos, ¿vale? No nos está pareciendo, algo hemos hecho mal, a ver, igual lo estamos poniendo mal, ¿eh? y imgurl está bien, venimos aquí, es que muchas veces cuando estamos cambiando los bloques esto suele pasar y aquí me veremos la imagen de fondo, y ahora sí, nos aparece, ahora podemos meter otro debajo, aquí ponemos un bloque que sea lo que sea y aquí metemos otra vez nuestro bloque, tantas veces como queramos y en este caso pues ponemos la original, vemos como nos puede quedar, recargamos y nos aparece con nuestros dos bloques, ¿vale? Entonces, recapitulando un poquito, ¿vale? y con esto ya acabamos, ¿qué es lo que hemos hecho? Hemos creado un plugin, ¿vale? Hemos declarado el plugin con nombre, descripción, etcétera, etcétera, hemos incluido una clase que lo añade la lógica del plugin, hemos registrado nuestro bloque en la parte global, la que hemos puesto en... hemos llamado el método frontend, y luego hemos añadido los ficheros React que vamos a generar, los que se generan cómbil, con WP en Qscript, ¿vale? os he puesto aquí las URLs de la referencia de WordPress Docs, subiré las slides para que lo podáis ver en más detalle con el que parámetros hemos utilizado, cuales no, etcétera, ¿vale? Entonces, aquí hemos pasado a la parte de React, lo primero, instalar node con nuestro package JSON, hemos metido todas las dependencias de WordPress Scripts, ¿vale? aquí sale también con lo primero como lo podéis hacer desde línea comandos, nuestro WordPress Scripts, la referencia del código de NPM, después en Index.js hemos importado la función register block type, hemos hecho el import de register block type desde WordPress blocks, que es lo mínimo que necesitamos, una vez ahí hemos metido el nombre de la descripción, el icono que lo hemos cambiado luego, y nuestras métodos o funciones, edit y save, edit, hemos metido nuestro componente de la parte de administración y en save hemos metido el componente que se va a renderizar en el front-end, ¿vale? Aquí tenéis un poco los parámetros de register block type, el título, que es lo que nos aparece aquí, la descripción que aparece en la barra de la derecha, el icono que hemos metido y la categoría, que en este caso la habíamos metido como categoría text. Y aquí, bueno, después de declarar el bloque, de registrar el bloque, hemos metido los atributos, que en este caso serán los props necesarios, tanto NAMM como IMG URL, que luego los hemos puesto aquí y aquí, y después pues el componente del backend y el componente del front-end. Y finalmente pues le hemos añadido ciertos estilos, ¿vale? Podemos añadirles estilos, un estilo distinto al front-end que al back, bueno, en este caso hemos metido los mismos estilos para los dos. Simplemente, nos vamos a nuestro plugin de PHP de WordPress y WP en QStyle, ya sea para la parte del front-end, como para el back-end, como para las dos, ¿vale? Y como compilamos el bloque, NPM, run-start. Si queremos que esté en modo watcher, en modo escuchando cada vez que haya un cambio en el fichero y que automáticamente se me compilé, o empiega un run-bill para que se haga una vez. Y esto es todo. Espero que hayáis aprendido y tengáis menos miedo. Espero no haberos metidos más miedo todavía en el cuerpo para el tema de React. Pero bueno, ya estás. ¿Aguna duda, pregunta? Os pasan el micrófono por aquí. Buenas, muy buenas. Charla Joaquín, la verdad que lo has explicado muy claro. Te quería hacer una pregunta referente a ya que tenemos el archivo de dependencias. ¿Podríamos meter TypeScript y Styleth Components? Sí, sí, le puedes meter y cualquier tile-win, material, lo que quieras. ¿Lo has probado? Lo he probado. Porque quiero decir que ahí coge mucha potencia en el sentido de que con el CSS lo puedas estilar según la lógica que estamos comentando. Me parece que hay que tener cuidado porque daros cuenta que todo eso que estamos metiendo, sí que es cierto que, por ejemplo, la parte del backend no nos va a suponer mayor problema, pero en la parte del front-end luego tendrás que meter todos esos estilos con el que hay en QS Styles. Entonces, dependiendo de la cantidad de estilos que estás metiendo ahí para un bloque Gutenberg, si estás metiendo algo distinto o algún framework distinto al que tú tienes, por ejemplo, en tu tema, es probable que metas mucho CSS y muchas cosas en el tema del front-end. Hay que tener cuidado para no meter las cosas muchas veces. Imagínate que tú pones, por ejemplo, tile-win, CSS, ¿vale? Y te pones tu CSS para tus componentes en tile-win. Y luego coges otro componente distinto y dices, pues, ahora voy a meter Bustrap. Al final, luego en el front-end tendrás mucha cosa. Sí, sí, yo no me refería tanto a esto de framework de maquetación, sino a utilizar esa combinación para poder jugar con... En ese caso es un problema, porque date cuenta que lo que luego se renderiza no es react. Claro. Lo que tú renderizas en el tema no es react, ¿vale? Tú tienes un WordPress normal y tradicional. Y tienes la ventaja que, como todos esos componentes, están totalmente como individuales, ¿no? Encapsulados, exacto. Encapsulados no se van a pegar de ninguna manera. Genial, muchas gracias. Yo lo tengo pendiente de probar. Pues nada, ánimo. Creo que no. Que no está enchufado. Te he escuchado, ¿eh? Se puede hacer algo relacional así. Porque al final, sin recurrir a PHP, sin recurrir a ACF, sin recurrir a funciones custom, desde react se puede hacer algo relacional. Desde react, lo que puedes hacer es llamar a cualquier endpoint, por ejemplo, de WordPress, ¿vale? Por ejemplo, a la API de WordPress puedes llamar sin problema. Desde react puedes coger distintos elementos, traerlos, combinarlos. No hay problema en ese aspecto. OK. Y suele funcionar bien, además. Más rápido, más rápido. Y además, como estás en el entorno del panel de administración, para traer todos esos datos, no tienes que meter, por ejemplo, temas de autenticación en las llamadas de API y así. ¿Alguna pregunta más? ¿No? Creo que hemos clavado el tiempo, ¿no? Muchas gracias. Gracias a los seguidores.