Stav komponenty vs. obchod Redux

Při práci s Reactem a Reduxem používám jednoduchý vzor k tomu, aby byly moje komponenty znovu použitelné a abych o nich přemýšlel. V posledních 1 a půl roce práce s Reactem jsem si uvědomil, že každý, kdo začíná pracovat s Reactem a Reduxem, vždycky čelí zmatku. rozhodování, která komponenta by měla interagovat s úložištěm redux a které komponenty by na něm měly záviset pouze na vlastním stavu.

V tomto článku se pokusím o to, aby bylo toto rozlišení mezi tím, kdy zvolit stav komponenty a kdy zvolit úložiště Redux, snazší.

Nejdříve se zaměřme na React.

React má dva typy komponent: -

  1. Inteligentní komponenty
  2. Hloupé komponenty - nazývané také jako komponenty prezentace

Způsob, jakým rozlišuji mezi nimi, je: -

Pokud součást potřebuje udržet stav, klasifikuje se jako inteligentní součást.
Pokud komponenta potřebuje pouze zobrazit data a může je přijmout z rodičovské komponenty, jsou klasifikována jako prezentační komponenty nebo němé komponenty.

Například: - Řekněme, že máme aplikaci elektronického obchodování, kde máme stránku se seznamem produktů, která zobrazuje seznam produktů.

V tomto scénáři by kostra nebo holé rozvržení mělo následující komponenty vyšší úrovně: -


 
 
 
 

Komponenta ProductsContainer by se zde zaměřila na získání seznamu produktů a poté iteraci přes každý z produktů a vykreslení každé komponenty produktu.

Zde můžeme nazvat ProductsContainer jako inteligentní komponentu, protože tato komponenta obsahuje stav, který v tomto případě představuje seznam produktů.

Ukázkový kód komponenty produktu, který je naší prezentační komponentou, by vypadal asi takto: -

Výše uvedené je prezentační komponenta, protože je zodpovědná pouze za zobrazování dat a přijímá tato data ve formě rekvizit od své nadřazené komponenty.

Na závěr, pokud komponenta drží stav a manipuluje s ním, je to inteligentní komponenta a pokud komponenta pouze zobrazuje data, která přijímá ve formě rekvizit, je klasifikována jako prezentační komponenta.

Zlatý citát od Dana Abramova, který zdůrazňuje toto:

Když si všimnete, že některé komponenty nevyužívají rekvizity, které dostávají, ale pouze je předávají dolů, a kdykoli děti potřebují více dat, musíte je znovu propojit, je vhodné zavést některé komponenty kontejneru.

To se týkalo stavu komponent, další otázkou, která nás napadne, je, která data by měla jít dovnitř obchodu redux.

Způsob, jakým to klasifikuji, je, když je třeba stav kdykoli sdílet s více komponentami nebo více stránkami a my potřebujeme přetrvávat některá data při změnách trasy, všechna tato data by měla jít do úložiště redux.

Chcete-li pokračovat ve stejném příkladu, řekněme, že všechny tyto produkty mají tlačítko Koupit nyní a máme vozík, který by měl uchovávat všechny položky, na které bylo tlačítko Koupit nyní kliknuto.

Tato informace o vozíku musí být zachována na mnoha stránkách a ve složkách, jako je součást hlavičky, kde v ní ukážeme počet vozíků, stránku pokladny a stránku plateb.

To je jasný náznak, že produkty přidané do košíku by měly jít spíše do úložiště redux než do stavu komponenty.

To nás přivádí k dalšímu rozlišení mezi komponenty: -

  1. Jakákoli součást, která je spojena s úložištěm redux, je klasifikována jako součást kontejneru. Může odesílat akce a aktualizovat úložiště redux prostřednictvím reduktorů.
  2. Komponenty, které nejsou připojeny k úložišti redux, jdou uvnitř složky Components.Now tyto komponenty lze také dále klasifikovat jako Smart a Dumb, protože i když nejsou připojeny k úložišti redux, stále mohou udržovat stav voláním nějakého API a přetrvávání těchto dat pouze do doby životnosti dané komponenty.

Například:-

Komponenta ShoppingApp může být klasifikována jako komponenta kontejneru a být zodpovědná za vyvolání počátečního počtu košíku a přihlašovacích informací.

Nebudeme se hlouběji věnovat fungování reduxu a různých reduxových funkcí, jako jsou mapStateToProps, tvůrci akcí, dispečeři.

Všechny tyto věci lze přečíst z Redux Docs.

Maketa pro konečnou aplikaci, kterou budeme stavět, bude něco takového: -

Po přidání reduktorů, komponent, kontejnerů, akcí je příkladem, jak by moje struktura adresáře chtěla: -

Zde bude ShoppingApp připojen k úložišti redux a odešle akci, aby získal počáteční data košíku. Díky tomu bude ShoppingApp jako komponenta kontejneru.

ShoppingApp předá tato data komponentě záhlaví.

Díky tomu je záhlaví pouze jako součást a protože nemá vlastní stav komponenty, dále se klasifikuje do prezentace.

ProductsContainer v termínech redux se nepovažuje za komponentu kontejneru, protože není připojen k úložišti redux, ale protože má svůj vlastní stav komponenty, který jej klasifikuje jako inteligentní komponentu.

Úplný kód pro výše uvedený příklad lze nalézt na následující adrese URL a pole codeandbox: -

Pro nějaký styl jsem přidal reakční materiál-ui.

Závěrem tedy platí, že pokud vaše komponenta potřebuje interagovat s úložištěm redux, zpracovávat data a odesílatelské akce, měla by jít dovnitř kontejnerů, jinak uvnitř komponent.

Další čtení

  • Prezentační a kontejnerové komponenty
  • Redux dokumentace
  • Komponenty kontejneru