Wir haben in dieser Reihe viel erreicht! Wir haben einen benutzerdefinierten WordPress-Block erstellt, der Daten von einer externen API abruft und sie im Frontend rendert. Dann haben wir diese Arbeit übernommen und sie erweitert, sodass die Daten auch direkt im WordPress-Block-Editor gerendert werden. Danach haben wir eine Einstellungs-UI für den Block mit Komponenten aus dem WordPress InspectorControls Paket erstellt.
Es gibt noch ein letztes Thema, 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 Block-Einstellungs-UI zu „speichern“, aber diese werden tatsächlich nirgends gespeichert. Wenn wir ein paar Auswahlen treffen, sie speichern und dann zum Beitrag zurückkehren, sind die Einstellungen vollständig zurückgesetzt.
Lass uns den Kreis schließen und diese Einstellungen speichern, damit sie beim nächsten Mal, wenn wir einen Beitrag bearbeiten, der unseren benutzerdefinierten Block enthält, erhalten bleiben!
Arbeiten mit externen APIs in WordPress-Blöcken
- Daten im Frontend rendern
- Daten im Backend rendern
- Erstellen einer benutzerdefinierten Einstellungs-UI
- Speichern von benutzerdefinierten Blockeinstellungen (Sie sind hier!)
- Arbeiten mit Live-API-Daten (bald verfügbar)
Speichern von Einstellungsattributen
Wir arbeiten mit einer API, die uns die Rangliste von Fußball Football-Teams liefert, und wir nutzen sie, um Ranglisten basierend auf Land, Liga und Saison abzurufen und anzuzeigen. Wir können dafür neue Attribute erstellen, wie hier:
// 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 aus LeagueSettings.js setzen. Immer wenn ein ComboboxControl in unserer Einstellungs-UI aktualisiert wird, müssen wir die Attribute mithilfe der Methode setAttributes() setzen. Dies war unkomplizierter, als wir nur mit einem Datenendpunkt arbeiteten. Aber jetzt, da wir mehrere Eingaben haben, ist es etwas aufwendiger.
So werde ich es organisieren. Ich werde ein neues Objekt in LeagueSettings.js erstellen, das der Struktur der Einstellungsattribute und ihrer Werte folgt.
// LeagueSettings.js
let localSettings = {
country: attributes.settings.country,
league: attributes.settings.league,
season: attributes.settings.season,
};
Ich werde auch die anfänglichen Zustandsvariablen von null auf die jeweiligen Einstellvariablen ändern.
// 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()-Methoden werde ich ein setLocalAttributes() erstellen, das ein Argument hat, das das vorherige localSettings-Objekt klont und überschreibt, 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 setLocalAttributes() wie folgt definieren:
// LeagueSettings.js
function setLocalAttributes(value) {
let newSettings = Object.assign(localSettings, value);
localSettings = { ...newSettings };
setAttributes({ settings: localSettings });
}
Wir verwenden also Object.assign(), um die beiden Objekte zusammenzuführen. Dann können wir das newSettings-Objekt zurück in localSettings klonen, da wir auch jedes Einstellungsattribut berücksichtigen müssen, wenn eine neue Auswahl getroffen wird und eine Änderung auftritt.
Schließlich können wir setAttributes() wie gewohnt verwenden, um das endgültige Objekt zu setzen. Sie können bestätigen, ob die oben genannten Attribute geändert werden, indem Sie die Auswahlen in der UI aktualisieren.
Eine weitere Möglichkeit zur Bestätigung ist, einen console.log() in den DevTools durchzuführen, um die Attribute zu finden.

Schauen Sie sich diesen Screenshot genauer an. Die Werte sind in attributes.settings gespeichert. Wir können sehen, wie es live passiert, weil React jedes Mal neu gerendert, wenn wir eine Änderung an den Einstellungen vornehmen, dank des useState() Hooks.
Anzeigen der Werte in der Einstellungs-UI der Blöcke
Es ist nicht sehr nützlich, die Einstellungswerte in den Steuerelementen selbst zu speichern, da jeder von den anderen Einstellungswerten abhängt (z. B. Ranglisten nach Liga hängen davon ab, welche Saison ausgewählt ist). Aber es ist sehr nützlich in Situationen, in denen die Einstellungswerte statisch sind und die Einstellungen unabhängig voneinander sind.
Ohne die aktuellen Einstellungen kompliziert zu machen, können wir einen weiteren Abschnitt im Einstellungsfenster erstellen, der die aktuellen Attribute anzeigt. Sie können Ihre Methode zur Anzeige der Einstellungswerte wählen, aber ich werde eine Tip Komponente aus dem Paket @wordpress/components importieren.
// LeagueSettings.js
import { Tip } from "@wordpress/components";
Während ich hier bin, werde ich eine bedingte Prüfung für die Werte durchführen, bevor ich sie in der Tip Komponente anzeige.
<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>
So funktioniert das im Block-Editor:
API-Daten sind leistungsstärker, wenn Live-Daten angezeigt werden können, ohne sie jedes Mal manuell aktualisieren zu müssen. Das werden wir im nächsten Teil dieser Reihe behandeln.