Komponendi olek vs Reduxi pood

Töötades Reacti ja Reduxiga, kasutan lihtsat mustrit, et muuta oma komponendid taaskasutatavaks ja põhjendada seda. Reaktoriga töötades olen viimase pooleteise aasta jooksul aru saanud, et kõik, kes hakkavad Reacti ja Reduxiga koostööd tegema, on alati segaduses otsustades, milline komponent peaks redutseerija poega suhtlema ja millised komponendid peaksid sellest lihtsalt olekust sõltuma.

Niisiis püüan selles artiklis eristada seda, millal valida komponendi olek ja millal Reduxi pood valida.

Alustuseks keskendume kõigepealt reageerimisele.

Reakt on kahte tüüpi komponente: -

  1. Nutikad komponendid
  2. Loll komponendid - nimetatakse ka esitluskomponentideks

Ma eristan neid kahest järgmiselt:

Kui komponent peab olekut hoidma, liigitatakse see arukaks komponendiks.
Kui komponent vajab lihtsalt andmete kuvamist ja saab neid andmeid selle vanemalt komponendilt vastu võtta, siis klassifitseeritakse need esitluskomponentideks või rumalateks komponentideks.

Näide: - Oletame, et meil on e-kaubanduse rakendus, kus meil on toodete loendi leht, mis kuvab toodete loendi.

Selle stsenaariumi korral oleksid skelett või tühi paigutus järgmised kõrgema taseme komponendid: -


 
 
 
 

Siin olev komponent ProductsContainer keskenduks toodete loendi hankimisele ja seejärel itereeriks läbi kõigi toodete ja renderdaks iga tootekomponendi.

Siin võime nimetada ProductsContaineri nutikaks komponendiks, kuna see komponent hoiab olekut, mis antud juhul on toodete loend.

Tootekomponendi, mis on meie esitluskomponent, näidiskood näeks välja umbes selline: -

Ülaltoodud on esitluskomponent, kuna selle ülesandeks on ainult andmete kuvamine ja ta võtab neid andmeid tugikomponendina oma vanemast komponendist.

Kokkuvõtteks võib öelda, et kui komponent hoiab olekut ja manipuleerib sellega, on see nutikas komponent ja kui komponent kuvab lihtsalt andmeid, mida ta saab rekvisiitide kujul, klassifitseeritakse see esitluskomponendiks.

Dan Abramovi kuldne tsitaat, mis tõstab selle esile, on:

Kui märkate, et mõned komponendid ei kasuta saadud rekvisiite, vaid edastavad need lihtsalt alla ja peate kõik need vahekomponendid ümber kerima, kui lapsed vajavad rohkem andmeid, on hea aeg tutvustada mõnda konteineri komponenti.

See puudutas komponendi olekut, järgmine küsimus, mis meile pähe tuleb, on see, millised andmed peaksid reduxi poodi minema.

Selle klassifitseerimise viisiks on olukord, kus kunagi tuleb olekut jagada mitme komponendi või mitme lehe vahel ja me peame marsruudimuudatuste osas teatud andmeid säilitama, kõik need andmed peaksid minema reduxi poodi.

Sama näite jätkamiseks oletame, et kõigil neil toodetel on nupp Osta kohe ja meil on ostukorv, mis peaks hoidma kõiki neid tooteid, mille jaoks nuppu Osta kohe on klõpsatud.

See ostukorviteave peab püsima paljudel lehtedel ja komponentide lõikes, näiteks päisekomponendis, kus kuvame ostukorvide arvu, kassasse ja makselehte.

See on selge viide sellele, et ostukorvi lisatud tooted peaksid minema komponendi oleku asemel redux-poodi.

See viib meid veel ühe eristamiseni komponentide vahel: -

  1. Kõik komponendid, mis on ühendatud redux-kauplusega, klassifitseeritakse konteineri komponentideks. See võib toiminguid saata ja redigeerimistehase kaudu redigeerida.
  2. Komponendid, mis pole redux-poodiga ühendatud, lähevad komponentide kausta. Nüüd saab neid komponente täiendavalt liigitada ka nutikateks ja lollideks, sest kuigi nad pole redux-poodiga ühendatud, suudavad need siiski olekut hoida, kutsudes mõnda API-d ja säilitades neid andmeid ainult selle komponendi eluea jooksul.

Näiteks:-

Komponendi ShoppingApp võib liigitada konteinerikomponendiks ja vastutada esialgse ostukorvi arvu ja sisselogimisteabe hankimise eest.

Me ei hakka süvenema reduxi ja erinevate redutseerimisfunktsioonide, nagu mapStateToProps, toimingute loojad, dispetšerid, toimimisse.

Kõiki neid asju saab Redux Docsist lugeda.

Lõpliku rakenduse, mille ehitame, makett on midagi sellist: -

Pärast reduktorite, komponentide, konteinerite ja toimingute lisamist on näide minu kataloogistruktuuri soovist: -

Siin ühendatakse ShoppingApp reduxi kauplusega ja see saadab toimingu, et hankida esialgsed ostukorvi andmed. See teeb ShoppingAppist konteineri komponendi.

ShoppingApp edastaks need andmed päisekomponendile.

See muudab päise lihtsalt komponendiks ja kuna sellel ei ole oma komponendi olekut, liigitatakse see lisaks esitluskomponendiks.

ProductsContainer redutseeritult ei kvalifitseeru konteineri komponendiks, kuna see pole ühendatud redux-poodiga, vaid kuna sellel on oma komponendi olek, mis liigitab selle nutikaks komponendiks.

Ülaltoodud näite täielik kood leiate järgmiselt koodide ja kasti URL-ist: -

Mõne stiili jaoks olen lisanud reagect material-ui.

Kokkuvõtteks võib öelda, et kui teie komponent peab suhelda reduxi kauplusega, hallata andmeid ja edastada toiminguid, peaks see minema konteineritesse, vastasel juhul komponentide sisse.

Lisalugemist

  • Esitlus- ja konteinerikomponendid
  • Reduxi dokumentatsioon
  • Konteineri komponendid