Um Daten in einem individuellen API-Endpunkt zu speichern, musste ich den Code jedes Mal ausführen, wenn der Block-Editor gespeichert wurde. Das war leichter gesagt als getan. Die erste Lösung, die man findet, ist die Verwendung von subscribe, um jede Änderung zu abonnieren und sie nach der benötigten Änderung zu filtern.

Dies bringt jedoch einige Nachteile mit sich, da man die Änderungen filtern muss, und da ein subscribe sehr oft ausgeführt wird, ist es ziemlich leistungsintensiv. Außerdem konnte ich keine Möglichkeit finden, das Abonnement so zu filtern, dass es nur einmal ausgeführt wird, ohne Flags und Debounces zu verwenden.

Glücklicherweise fand ich eine weithin ungesehene Antwort auf der WordPress Development Stack Exchange, die die savePost-Action der Post Editor’s Data verwendet.

Um sie zu verwenden, müssen wir unsere individuelle Action an diese Action anhängen und sie ausführen, sobald selbige erfolgreich ausgeführt wird. Über einen dispatch hängen wir uns an die savePost-Action und verknüpfen sie mit dieser, so dass sie nichts tut, solange der Beitrag nicht wirklich gespeichert wurde (ähnlich wie bei Meta-Boxen). Dann können wir unseren individuellen Code ausführen, in meinem Fall erhalte ich bestimmte Daten und verwende apiFetch, um sie an einen individuellen API-Endpunkt zu senden.

const [ isDispatched, setIsDispatched ] = useState( false );
const { savePost } = dispatch( 'core/editor' );

if ( ! isDispatched ) {
	setIsDispatched( true );
	dispatch( 'core/editor' ).savePost = () => {
		return savePost().then( () => {
			let data = { values: [] };
			const postId = select( 'core/editor' ).getCurrentPostId();
			
			// get data
			
			if ( ! data.values.length ) {
				return;
			}
			
			apiFetch( {
				data,
				method: 'PUT',
				path: '/custom/v1/api/endpoint/' + postId,
			} ).then( () => {
				// TODO: show success message
			} ).catch( ( error ) => {
				// TODO: show error message
			} );
		} );
	}
}
Code-Sprache: JavaScript (javascript)

Damit der Dispatch nur einmal durchgeführt wird, verwenden wir noch eine lokale Variable isDispatched, die dem State zugeordnet wird und daher persistent ist. Diese wird beim ersten Dispatch auf true gesetzt, sodass danach kein weiterer Dispatch erfolgt. Andernfalls würde beim zweiten Speichern eines Beitrags ohne vorheriges Neuladen die Aktion zweimal durchgeführt werden, beim nächsten Mal dreimal und so weiter.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert