Guardar la configuración de un bloque de WordPress personalizado en el editor de bloques

¡Hemos logrado un montón de cosas en esta serie! Creamos un bloque personalizado de WordPress que obtiene datos de una API externa y los representa en la interfaz. Luego tomamos ese trabajo y lo ampliamos para que los datos también se muestren directamente en el editor de bloques de WordPress. Después de eso, creamos una interfaz de usuario de configuración para el bloque usando componentes de WordPress InspectorControls paquete.

Hay una última parte que debemos cubrir y es guardar las opciones de configuración. Si recordamos el último artículo, técnicamente podemos "guardar" nuestras selecciones en la interfaz de usuario de configuración del bloque, pero en realidad no se almacenan en ningún lado. Si hacemos algunas selecciones, las guardamos y luego volvemos a la publicación, la configuración se restablece por completo.

¡Cerremos el ciclo y guardemos esas configuraciones para que persistan la próxima vez que editemos una publicación que contenga nuestro bloque personalizado!

Guardar atributos de configuración

Estamos trabajando con una API que nos proporciona fútbol clasificación del equipo de fútbol y lo estamos usando para buscar y mostrar las clasificaciones según el país, la liga y la temporada. Podemos crear nuevos atributos para cada uno de ellos como este:

// index.js

attributes: {
  data: {
    type: "object",
  },
  settings: {
    type: "object",
    default: {
      country: {
        type: "string",
      },
      league: {
        type: "string",
      },
      season: {
        type: "string",
      },
    },
  },
},

A continuación, debemos establecer los atributos de LeagueSettings.js. Cada vez que un ComboboxControl se actualiza en nuestra interfaz de usuario de configuración, necesitamos establecer los atributos usando el setAttributes() método. Esto fue más sencillo cuando solo trabajábamos con un punto final de datos. Pero ahora que tenemos múltiples entradas, es un poco más complicado.

Así es como lo voy a organizar. Voy a crear un nuevo objeto en LeagueSettings.js que sigue la estructura de los atributos de configuración y sus valores.

// LeagueSettings.js

let localSettings = {
  country: attributes.settings.country,
  league: attributes.settings.league,
  season: attributes.settings.season,
};

También voy a cambiar las variables de estado inicial de null a las respectivas variables de configuración.

// LeagueSettings.js

const [country, setCountry] = useState(attributes.settings.country);
const [league, setLeague] = useState(attributes.settings.league);
const [season, setSeason] = useState(attributes.settings.season);

En cada uno de los handle______Change(), voy a crear un setLocalAttributes() que tiene un argumento que clona y sobrescribe el anterior localSettings objeto con los nuevos valores de país, liga y temporada. Esto se hace con la ayuda del operador de propagación.

// LeagueSettings.js

function handleCountryChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, country: value });
  // Rest of the code
}

function handleLeagueChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, league: value });
  // Rest of the code
}

function handleSeasonChange(value) {
  // Initial code
  setLocalAttributes({ ...localSettings, season: value });
  // Rest of the code
}

Podemos definir el setLocalAttributes() Me gusta esto:

// LeagueSettings.js

function setLocalAttributes(value) {
  let newSettings = Object.assign(localSettings, value);
  localSettings = { ...newSettings };
  setAttributes({ settings: localSettings });
}

Entonces, estamos usando Object.assign() para fusionar los dos objetos. Entonces podemos clonar el newSettings objeto de nuevo a localSettings porque también debemos tener en cuenta cada atributo de configuración cuando se realiza una nueva selección y se produce un cambio.

Finalmente, podemos usar el setAttributes() como hacemos normalmente para fijar el objeto final. Puede confirmar si los atributos anteriores están cambiando actualizando las selecciones en la interfaz de usuario.

Otra forma de confirmar es hacer un console.log() en DevTools para encontrar los atributos.

Mire más de cerca esa captura de pantalla. Los valores se almacenan en attributes.settings. Podemos verlo en vivo porque React se vuelve a renderizar cada vez que hacemos un cambio en la configuración, gracias a la useState() gancho.

Mostrar los valores en la interfaz de usuario de configuración de bloques

No es muy útil almacenar los valores de configuración en las propias opciones de control, ya que cada uno depende del otro valor de configuración (por ejemplo, las clasificaciones por liga dependen de la temporada seleccionada). Pero es muy útil en situaciones donde los valores de configuración son estáticos y donde las configuraciones son independientes entre sí.

Sin complicar la configuración actual, podemos crear otra sección dentro del panel de configuración que muestre los atributos actuales. Puede elegir su forma de mostrar los valores de configuración, pero voy a importar un Tip componente del desplegable @wordpress/components paquete:

// LeagueSettings.js
import { Tip } from "@wordpress/components";

Mientras estoy aquí, voy a hacer una verificación condicional de los valores antes de mostrarlos dentro del Tip componente:

  {country && league && season && (
    
      
Current Settings: 
      

        

          Country: {attributes.settings.country}
        
        

          League: {attributes.settings.league}
        
        

          Season: {attributes.settings.season}
        
      
    
  )}

Así es como termina funcionando en el editor de bloques:

Los datos de API son más poderosos cuando se pueden mostrar datos en vivo sin tener que actualizarlos manualmente cada vez. Veremos eso en la próxima entrega de esta serie.