See postitus on kiire sissejuhatus sellesse, kuidas hoida oma Gutenbergi kood Reacti konksude abil vastavuses praeguste standarditega. Vaatame, kuidas see kasulik on, miks me peaksime seda tegema ja kuidas.
Ah, konksud?
Eeldan, et teil on juba kogemusi veidi keerukamate Gutenbergi plokkide või pistikprogrammidega, mis otsivad postitusi või toovad ja värskendavad postituste metat. Ja seega töötanud [withSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withSelect)ja/või [withDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#withDispatch). Need on WordPressi kõrgema järgu komponendid, mis võimaldavad teil pääseda juurde WordPressi poodidele, et tuua või edastada teavet, mis jääb pisut väljapoole "tavalist" plokki või postituse redigeerimist. Võimalik, et olete olnud sunnitud kasutama composeka selleks, et ühendada mitme kõrgema järgu komponendiga komponent. Kui teie kood kasutab neid mustreid, ärge muretsege – need töötavad suurepäraselt ja töötavad ka edaspidi! Kuid tehnoloogia arenedes saame paremini hakkama.
2019 aasta alguses tõi React välja konksud (versioon 16.8), mis võimaldavad teil olekut kasutada ilma klassi kasutamata ja täiustada muid funktsioone, mis annavad loetavama ja korduvkasutatava koodi. Näiteks registritele juurdepääsu saamiseks ei ole vaja koodi mähkida kõrgema järgu komponentidesse. Ja suvel 2019 järgnes WordPress, mis käivitas kohandatud konksud: [useDispatch](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useDispatch)ja [useSelect](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-data/#useSelect).
Konksude eelised on palju. Kõige tavalisem näide on komponendi oleku kasutamise lubamine ilma Javascripti klassi (useState) kirjutamata. Kuid minu arvates on suurim kasu korduvkasutatavus. Eemaldades vajaduse kasutada mustreid, nagu renderdusrekvisiidid ja kõrgema järgu komponendid, saab komponendid kirjutada palju iseseisvamateks tükkideks. Veel üks konksude eelis on see, et see muudab teie koodi hõlpsamini loetavaks ja arusaadavaks!
Hüppame kohe mõne näite juurde ja vaatame, kuidas meie koodi rakendada useSelectja konksud seda teha!useDispatch
RakendamineuseSelect
Alustame withSelectja sellele vastavast konksust useSelect. Neid kasutatakse registreeritud valijatelt riigist tuletatud rekvisiitide hankimiseks. Levinud näited on juurdepääs valijatele " core" või " core/editor", et teha postitusi päringuid (getEntityRecords), pääseda juurde postituse metale (getEditedPostAttribute) või lihtsalt saada praeguse postituse tüüp või muu teave.
Esitluse eesmärgil alustan lihtsa näitega. Oletame, et mul on plokikomponent, kus mul on kuskil postituste valija. Postitusvalikute sisestamiseks pean juurdepääsu registrile " core" ja GetEntityRecords()helistama.
Vana moodi kasutaminewithSelect
Kui tahan teha päringuid ploki postituste kohta, pean oma komponendi mähkima withSelect. Seda tehakse exportavalduses tavaliselt.
Pange tähele, et see koodinäide ei ole täielik tegeliku funktsionaalploki või JS-i pistikprogrammina, see on eemaldatud, et kuvada ainult põhikontseptsioone withSelect. Kui otsite praktilisi koodinäiteid, on mul ka teisi artikleid, mis seda käsitlevad: nt kuidas rakendada plokke postituse valikuga või kuidas lisada inspektorile postituse meta. Need on kirjutatud märkidega withSelectja withDispatch, tehke ka need ning tulge siis siia tagasi, et õppida, kuidas neid konksudeks muuta.
Nagu reast näete, #12-16mähkin oma komponendi withSelect. Funktsiooni withSelect kaudu pääsen juurde soovitud poodi ja tagastan rekvisiidis " somePosts" postituspäringu. See rekvisiit on siis saadaval minu AWP_Example_Pluginkomponendi sees (nagu näete somePosts, et ma hävitan rea rekvisiite #3).
Nagu varem mainitud, töötab see meetod suurepäraselt – ja töötab ka edaspidi. Kuid sellel on mitmeid miinuseid. Üks on see, et seda pole väga lihtne mõista. Muidugi, see oli väga lihtne näide. Esmapilgul komponendile endale pole kindel, kust tugi somePostspärineb või mis see on. Peaksite teadma, et otsida ekspordiaruannet ja vaadata, kas seal on ümbriseid. See tundub ka veidi lahutamatuna. Teete üsna suure osa olulisest tööst väljaspool oma komponenti millegi nimel, mida soovite oma komponendi sees saada.
Teeme seda paremini konksude abil.
KonverteerimineuseSelect
Üheks teisendamine on withSelectnii useSelectlihtne kui võimalik. Esimene samm on see, et saame defineerida muutuja somePostsmeie komponendi sees, mitte väljastpoolt exportavalduse abil. Teine samm on kogu meie funktsiooni withSelectteisaldamine useSelect. Ja see ongi kõik.
Ülaltoodud kood annab täpselt sama tulemuse, mis koodiga withSelect. Erinevus seisneb selles, et kood on nüüd palju arusaadavam! Nüüd näeme väga lihtsalt, et muutuja somePostssalvestab postituspäringu tulemuse otse meie komponendi sisse.
Oluline märkus: useSelectaktsepteerib teist parameetrit; hulk sõltuvusi. Sõltuvused on muutujad, mis tagavad, et käivitame ainult useSelectsiis, kui üks sõltuvustest (muutuja väärtustest) on muutunud. See osa on olulisem useDispatchkui siin, nii et selgitan seda natuke useDispatchallpool olevas jaotises.
RakendamineuseDispatch
Nüüd vaatame withDispatchja sellele vastavat konksu useDispatch. Neid kasutatakse rekvisiitide saatmiseks registritesse. Näiteks käskides Gutenbergil värskendada postituse metat " core/editor" kaudu.
Jällegi, demonstreerimise eesmärgil ei ole minu koodinäited täielikud funktsionaalsed kooditükid – need illustreerivad ainult neid mustreid puudutavaid osi. Selles näites eeldan, et mul on tekstiväli, mis näitab postituse meta – ja soovin postituse meta väärtust muudatuse korral värskendada.
Vana moodi kasutaminewithDispatch
Kuna withDispatchtegemist on kõrgema järgu komponendiga, pean oma komponendi selle sisse pakkima. Seda tehakse exportavalduses tavaliselt. Selleks, et meie meta tekstiväli töötaks me
Näiteks:
Real #20-26mähime komponendi sisse withDispatch, milles tagastame funktsiooni " setPostMeta", mis saadab posti meta (selle värskendamiseks). Real #6destruktureerime rekvisiidi, et saaksime seda kasutada tekstivälja onChangesündmuses real #13. (Pange tähele, et ülaltoodud näide ei oleks funktsionaalne, kuna määrasime tekstivälja väärtuseks tühja stringi. See on lihtsalt selleks, et näidata, kuidas me kasutaksime lähetamist).
Jällegi näeme, et koodi mõistmine pole nii lihtne. Peaksite teadma, et otsida ümbrist, et aru saada, mis rekvisiit ” setPostMeta" on või millest see pärineb. Teeme seda paremini konksude abil!
KonverteerimineuseDispatch
Keeleks muutmine withDispatchei useDispatchole nii lihtne withSelectkui useSelect. See on siiski üsna lihtne. Tasub meeles pidada kahte asja. Üks on see, et useDispatchesimese parameetrina võetakse poe nimi. Seejärel pääseksime poodi juurde ja kutsuksime välja selle saadaolevad funktsioonid, kui seda kasutame (nt tekstivälja onChangesündmusel). Teiseks on teise parameetri sõltuvuste massiiv useDispatcholulisem kui parameetriga useSelect. Kui te ei halda sõltuvusi õigesti, võite riskida, et teie kood satub igavesse tsüklisse. Ainult sõltuvusmuutujate muutmisel käivitatakse skript uuesti useDispatch.
Näiteks:
Liinil #8hävitame selle, mida vajame poest " core/editor". Meid huvitab ainult editPostfunktsioon, mida saame kasutada postituse meta värskendamiseks. Teise parameetrina useDispatchpakume sõltuvusi. Postituse meta värskendamise näite puhul oleks postituse meta väärtuse kasutamine (kasutades useSelect) täiuslik sõltuvusena. Selles näites olen selle lihtsalt määranud näiliseks muutujaks. Vaadake põhjalikumat ja realistlikumat näidet allpool. Ja siis #16tekstivälja onChangesündmuse real helistame editPostmeta värskendamiseks. Pange tähele selle rea erinevust withDispatchülaltoodud kasutamisega! Kuna me kasutame editPostposti meta värskendamiseks (setPostMeta) funktsiooni tagastamise asemel otse, peame esitama objekti koosmetavõtmena ja seejärel objekti postituse metaga, mida soovime värskendada. Oleme withDispatchkoodi jaganud osadeks.
Siiski useDispatchmuudab kasutamine koodi palju loetavamaks ja arusaadavamaks. Väljapoole meie komponenti ei lisata enam koodi, mida peame sees kasutama.
Täielikum näide ja vajaduse kaotaminecompose
Kui kasutate withDispatch, on tõenäoline, et vajate withSelectka seda komponenti. Ülaltoodud näidetes useDispatchvärskendame postituse metaväärtust. Kuid selleks, et tekstiväli töötaks korralikult (ja näitaks ka praegust väärtust), peaksime tooma ka postituse metaväärtuse.
Kui teil on vaja kasutada mitut komponendi ümber mähitud kõrgemat järku komponenti, kasutaksite tõenäoliselt veel üht Gutenbergi funktsiooni; [compose](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-compose/). See on mugav funktsioon mitme kõrgema järgu komponendi kombineerimiseks üheks kõrgema järgu komponendiks, mille ümber saate oma komponendi ümber mähkida.
Vaatame täielikumat näidet komponendist, mis hangib tekstiväljal postituse metaväärtuse ja värskendab selle väärtuse muutmisel. Alustame sellest, kuidas me peaksime seda tegema, kasutades withSelectja withDispatch(ja seega ka compose).
Kasutades withSelect, withDispatchjacompose
Joones #21-34koostame withSelectja withDispatchmähime need ümber oma komponendi. postMetaalates withSelectja setPostMetaalates withDispatchon nüüd saadaval meie komponendis rekvisiidina. Destruktureerime need real #7ja kasutame neid #13ja #14.
Nagu näete, on väljaspool meie komponenti vajalik kood pikem kui komponent ise. Ma ei tea, kuidas teiega on, aga minu jaoks tundub see veidi segane. Arendajad võivad hakata seda koodi lugema ülevalt, mitte nägema alumist osa, ja hakata mõtlema, kust postMetaja kust setPostMetasee pärit on – need näivad olevat võluväel kättesaadavad. Minu jaoks on see väga ebaintuitiivne.
Vaatame, kuidas me ülaltoodud näite konksudeks teisendaksime.
Kasutades useSelectjauseDispatch
Kui ilus ja loetav see on?! Näeme oma komponendis otsekohe, kust postMetahangitakse ja kuidas me sellele juurdepääsu saame editPost. Meie komponenti on ka palju lihtsam taaskasutada.
Pange tähele, et useDispatchreale #12lisame sõltuvusena värskendatava postmeta (postMeta.example_post_meta). Kui peaksite hoidma selles komponendis mitut postituse metamuutujat ajakohasena, peaksite need kõik lisama sõltuvusena, et tagada lähetamise käitamine (tegelikult salvestades postituse meta), kui ühe neist väärtus muutub.
Loodan, et see oli kellelegi informatiivne ja kasulik. Konksud on mulle veel veidi võõrad, kuid nähes nende kasutamise eeliseid, ei pöördu ma tagasi!