Guardar configuraciones personalizadas de bloques de WordPress en el Editor de bloques | trucos CSS

¡Logramos mucho en esta serie! Creamos un bloque personalizado de WordPress que extrae datos de una API externa y los representa en la interfaz. Luego tomamos este trabajo y lo ampliamos para que los datos también se representen directamente en el editor de bloques de WordPress. A continuación, creamos una interfaz de usuario de configuración para el bloque utilizando componentes de WordPress. InspectorControls paquete.

Hay un último punto 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. Hacemos algunas selecciones, las guardamos, luego volvemos a la publicación, la configuración se restablece por completo.

¡Cerremos el ciclo y guardemos esta configuración para que persista la próxima vez que editemos una publicación que contenga nuestro bloque personalizado!

Guardar atributos de configuración

Trabajamos con la API que nos proporciona fútbol Clasificación de equipos de fútbol y la usamos para extraer y mostrar clasificaciones según el país, la liga y la temporada. Podemos crear nuevos atributos para cada uno de ellos así:

// 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.jsSiempre que un ComboboxControl se actualiza en nuestra interfaz de usuario de configuración, necesitamos establecer los atributos usando el setAttributes() Esto fue más fácil cuando trabajábamos con un solo punto final de datos. Pero ahora que tenemos múltiples entradas, es un poco más complicado.

Así es como voy a organizarlo. 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 cambiaré las variables de estado inicial de null a las variables de configuración correspondientes.

// 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 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 usando el operador spread.

// 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 setLocalAttributes() como esto:

// LeagueSettings.js

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

Entonces, usamos Object.assign() para fusionar los dos objetos. Entonces podemos clonar newSettings objeto de nuevo a localSettings ya que 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 setAttributes() como hacemos normalmente para fijar el objeto final. Puede confirmar si los atributos anteriores cambian actualizando las selecciones en la interfaz de usuario.

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

Eche un vistazo más de cerca a esta captura de pantalla. Los valores se almacenan en attributes.settingsPodemos 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 valores en la interfaz de usuario de configuración del bloque

No es muy útil almacenar los valores de configuración en las propias opciones de gestión, ya que cada uno depende del otro valor de configuración (por ejemplo, la clasificación de la liga depende 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 en el panel de configuración que muestre los atributos actuales. Puede elegir su forma de mostrar los valores de configuración, pero importaré Tip componente de @wordpress/components paquete:

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

Mientras estoy aquí, haré una verificación condicional de los valores antes de mostrarlos en el Tip componente:

<Tip>
  {country && league && season && (
    <>
      <h2>Current Settings: </h2>
      <div className="current-settings">
        <div className="country">
          Country: {attributes.settings.country}
        </div>
        <div className="league">
          League: {attributes.settings.league}
        </div>
        <div className="season">
          Season: {attributes.settings.season}
        </div>
      </div>
    </>
  )}
</Tip>

Así es como esto completa el trabajo en el editor de bloques:

Las API de datos son más poderosas cuando se pueden mostrar datos en vivo sin tener que actualizarlos manualmente cada vez. Veremos esto en la próxima parte de esta serie.