Selles Gutenbergi kohandatud plokkide õpetuste seeria viimases osas õpime, kuidas kasutada kõrgema järgu komponente, et kasutada WordPressi komponente postituste ja muu WordPressi põhiteabe päringute tegemiseks.
Eelmises osas õppisime tundma dünaamilisi plokke ja lõpuks juurutasime funktsioonid postituse ID sisestamiseks ja PHP abil postituse dünaamiliseks toomiseks ning selle esiotsa ja eelvaate režiimis renderdamiseks. Postituse ID käsitsi sisestamine ei ole intuitiivne ega kasutajasõbralik. Palju parem on pakkuda kasutajale mingi viis postituste valimiseks või otsimiseks postituse pealkirja järgi ja millegi valimiseks klõpsates.
Üks osa selle lahendamisest on üsna lihtne; kuidas oma ploki editfunktsioonist postitusi päringuid teha. Meil on selleks paar võimalust ja parim variant on kasutada mõnda WordPressi nn kõrgemat järku komponenti. Võite kasutada ka Javascripti brauseri meetodeid, et teha AJAX-i kõne WordPress REST API-le, kasutades näiteks [fetch](https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API)või axiosid. WordPress pakub tegelikult oma versiooni fetch: apiFetch().
Selle lahendamise teine osa on teie enda otsustada; kuidas esitada loendit või valikut meie plokis. Kuidas kavatsete postituste loendit esitada? Kas valitud, märkeruutude või raadionuppude loendis? Või soovid pakkuda otsinguvõimalust ja seeläbi automaatse täitmise lahendust või filtrilahendust rakendada? Kas lubada valida mitu postitust või ainult üks? Tavaliselt saate selle lahendada erinevate WordPressi komponentide abil, kuid peate otsustama, millist lahendust soovite rakendada.
Õppime esmalt natuke kõrgema järgu komponentide ja WordPressi andmemooduli kohta, enne kui vaatame, kuidas saaksime oma plokis postituspäringuid teha.
WordPress Core Data moodul ja kõrgema järgu komponendid
Reactiga töötades peate sageli oleku üle kandma alamkomponentidele või üles ühisele vanemlikule komponendile, et kõigil teistel alamkomponentidel oleks neile juurdepääs. Lahendus rakenduse oleku tsentraliseerimise probleemi lahendamiseks on Reduxi kasutamine. Reduxi abil saate luua kauplusi – need on objektid, mis hoiavad rakenduse olekut ja teavet.
WordPressi andmemoodul on erinevate poodide keskus ja pakub funktsioone andmete haldamiseks erinevate moodulite vahel. See on üles ehitatud Reduxile, kuid ärge pidage seda Reduxiks WordPressi jaoks ekslikult, kuna erinevusi on üsna palju. Saate registreerida oma poed WordPressis või, mis veelgi olulisem, pääseda juurde WordPressi registreeritud poodidele.
Siin on ülevaade saadaolevatest poodidest WordPressi andmemoodulis (tõenäoliselt muutub aja jooksul). Kõik WordPressi poed sisalduvad põhiandmete moodulis. Näiteks on olemas poed, mis hoiavad toimetaja andmeid (core/editor), teateid (core/notices), plokkide andmeid (core/blocks), vaateava teavet (core/viewport) ja lõpuks, kuid mitte vähemtähtsana, põhipood ise – core.
Kaupluste andmetele juurdepääsuks peate kasutama valijaid. WordPressil on wp.datapaketi sees valija; [select](https://developer.wordpress.org/block-editor/packages/packages-data/#select)(). Kauplustega saate manipuleerida ka rakendusega dispatch, kuid see õpetusesari seda ei käsitle. Tegelikult saate valijat ise väga lihtsalt proovida, et näha, mis WordPressi poodides saadaval on.
Proovin valijat
Avage Chrome’is Gutenbergi redaktor ja konsooli siluritööriist. Trüki sisse:
wp.data.select('core')Ja vajutage sisestusklahvi. Peaksite saama vastusena objekti kõigi selektorite (funktsioonidega), mida saate kasutada. Näidetena leiate selliseid funktsioone nagu getMedia, getTaxonomy, getAuthorsja nii edasi. See, mida me kasutame postituste päringute tegemiseks, on samuti olemas, kuid sellel pole intuitiivset nime; seda nimetatakse getEntityRecords. Praegu on mõned neist funktsioonidest dokumenteeritud, kuid enamik kahjuks mitte.
Proovige ka teisi poode peale corenäiteks:
wp.data.select('core/editor').getBlocks()See tagastab kogu teabe kõigi praegu teie postituses olevate plokkide kohta. Saate sellega mängida Chrome’i konsooli siluris ja proovida mõnele funktsioonile helistada, et näha, mida vastuseks saate. Mõned nõuavad parameetreid ja teised mitte.
Selektorite kasutamiseks ja kauplustele juurdepääsuks peame neid kasutama kõrgema järgu komponentides. Kõrgemat järku komponendid on lihtsalt Reactis millegi tegemise muster. Edastame komponendi funktsioonile (või komponendile), mis võib lisada mõned rekvisiidid, ja tagastame seejärel uue komponendi.
WordPressi andmemooduli seest leiame [withSelect](https://developer.wordpress.org/block-editor/packages/packages-data/#withSelect); kõrgema järgu komponent, mida saab kasutada rekvisiitide süstimiseks registreeritud selektorite abil. Teisisõnu; sees withSelecton meil juurdepääs valijale select()ja saame seda kasutada kõne(de) tegemiseks. Valija tulemused on selle komponendi rekvisiidid, millele edastame withSelect. Kui teil on vaja kombineerida mitut kõrgemat järku komponenti, pakub WordPressi andmemoodul seda composefunktsiooni, kuid see ei kuulu selle õpetuse ulatusse. Kasutame ainult ühte kõrgemat järku komponenti; withSelect.
See on olnud palju teooriat, nii et alustame mõne koodi ja praktiliste näidete vaatamist.
Postituste toomine funktsiooniga withSelect, valige ja hanki EntityRecords
Ülaltoodu kokkuvõtteks peame withSelectoma ploki jaoks seadistama kõrgema järgu komponendi. Selle sees saame kasutada valijaid, et pääseda juurde WordPressi poodidele, mis on rekvisiidid komponendile, millele edastame withSelect. Postituste päringute tegemiseks kasutame corepoodi ja valijat .getEntityRecords
Funktsioon getEntityRecordson hetkel kahjuks vähe dokumenteeritud. Kuid olen õppinud, et saame edastada postTypeesimese parameetrina (olemi tüüp) ja seejärel teise parameetrina postituse tüübi (nt " post" või). Kolmas parameeter on valikuline ja võib olla päringuargumentidega objekt. Kolmandat parameetrit vaatame hiljem.
Kui järgiksite seda õpetuse seeriat eelmisest osast, oleks teil kohandatud plokk, mis aktsepteerib tekstisisestuses käsitsi sisestatud postituse ID-d. Plokk kasutab PHP-d, et dünaamiliselt renderdada postitust kasutajaliideses (ja eelvaaterežiimis). Eemaldame postituse ID käsitsi sisestamise nõude ja asendame selle millegi intuitiivsemaga. Nagu eelnevalt mainitud, peate ise otsustama, kuidas postituste loendit esitada ja milline on parim viis, kuidas lasta kasutajal postitust valida. Lihtsuse huvides lisame valiku kõigi postituste pealkirjade hulgast.
KodeeriminewithSelect
Alustame selle sisse kodeerimist. Kõigepealt peame andmepaketist vajaliku struktureerima;
const { withSelect, select } = wp.data;Seejärel kasutame withSelectoma ploki editfunktsioonis ja edastame oma redigeerimiskomponendi; FirstBlockEdit. Sees withSelectme destruktureerime selectparameetrina ja kasutame valijat select()postituste päringu tegemiseks getEntityRecords. Tagastame ühe omadusega objekti, mille kutsume postsja mis sisaldab select()kõne tulemust.
Meie komponendi kohal oleva koodiga FirstBlockEditon nüüd uus rekvisiit; posts. Kõik, mida me kõrgema järgu komponendi sees tagastame withSelect, on juurdepääsetav läbitava komponendi rekvisiitidena (päris lõpus suluses).
Postituste käsitlemine valijast
Nüüd saame minna oma komponendi juurde FirstBlockEditja heita pilk uuele props.posts. Kuna meie komponent on klassipõhine komponent, peame viitama rekvisiitidele this. Logime selle konsoolis render()funktsiooni sees välja FirstBlockEdit:
render() {
const { attributes, setAttributes } = this.props;
console.log(this.props.posts);
...
}Hoidke oma konsooli siluril silm peal. Võite märgata, et see logib kaks korda; esmalt nullja siis millalgi hiljem logib see hulga postitusi. Selle põhjuseks on asjaolu, et postituste päringuid tehakse asünkrooniliselt. Meie komponent renderdatakse esmalt enne vastust, mis ajal props.postson null. Kui saame vastuse, renderdatakse meie komponent uuesti koos rekvisiidiga. Peaksite alati meeles pidama, et selle väikese ajavahemiku jaoks peaksite oma koodis andmeid kasutamata.
Valiku lisamine postituste kuvamiseks
Valmistame ette valitud täitma tagastatud postitustega ja selleks kasutame WordPressi komponenti SelectControl. Komponent SelectControlaktsepteerib valikute massiivi, kus iga valik on objekt omadustega valueja label.
Kui vaatate konsooli logitud (teist) vastust, näete, et saame hulga postitusobjekte. Iga postitus sisaldab enamikku postituse teabest, kuid valitud valikute puhul huvitab meid ainult postituse ID väärtusena ja postituse pealkiri siltina. Nii et me vaatame läbi postsrekvisiidi ja sisestame massiivimuutuja, mille edastame SelectControl. Ärge unustage käsitleda väikest ajavahemikku, kus postsrekvisiit on null. Sel juhul täidame valikumassiivi ühe valikuga, millel on silt „Laadimine…".
Pange tähele, et peame viitama postituse pealkirjale kui post.title.rendered. Saate end logitud konsoolist otsida postsja vaadata, kuidas iga postituse teave on üles ehitatud.
Pärast seda peame lihtsalt lisama sinna, SelectControlkuhu tahame. See võib olla ploki enda sees (eelistatult redigeerimisrežiimi koodis) või Inspectori sees.
Seadsime SelectControlatribuudi viitama atribuudile, selectedPostIdmille määratlesime eelmises etapis. Seadistame rekvisiidis salvestatud väärtuse ja tegeleme selle valuevärskendamisega onChangerekvisiidis – täpselt nagu oleme seda mitu korda varem teinud. Tagame numbri salvestamise kasutades, parseInt()kuna sellel selectedPostIdon tüüp number. Ja me edastame loodud valikute massiivi rekvisiidis options.
See on tõesti kõik! Kui järgisite eelmise sammu koodi, peaks teil juba olema kood, mis loeb salvestatud postituse ID ja kuvab selle!
Muidugi soovitan teil postituste loendit ja valikut rakendada teisiti kui lihtsalt valik. See ei ole ilus ega kasutajasõbralik lahendus, eriti paljude postitustega saitide puhul. Postituste arvust rääkides, kas märkasite, et valija getEntityRecords tagastab ainult maksimaalselt 10 viimast postitust? See on getEntityRecordsi vaikekäitumine, kuid me saame postituspäringut muuta, edastades kolmanda parameetri.
Muutke getEntityRecordsi päringut
Edastades objekti getEntityRecordsile kolmanda parameetrina, saame postituspäringut muuta. Nagu eelnevalt mainitud, getEntityRecordspuuduvad kahjuks selle dokumendid. Kuid kogu veebi lugedes olen kogunud loendi võimalikest päringuargumentidest;
per_page: määrake arv, et piirata postituste arvu. Seadistage väärtusele,-1et tuua maksimaalselt 100. Vaikimisi10.exclude: teatud postituste välistamine päringust. Määrake postituse ID või numbrite massiiv mitme postituse ID jaoks.parent_exclude: teatud vanemate postituste välistamine. Määrake postituse ID või mitme postituse ID massiiv.orderby: otsustage postituste järjekord. Tõenäoliselt saate kasutada samu parameetreid, mis WP_Query järjekorras. Võib olla nt "menu_order".order: kas'asc'või ‘desc'kasvavas või kahanevas järjestuses.status: filtreerige postituse oleku järgi. Võib olla string, mitme komaga eraldatud olekuga string või olekustringide massiiv. Nt['publish', 'draft']päringute tegemiseks nii avaldatud kui ka koostatud postituste kohta.categories: postituste filtreerimine teatud kategooriate järgi. Esitage kategooria ID või kategooria ID-de massiiv. Usun, et see töötab ainult postituste kategooriate ja mitte muude kohandatud taksonoomiate puhul.tags: filtreerige postitusi teatud siltide järgi. Esitage sildi ID või märgendi ID-de massiiv. Töötab ainult postitusmärgendite ja mitte muude kohandatud taksonoomiate puhul.search: lisage otsingupäring (string).
Märkus: see loetelu ei ole ammendav ja võib samuti muutuda!
Muudame oma päringut. Me tahame teha kahte asja; kõigepealt tahame tuua kõik postitused, mitte ainult 10 viimast. Selleks pakume -1. per_pageTeiseks tahame praeguse postituse postituste loendist välja jätta, andes praeguse postituse ID aadressile exclude. Sageli pole mõtet näidata postituse otseteed või praeguse postituse eelvaadet.
Võite mõelda; oodake, kuidas me saame praeguse postituse ID? Ärge unustage, et kõrgema järgu komponendis withSelectja selectselektoriga pääseme juurde kõikidele WordPressi põhiandmesalvedele. Praeguse postituse ID on loomulik salvestada mõnda WordPressi põhipoodi. Seest core/editorleiame funktsiooni getCurrentPostId().
Muutkem withSelectnaasmist millekski selliseks:
Ülaltoodud muudatus on üsna iseenesestmõistetav. Loome päringuobjekti atribuutidega per_pageja excludeedastame selle kolmanda parameetrina getEntityRecords(). Nüüd peaks meie props.postssisekomponent FirstBlockEditloetlema kõik postitused, kuid välistama praeguse postituse.
Järeldus
See postitus lõpetab kohandatud Gutenbergi plokkide õpetuseseeria. Seeria eesmärk oli läbida oma kohandatud plokkide väljatöötamise põhitõed, pakkudes teile lähtepunkti oma ja keerukamate plokkide väljatöötamiseks. Kindlasti hoidke silm peal, et saada rohkem Gutenbergiga seotud õpetusi siit. Võib-olla leiate õpetuse, mis selgitab täpsemalt midagi, mida tahtsite ise teha!