Desarrollo de Gutenberg con ejemplos: Google Maps (parte 3)

Bienvenido a la tercera y última publicación sobre cómo crear un complemento de mapas para Gutenberg. Nuestra última publicación fue bastante densa y vimos muchas cosas diferentes: los atributos que tiene nuestro bloque, cómo insertar un mapa usando un componente React, cómo usar los componentes de WordPress o incluso crear nuestros propios componentes para definir la interfaz de usuario, etc. Hoy hablaremos de algo más simple.

En esta publicación, veremos cómo representar el mapa de Google Maps en el front-end. Para ello, echaremos un vistazo más de cerca a save.js y haremos algunos cambios en el complemento para que todo funcione como se espera. También aprovecharé este último post para comentar cualquier punto que no haya quedado claro hasta ahora.

Cómo guardar nuestro bloque de mapa para mostrarlo en el front-end

Para mostrar el mapa en el front-end, primero tenemos que definir el HTML que queremos que se represente en el front-end. En un bloque de Gutenberg, esto se logra definiendo el método de save de la función registerBlockType . Como ya mencioné en el post anterior, este método está definido en el archivo save.js en packages/blocks/nelio-maps/ .

Nuevamente, esta es una función extremadamente simple de entender:

• De la línea 7 a la 25 extraemos todos los atributos que son relevantes para nuestro bloque. Es decir, todos los atributos que definimos en attributes.js y que modifican la apariencia de nuestro mapa.
• En la línea 41 abrimos el div que servirá como contenedor para el bloque.
• En la línea 47 encontramos un div que envolverá el propio mapa. Mira algo muy interesante: este div incluye todos los attributes del objeto en su definición. Esto significa que todas las propiedades de los attributes (por ejemplo, 'data-lat': lat de la línea 34) se representarán como atributos HTML (por ejemplo, suponiendo que la variable lat sea 2,48171 , lat aparecerá en el HTML final como data-lat="2.48171" ).
• En la línea 49, se agrega un pequeño div que contiene las coordenadas del marcador.
• En la línea 59, el contenido del RichText que habíamos definido en edit.js

Entonces, en esencia, el método save genera un HTML que contiene todos los atributos que son relevantes para representar un mapa en el front-end. ¿Entonces, qué podría salir mal? Bueno, si tuvieras que abrir el front-end ahora, todo lo que verías sería esto:

Un bloque vacío que solo tiene algo de contenido RichText . ¿Qué sucedió?

Cómo modificar el complemento para renderizar un mapa de Google creado con nuestro bloque de Gutenberg

Para mostrar un mapa de Google en el front-end, es necesario que carguemos la biblioteca de Google Maps y un script que lo use para construir el mapa en sí. Esto es extremadamente simple y si alguna vez ha desarrollado para WordPress, debe saber cómo hacerlo.

Lo primero que debemos hacer es crear un script que pueda construir un mapa de Google usando los datos que hemos puesto en el HTML. Este script está en assets/src/js/public/public.js . Echa un vistazo más de cerca para entender cómo funciona:

• En la línea 9 buscamos todos los nodos que contienen un mapa (filtrando por una de las clases que hemos incluido en el método save ) y, para cada uno de ellos, llamamos al método initGoogleMap .
• Este método se basa en dos funciones para hacer su trabajo. Por un lado extrae las coordenadas de un posible marcador con la función extractMarkerPositionIfAny de la línea 55 y por otro extrae todas las propiedades del mapa (coordenadas del centro, nivel de zoom, lista de botones visibles, etc) con la función extractMapOptions de la línea 26. Tenga en cuenta que ambas funciones simplemente se dedican a leer los valores de los atributos data-something que habíamos puesto en el método de save .
• Finalmente, creamos un mapa (línea 18) y agregamos un marcador (línea 21) utilizando las clases Map y Marker , respectivamente, proporcionadas por la biblioteca de Google Maps.

Ahora que tenemos este script, solo necesitamos dos ajustes adicionales en nuestro proyecto:

• Por un lado, debemos modificar el archivo de configuración de webpack webpack.config.js para que transpile el script public.js que acabamos de crear. Puede sonar difícil, pero en realidad es bastante fácil: solo mire los cambios que hice en ese archivo en este compromiso.
• Por otro lado, tenemos que modificar el complemento para poner en cola este nuevo script (¡y la biblioteca de Google Maps!) en el front-end. Nuevamente, un cambio muy simple que puedes ver en este compromiso.

Una vez realizados todos estos cambios, este es el resultado final:

Sé lo que estás pensando: ¿por qué, en lugar de hacer todo esto a mano, no usamos el componente React que habíamos usado en edit.js ? ¿Esto no ahorraría algo de tiempo?

De hecho, usar el componente React que vimos en la publicación anterior nos habría ahorrado algunos problemas... pero hay un problema: se basa en React, lo que significa que tendríamos que cargar React en el front-end para usarlo también. Y eso parece demasiado, ¿no crees?

Detalles pendientes

Finalmente, permítanme discutir brevemente un aspecto que es muy importante, de lo contrario, su complemento no funcionará: la clave API de Google Maps.

La clave API de Google Maps

Para utilizar Google Maps, debe tener una clave API. Cómo conseguirlo es algo que nos explicó Antonio hace unos días. Ahora, ¿cómo lo usamos?

Una opción sería codificar nuestra clave API en el complemento. Si eres el único que usará el complemento, eso sería suficiente. Pero si planea distribuir su complemento a usuarios reales, es una muy mala idea, porque no todos los servicios de Google son gratuitos; algunos son pagos y los costos pueden ser bastante altos si todos usan su clave.

¿Qué hacer en estos casos? La idea es muy simple: simplemente agregue una opción de configuración en el complemento para que las personas ingresen su propia clave API.

En nuestro caso, si agrega un mapa sin clave API, verá el siguiente mensaje de advertencia:

instándolo a agregar la clave API.

Por lo general, crearía una página especial para administrar la configuración de su complemento. Pero para un complemento tan fácil y simple como el que estamos creando, pensé que sería más fácil si optábamos por una solución diferente.

En WordPress hay una pantalla de opciones en /wp-admin/options.php que se ve así:

Es una especie de “interfaz agradable” para editar (casi) todas las opciones que se han registrado en WordPress y están en la tabla wp_options . Por lo tanto, todo lo que nuestro complemento tiene que hacer es asegurarse de que esta opción siempre exista en la base de datos (incluso cuando aún no haya una clave API configurada) y tendremos una "interfaz agradable" para que el usuario pegue su clave API sin hacer nada !

Para lograr esto, usa el gancho init (ver línea 73 de este compromiso) con una función (línea 134) que siempre establece un valor para tu opción clave. Si la opción aún no existe, esta función establecerá su valor en el valor predeterminado (una cadena vacía) y guardará la opción. Si ya existía, el nuevo valor será el mismo que ya teníamos, por lo que la función de actualización no hará nada. ¡Un truco inteligente y efectivo!

En resumen

En este post hemos superado la última barrera de nuestro proyecto: cómo guardar el mapa y cómo mostrarlo en el front-end. Básicamente, todo lo que necesitábamos era un div con toda la información relevante sobre el mapa (su centro, opciones para mostrar los botones, el marcador, etc.) y un pequeño script para reconstruirlo en el front-end.

Espero que este tutorial te haya gustado y te sirva de ejemplo para emprender tus propios proyectos. Como puedes ver, si empiezas un nuevo proyecto con una buena base como la que hemos creado en Nelio con el modelo repetitivo para el desarrollo de Gutenberg, materializar tus ideas en proyectos reales será mucho más fácil.

Si tiene alguna pregunta, háganoslo saber en la sección de comentarios a continuación. ¡Buena suerte!

Imagen destacada de Artem Bali en Unsplash .