prezentációs és konténer alkatrészek

frissítés 2019-től: ezt a cikket már régen írtam, és a nézeteim azóta fejlődtek. Különösen nem javaslom az alkatrészek ilyen felosztását. Ha természetesnek találja a kódbázisában, ez a minta hasznos lehet. De láttam, hogy minden szükség nélkül és szinte dogmatikus buzgalommal hajtják végre túl sokszor. A fő ok, amiért hasznosnak találtam, az volt, hogy lehetővé tette, hogy elkülönítsem a komplex állapotos logikát az összetevő más szempontjaitól. Hooks megengedte, hogy ugyanezt tegyem önkényes felosztás nélkül. Ez a szöveg történelmi okokból sértetlen marad, de ne vegye túl komolyan.

van egy egyszerű minta, amelyet rendkívül hasznosnak találok a React alkalmazások írásakor. Ha egy ideje reagálsz, akkor valószínűleg már felfedezted. Ez a cikk jól elmagyarázza, de Szeretnék még néhány pontot hozzáadni.

a komponenseket sokkal könnyebb újrafelhasználni és indokolni, ha két kategóriába soroljuk őket. Konténereknek és prezentációs komponenseknek hívom őket*, de hallottam kövéreket és Soványakat, okosakat és Butákat, Állapotosakat és Tisztákat, képernyőket és alkatrészeket stb. Ezek mind nem teljesen ugyanazok, de az alapötlet hasonló.

prezentációs komponenseim:

• érdekli, hogy néznek ki a dolgok.
• tartalmazhat mind prezentációs, mind konténer komponenseket** belül, és általában rendelkezik néhány DOM jelöléssel és saját stílusokkal.
• gyakran lehetővé teszik az elszigetelést ezen keresztül.kellékek.gyerekek.
• nincs függőség az alkalmazás többi részétől, például a Flux műveletektől vagy az üzletektől.
• ne adja meg az adatok betöltésének vagy mutációjának módját.
• adatok és visszahívások fogadása kizárólag kellékeken keresztül.
• ritkán van saját állapotuk (ha igen, akkor inkább UI állapot, mint adat).
• funkcionális komponensként íródnak, kivéve, ha állapot -, életciklus-horgokra vagy teljesítmény-optimalizálásra van szükségük.
• Példák: Oldal, Oldalsáv, Történet, Felhasználói Információ, Lista.

saját konténer alkatrészek:

• a dolgok működésével foglalkoznak.
• tartalmazhat mind prezentációs, mind konténer komponenseket** belül, de általában nincs saját DOM jelölésük, kivéve néhány csomagoló div-t, és soha nem rendelkeznek stílusokkal.
• adja meg az adatokat és a viselkedést a prezentációs vagy más tárolóelemeknek.
• hívja meg a Flux műveleteket, és adja meg ezeket visszahívásként a prezentációs komponensekhez.
• gyakran állapotosak, mivel általában adatforrásként szolgálnak.
• általában magasabb rendű összetevők felhasználásával készülnek, mint például a connect() react Redux-ból, createContainer () relé vagy konténer.create () a Flux Utils, hanem kézzel írt.
• Példák: UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

különböző mappákba tettem őket, hogy ez a megkülönböztetés egyértelmű legyen.

e megközelítés előnyei

• az aggodalmak jobb szétválasztása. Jobban megérti az alkalmazást és a felhasználói felületet, ha ilyen módon írja az összetevőket.
• jobb újrafelhasználhatóság. Használhatja ugyanazt a prezentációs összetevőt teljesen különböző állapotforrásokkal, és azokat külön tárolóelemekké alakíthatja, amelyek tovább felhasználhatók.
• a prezentációs összetevők lényegében az alkalmazás “palettája”. Egyetlen oldalra helyezheti őket, és hagyhatja, hogy a tervező módosítsa az összes variációt anélkül, hogy megérintené az alkalmazás logikáját. Tudod fuss screenshot regressziós tesztek ezen az oldalon.
• ez arra kényszerít, hogy kibontsa az “elrendezési összetevőket”, például az oldalsávot, az oldalt, a Kontextusmenüt, és használja ezt.kellékek.gyerekek helyett duplikálása ugyanazt a jelölést és az elrendezés több konténer alkatrészek.

ne feledje, hogy az alkatrészeknek nem kell DOM-ot kibocsátaniuk. Csak összetételi határokat kell megadniuk az UI aggályai között.

használja ki ezt.

mikor kell bevezetni a konténereket?

azt javaslom, hogy először csak prezentációs komponensekkel kezdje el építeni az alkalmazást. Végül rájössz, hogy túl sok kelléket adsz át a közbenső alkatrészeken. Amikor azt veszi észre, hogy egyes alkatrészek nem használják a kapott kellékeket, hanem egyszerűen továbbítják őket, és újra kell vezetniük az összes közbenső alkatrészt, amikor a gyerekeknek több adatra van szükségük, akkor jó alkalom néhány konténer alkatrész bevezetésére. Így az adatokat és a viselkedéstámogatásokat a levélkomponensekhez kaphatjuk anélkül, hogy a fa közepén lévő nem kapcsolódó komponenseket megterhelnénk.

ez egy folyamatos refaktorálási folyamat, ezért ne próbálja meg az első alkalommal. Ahogy kísérletezel ezzel a mintával, intuitív érzéked lesz arra, hogy mikor kell kibontani néhány tárolót, csakúgy, mint tudod, mikor van ideje kibontani egy funkciót. Az ingyenes Redux Egghead sorozatom ebben is segíthet!

Egyéb dichotómiák

fontos megérteni, hogy a prezentációs komponensek és a konténerek közötti különbségtétel nem technikai jellegű. Inkább a céljuk megkülönböztetése.

ezzel szemben itt van néhány kapcsolódó (de különböző!) MŰSZAKI különbségek:

• hontalan és hontalan. Egyes komponensek a React setState() metódust használják, mások nem. míg a konténerkomponensek általában állapotmentesek, a prezentációs komponensek pedig állapotmentesek, ez nem nehéz szabály. A prezentációs komponensek lehetnek állapotmentesek, a konténerek pedig állapotmentesek is.
• osztályok és függvények. Mivel a React 0.14, az összetevők mind osztályként, mind függvényként deklarálhatók. A funkcionális komponenseket egyszerűbb meghatározni, de hiányoznak bizonyos funkciók, amelyek jelenleg csak az osztályösszetevők számára érhetők el. Ezek a korlátozások a jövőben megszűnhetnek, de ma léteznek. Mivel a funkcionális komponensek könnyebben érthetők, azt javaslom, hogy használja őket, hacsak nincs szüksége állapotra, életciklus-horgok, vagy teljesítményoptimalizálás, amelyek jelenleg csak az osztálykomponensek számára érhetők el.
• tiszta és tisztátalan. Az emberek azt mondják, hogy egy összetevő tiszta, ha garantáltan ugyanazt az eredményt adja vissza, ugyanazokkal a kellékekkel és állapotokkal. A tiszta komponensek osztályokként és függvényekként is definiálhatók, és lehetnek állapotosak és állapotmentesek is. A pure components másik fontos szempontja, hogy nem támaszkodnak a kellékek vagy az állapot mély mutációira, így renderelési teljesítményük optimalizálható a shouldComponentUpdate() horog sekély összehasonlításával. Jelenleg csak az osztályok határozhatják meg a shouldComponentUpdate() függvényt, de ez a jövőben változhat.

mind a prezentációs alkatrészek, mind a tartályok beleeshetnek bármelyik vödörbe. Tapasztalatom szerint a prezentációs komponensek általában állapot nélküli tiszta függvények, a konténerek pedig állapotos tiszta osztályok. Ez azonban nem szabály, hanem megfigyelés, és pontosan ellentétes eseteket láttam, amelyeknek konkrét körülmények között volt értelme.

ne vegye dogmának a prezentációs és konténerkomponens-elválasztást. Néha nem számít, vagy nehéz meghúzni a határt. Ha nem biztos abban, hogy egy adott alkatrésznek bemutatónak vagy tárolónak kell-e lennie, akkor túl korai lehet eldönteni. Ne izgulj!

példa

ez a lényeg Michael Chan nagyjából körmök is.

további olvasmányok

• első lépések A Redux
• Mixins halott, éljen összetétel
• konténer alkatrészek
• Atomic Web Design
• a Facebook hírcsatorna építése relé

lábjegyzetek

* a cikk egy korábbi verziójában “okos” és “buta” komponenseknek neveztem őket, de ez túlságosan durva volt a prezentációs komponensekkel szemben, és ami a legfontosabb, nem igazán magyarázta meg a céljuk közötti különbséget. Sokkal jobban élvezem az új feltételeket, és remélem, hogy te is!

** a cikk egy korábbi verziójában azt állítottam, hogy a prezentációs komponenseknek csak más prezentációs komponenseket kell tartalmazniuk. Már nem hiszem, hogy ez a helyzet. Az, hogy egy komponens prezentációs komponens vagy konténer, a megvalósítás részlete. Képesnek kell lennie arra, hogy a prezentációs összetevőt egy tárolóra cserélje anélkül, hogy bármelyik híváshelyet módosítaná. Ezért mind a prezentációs, mind a konténerkomponensek tartalmazhatnak más prezentációs vagy konténerkomponenseket.