Speichern von Einstellungen für einen benutzerdefinierten WordPress-Block im Blockeditor PlatoBlockchain Data Intelligence. Vertikale Suche. Ai.

Speichern von Einstellungen für einen benutzerdefinierten WordPress-Block im Block-Editor

Wir haben eine Menge Dinge in dieser Serie erreicht! Wir haben einen benutzerdefinierten WordPress-Block erstellt, der Daten von einer externen API abruft und auf dem Frontend rendert. Dann haben wir diese Arbeit übernommen und erweitert, sodass die Daten auch direkt im WordPress-Blockeditor gerendert werden. Danach haben wir eine Einstellungs-UI für den Block mit Komponenten aus WordPress erstellt InspectorControls Paket.

Es gibt noch ein letztes Bit, das wir behandeln müssen, und das ist das Speichern der Einstellungsoptionen. Wenn wir uns an den letzten Artikel erinnern, sind wir technisch in der Lage, unsere Auswahl in der Benutzeroberfläche der Blockeinstellungen zu „speichern“, aber diese werden eigentlich nirgendwo gespeichert. Wenn wir einige Auswahlen treffen, speichern und dann zum Beitrag zurückkehren, werden die Einstellungen vollständig zurückgesetzt.

Lassen Sie uns den Kreis schließen und diese Einstellungen speichern, damit sie beim nächsten Bearbeiten eines Beitrags, der unseren benutzerdefinierten Block enthält, beibehalten werden!

Arbeiten mit externen APIs in WordPress-Blöcken

Einstellungsattribute speichern

Wir arbeiten mit einer API, die uns Folgendes zur Verfügung stellt Fußball Rangliste der Fußballmannschaft und wir verwenden sie zum Abrufen von Ranglisten basierend auf Land, Liga und Saison. Wir können für jedes dieser Attribute neue Attribute wie folgt erstellen:

// index.js

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

Als nächstes müssen wir die Attribute von setzen LeagueSettings.js. Wann immer a ComboboxControl in unserer Einstellungs-Benutzeroberfläche aktualisiert wird, müssen wir die Attribute mithilfe von festlegen setAttributes() Methode. Dies war einfacher, als wir nur mit einem Datenendpunkt arbeiteten. Aber jetzt, da wir mehrere Eingaben haben, ist es ein wenig komplizierter.

So werde ich es organisieren. Ich werde ein neues Objekt in erstellen LeagueSettings.js das folgt der Struktur der Einstellungsattribute und ihrer Werte.

// LeagueSettings.js

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

Ich werde auch die Anfangszustandsvariablen von ändern null zu den jeweiligen Einstellungsvariablen.

// LeagueSettings.js

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

In jedem der handle______Change(), werde ich eine erstellen setLocalAttributes() das ein Argument hat, das das vorherige klont und überschreibt localSettings Objekt mit den neuen Werten für Land, Liga und Saison. Dies geschieht mit Hilfe des Spread-Operators.

// 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
}

Wir können die definieren setLocalAttributes() so was:

// LeagueSettings.js

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

Also verwenden wir Object.assign() um die beiden Objekte zusammenzuführen. Dann können wir die klonen newSettings Objekt zurück zu localSettings da wir auch jedes Einstellungsattribut berücksichtigen müssen, wenn eine neue Auswahl getroffen wird und eine Änderung auftritt.

Schließlich können wir die verwenden setAttributes() wie wir es normalerweise tun, um das endgültige Objekt festzulegen. Sie können bestätigen, ob sich die oben genannten Attribute ändern, indem Sie die Auswahlen in der Benutzeroberfläche aktualisieren.

Eine andere Möglichkeit zur Bestätigung besteht darin, eine console.log() in DevTools auszuführen, um die Attribute zu finden.

Speichern von Einstellungen für einen benutzerdefinierten WordPress-Block im Block-Editor

Schauen Sie sich diesen Screenshot genauer an. Die Werte werden gespeichert in attributes.settings. Wir können es live sehen, weil React jedes Mal neu rendert, wenn wir eine Änderung an den Einstellungen vornehmen, dank der useState() Haken.

Anzeigen der Werte in der Benutzeroberfläche der Blockeinstellungen

Es ist nicht sehr sinnvoll, die Einstellwerte in den Steuerungsoptionen selbst zu speichern, da jeder vom anderen Einstellwert abhängig ist (z. B. Rangliste nach Liga hängt davon ab, welche Saison ausgewählt ist). Es ist jedoch sehr nützlich in Situationen, in denen die Einstellungswerte statisch und die Einstellungen unabhängig voneinander sind.

Ohne die aktuellen Einstellungen zu verkomplizieren, können wir im Einstellungsfenster einen weiteren Abschnitt erstellen, der die aktuellen Attribute anzeigt. Sie können wählen, wie Sie die Einstellungswerte anzeigen möchten, aber ich werde eine importieren Tip Komponente von dem @wordpress/components Paket:

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

Während ich hier bin, werde ich eine bedingte Überprüfung der Werte durchführen, bevor ich sie in der darstelle Tip Komponente:


  {country && league && season && (
    
      

Current Settings:

Country: {attributes.settings.country}
League: {attributes.settings.league}
Season: {attributes.settings.season}
)}

So funktioniert das im Blockeditor:

API-Daten sind leistungsfähiger, wenn Live-Daten angezeigt werden können, ohne sie jedes Mal manuell aktualisieren zu müssen. Darauf gehen wir im nächsten Teil dieser Serie ein.

Zeitstempel:

Mehr von CSS-Tricks