...
✅ WEB- och WordPress -nyheter, teman, plugins. Här delar vi tips och bästa webbplatslösningar.

Skapa anpassat Gutenberg-block – Del 10: Hämta inlägg och komponenter av högre ordning

10

I den här sista delen av Gutenbergs handledningsserie för anpassade block kommer vi att lära oss hur man använder komponenter av högre ordning för att använda WordPress-komponenter för att utföra frågor om inlägg och annan grundläggande WordPress-information.

I den föregående delen lärde vi oss om dynamiska block och det slutade med att vi implementerade funktionalitet för att skriva in ett inläggs-ID och använda PHP för att dynamiskt hämta inlägget och rendera det i frontend- och förhandsgranskningsläge. Att manuellt skriva in ett inläggs-ID är inte intuitivt eller användarvänligt. Det är mycket bättre att ge användaren ett sätt att välja eller söka efter inlägg efter inläggstitel och klicka på något för att välja ett.

En del av att lösa detta är ganska lätt; hur du frågar efter inlägg från ditt blocks editfunktion. Vi har några alternativ för detta, och det bästa alternativet är att använda några av de så kallade högre ordningens komponenterna från WordPress. Du kan också använda Javascript-webbläsarmetoder för att utföra ett AJAX-anrop mot WordPress REST API med till exempel [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)eller axios. WordPress tillhandahåller faktiskt sin egen version av fetch: apiFetch().

Den andra delen av att lösa detta är lite upp till dig; vilket är hur man presenterar listan eller valet i vårt block. Hur ska du presentera listan med inlägg att välja mellan? I ett urval, lista med kryssrutor eller alternativknappar? Eller vill du erbjuda möjligheten att söka, och därmed implementera en autokompletteringslösning eller en filterlösning? Ska du tillåta att välja flera inlägg eller bara ett? Vanligtvis kan du lösa detta genom att använda olika WordPress-komponenter, men du måste bestämma dig för vilken lösning du vill implementera.

Låt oss först lära oss lite om komponenter av högre ordning och WordPress-datamodulen, innan vi tittar på hur vi kan utföra postförfrågningar i vårt block.

WordPress Core Data-modul och komponenter av högre ordning

När du arbetar med React behöver du ofta överföra status till underordnade komponenter eller uppåt till en gemensam föräldrakomponent så att alla andra underordnade komponenter har tillgång till dem. En lösning för att lösa problemet med att centralisera ett programs tillstånd är att använda Redux. Med Redux kan du bygga butiker – som är objekt som håller en applikations status och information.

WordPress Datamodulen är ett nav av olika butiker och ger funktioner för att hantera data mellan olika moduler. Det är byggt ovanpå Redux – men misstag det inte som en Redux för WordPress, eftersom det finns en hel del skillnader. Du kan registrera dina egna butiker inom WordPress, eller kanske ännu viktigare, komma åt WordPress registrerade butiker.

Här är en översikt över de tillgängliga butikerna i WordPress-datamodulen (kommer förmodligen att förändras med tiden). Alla WordPress-butiker finns i modulen Core Data. Det finns till exempel butiker som innehåller redaktörens data (core/editor), notiser (core/notices), blockdata (core/blocks), visningsportinformation (core/viewport), och sist men inte minst själva huvudarkivet – core.

För att komma åt data från butiker måste du använda väljare. WordPress har en väljare i wp.datapaketet; [select](https://developer.wordpress.org/block-editor/packages/packages-data/#select)(). Du kan också manipulera butikerna med dispatch, men detta täcks inte av denna handledningsserie. Du kan faktiskt väldigt enkelt prova väljaren själv för att se vad som finns i WordPresss butiker.

Testar väljaren

Öppna Gutenberg-redigeraren i Chrome och öppna konsolens felsökningsverktyg. Skriv in:

wp.data.select('core')

Och tryck på Enter. Du bör få ett objekt som svar med alla väljare (funktioner) du kan använda. Som exempel hittar du funktioner som getMedia, getTaxonomy, getAuthors, och så vidare. Den vi kommer att använda för att fråga inlägg finns också där men har inte ett intuitivt namn; det heter getEntityRecords. För närvarande är några av dessa funktioner dokumenterade, men de flesta är det tyvärr inte.

Prova även andra butiker än coretill exempel:

wp.data.select('core/editor').getBlocks()

Detta returnerar all information om alla block för närvarande i ditt inlägg. Du kan leka med detta i Chrome-konsolfelsökningen och försöka anropa några funktioner för att se vad du får som svar. Vissa kräver parametrar och andra inte.

För att kunna använda väljare och komma åt butiker måste vi använda dem inom komponenter av högre ordning. Komponenter av högre ordning är helt enkelt ett mönster av att göra något i React. Vi skickar en komponent till en funktion (eller komponent) som kan lägga till några rekvisita, och returnerar sedan en ny komponent.

Inuti WordPress Datamodul hittar vi [withSelect](https://developer.wordpress.org/block-editor/packages/packages-data/#withSelect); en högre ordningskomponent som kan användas för att injicera rekvisita med hjälp av registrerade väljare. Med andra ord; inom withSelectvi har tillgång till väljaren select()och kan använda den för att utföra samtal. Väljarresultaten kommer att vara rekvisita till komponenten vi skickar till withSelect. Om du behöver kombinera flera komponenter av högre ordning erbjuder WordPress Data-modulen composefunktionen, men detta ligger utanför omfattningen av denna handledning. Vi kommer bara att använda en komponent av högre ordning; withSelect.

Detta har varit mycket teori, så låt oss börja titta på lite kod och praktiska exempel.

Hämta inlägg med hjälp av withSelect, välj och få EntityRecords

För att sammanfatta ovanstående måste vi ställa in den högre ordningens komponent withSelectför vårt block. Inuti detta kan vi använda väljare för att komma åt WordPresss butiker, som kommer att vara rekvisita till komponenten vi skickar till withSelect. Vi kommer att använda corebutiken och väljaren getEntityRecordsför att fråga inlägg.

Funktionen getEntityRecordsär tyvärr inte särskilt dokumenterad för tillfället. Men jag har lärt mig att vi kan skicka postTypesom första parameter (entitetstyp) och sedan posttypen som andra parameter (t.ex. ‘ post‘ eller ‘ page‘). Den tredje parametern är valfri och kan vara ett objekt med frågeargument. Vi kommer att titta på den tredje parametern senare.

Om du följde denna handledningsserie från föregående del skulle du ha ett anpassat block som accepterar ett manuellt inskrivet inläggs-ID i en textinmatning. Blocket använder PHP för att dynamiskt rendera inlägget i frontend (och i förhandsgranskningsläge). Låt oss ta bort kravet på att manuellt skriva in post-ID och ersätta det med något mer intuitivt. Som nämnts tidigare måste du själv bestämma hur du ska presentera listan med inlägg och det bästa sättet att låta användaren välja ett inlägg. För att göra det enkelt lägger vi till ett urval av alla inläggstitlar att välja mellan.

Kodning avwithSelect

Låt oss börja koda in detta. Först måste vi destrukturera det vi behöver från datapaketet;

const { withSelect, select } = wp.data;

Sedan använder vi withSelecti vårt blocks editfunktion och för vidare vår redigeringskomponent; FirstBlockEdit. Inuti withSelectdestrukturerar vi selectsom parameter och använder väljaren select()för att fråga inlägg med getEntityRecords. Vi returnerar ett objekt med en egenskap som vi anropar postssom innehåller resultatet av select()anropet.

Med koden ovanför FirstBlockEditkommer vår komponent nu att ha en ny rekvisita; posts. Vad vi än returnerar inuti den withSelecthögre ordningens komponent kommer att vara tillgänglig som rekvisita till den komponent vi skickar (i parentesen i slutet).

Hantera inläggen från väljaren

Vi kan nu gå in på vår komponent FirstBlockEditoch ta en titt på den nya props.posts. Eftersom vår komponent är en klassbaserad komponent måste vi referera till rekvisita med this. Låt oss konsollogga ut det i render()funktionen i FirstBlockEdit:

render() { const { attributes, setAttributes } = this.props; console.log(this.props.posts); ... }

Håll ett öga på din konsolfelsökare. Du kanske märker att detta loggar två gånger; först nulloch sedan någon gång senare loggar den en mängd inlägg. Detta beror på att fråga efter inlägg sker asynkront. Vår komponent renderas först före svaret, då props.postsär null. När vi får ett svar, renderas vår komponent igen med rekvisitan ifylld. Du bör alltid komma ihåg att ta emot denna lilla tidsperiod utan data i din kod.

Lägger till ett urval för att visa inläggen

Låt oss förbereda oss för att fylla i ett urval med inläggen som returneras och för det kommer vi att använda WordPress-komponenten SelectControl. Komponenten SelectControlaccepterar en rad val där varje val är ett objekt med egenskaperna valueoch label.

Om du tittar på konsolens loggade (andra) svar kan du se att vi får en rad postobjekt. Varje inlägg innehåller det mesta av inläggets information, men för valen i ett urval är vi bara intresserade av inläggs-ID som värde och inläggstitel som etikett. Så vi går igenom postspropen och fyller i en arrayvariabel som vi skickar vidare till SelectControl. Glöm inte att hantera den lilla tidsramen där postsrekvisitan är null. I så fall kommer vi att fylla i valmatrisen med ett alternativ som har etiketten "Loading…".

Observera att vi måste hänvisa inläggets titel som post.title.rendered. Du kan leta själv i den loggade konsolen postsoch se hur informationen är uppbyggd för varje inlägg.

Efter detta behöver vi helt enkelt lägga till en SelectControlvar vi vill ha den. Det kan vara inuti själva blocket (helst inom koden för redigeringsläge), eller inuti Inspector.

Vi ställer in SelectControlatt referera till attributet selectedPostIdsom vi definierade i föregående steg. Vi ställer in det sparade värdet i rekvisitan valueoch hanterar att uppdatera det i onChangeprop – precis som vi har gjort flera gånger tidigare. Vi säkerställer att ett nummer lagras genom att använda parseInt()eftersom det selectedPostIdhar typen number. Och vi passerar den genererade uppsättningen av val i rekvisitan options.

Det var verkligen allt! Om du följde koden från föregående steg borde du redan ha kod som läser det sparade inläggets ID och visar det!

Självklart rekommenderar jag att du implementerar listan och valet av inlägg annorlunda än bara ett enkelt urval. Detta är inte en snygg eller användarvänlig lösning, särskilt för webbplatser med många inlägg. På tal om antalet inlägg, märkte du att väljaren getEntityRecords endast returnerar maximalt de 10 senaste inläggen? Det är standardbeteendet för getEntityRecords, men vi kan ändra post-frågan genom att skicka en tredje parameter.

Ändra frågan för getEntityRecords

Genom att skicka ett objekt som den tredje parametern till getEntityRecords kan vi ändra postfrågan. getEntityRecordsSom tidigare nämnts saknas tyvärr dokumentationen för. Men genom att läsa över hela webben har jag samlat en lista över möjliga frågeargument;

  • per_page: Ställ in ett antal för att begränsa antalet inlägg. Ställ in på för -1att hämta maximalt 100. Standard 10.
  • exclude: Uteslut vissa inlägg från frågan. Ställ in ett inläggs-ID eller en array av nummer för flera inläggs-ID:n.
  • parent_exclude: Uteslut vissa föräldrainlägg. Ställ in ett inläggs-ID eller en uppsättning av flera inläggs-ID:n.
  • orderby: Bestäm ordningen på inläggen. Troligtvis kan du använda samma parametrar som i WP_Querys orderby. Kan vara t.ex. ‘ menu_order‘.
  • order: Antingen 'asc'eller ‘ desc'för stigande eller fallande ordning.
  • status: Filtrera efter poststatus. Kan vara en sträng, en sträng med flera statusar separerade med kommatecken eller en matris med statussträngar. Till exempel ['publish', 'draft']för att fråga både publicerade och utkastade inlägg.
  • categories: Filtrera inlägg efter vissa kategorier. Ange ett kategori-ID eller en uppsättning kategori-ID:n. Jag tror att detta bara fungerar för postkategorier och inte andra anpassade taxonomier.
  • tags: Filtrera inlägg efter vissa taggar. Ange ett tagg-ID eller en uppsättning tagg-ID:n. Fungerar endast för posttaggar och inte andra anpassade taxonomier.
  • search: Lägg till en sökfråga (sträng).

Obs: Detta är inte en uttömmande lista och kan även komma att ändras!

Låt oss ändra vår fråga. Vi vill göra två saker; först vill vi hämta alla inlägg och inte bara de 10 senaste. För att göra detta tillhandahåller vi -1till per_page. För det andra vill vi utesluta det aktuella inlägget från inläggslistan genom att tillhandahålla det aktuella inläggets ID till exclude. Det är ofta ingen mening att visa en inläggsgenväg eller förhandsgranskning av själva det aktuella inlägget.

Du kanske tror; vänta, hur får vi det aktuella post-ID? Glöm inte att vi inom den högre ordningens komponent withSelectoch med selectväljaren kan komma åt alla WordPresss kärndatalager. Det aktuella inläggs-ID:t är en naturlig sak att lagra i en av WordPress kärnbutiker. Inuti core/editorhittar vi funktionen getCurrentPostId().

Låt oss ändra withSelectåtergången till något så här:

Ovanstående förändring är ganska självförklarande. Vi genererar ett frågeobjekt med egenskaperna per_pageoch excludeoch skickar detta som tredje parameter till getEntityRecords(). Nu ska vår props.postsinsida i FirstBlockEditkomponenten lista ut alla inlägg men utesluta det aktuella inlägget.

Slutsats

Det här inlägget avslutar guideserien Hur man skapar anpassade Gutenberg-block. Serien var tänkt att gå igenom grunderna för att utveckla dina egna anpassade block, vilket ger dig en utgångspunkt för att utveckla dina egna och mer komplexa block. Håll definitivt utkik efter fler Gutenberg-relaterade handledningar här. Kanske hittar du en handledning som mer specifikt förklarar något du ville göra själv!

Inspelningskälla: awhitepixel.com

Denna webbplats använder cookies för att förbättra din upplevelse. Vi antar att du är ok med detta, men du kan välja bort det om du vill. Jag accepterar Fler detaljer