Mik a bemutató és a konténer alkatrészek a reakcióban? – CloudSavvy IT

A React olyan komponens-alapú architektúrával rendelkezik, amely arra ösztönzi Önt, hogy ossza fel a kódbázist a funkcionalitás újrafelhasználható egységeire. Nem minden komponens jön létre egyenlően. Vizsgáljuk meg a két általános típus, a Presentational és a Container (más néven „Stateful”) komponensek közötti különbségeket.

Van-e állam?

Először is hangsúlyozni kell, hogy ezek a kifejezések nem utalnak semmilyen konkrét React szolgáltatásra. Leírják a React komponensek írásmódját, amely segít fenntartani a modularitást és elkülöníteni az aggályokat. A két komponenstípus létezése a kódbázisában hozott döntésekből adódik.

Csak egy megkülönböztető tényező van: a konténerkomponenseknek van állapotuk, a prezentációs komponenseknek pedig nincs. A gyakorlatban ez azt jelenti, hogy egy konténerkomponens mindig felhívja a React-et setState() módszer. A prezentációs komponens soha nem fogja használni az állapotot.

Példákat nézve

Itt egy egyszerű bemutató komponens:

import React from "react";
 
class Presentational extends React.Component {
 
    render() {
        return <h1>{this.props.title}</h1>;
    }
 
}
 
export default Presentational;

Az alkatrész rendkívül egyszerű. Ez egyetlen h1 címke, amely a komponensen keresztül továbbított szöveget jeleníti meg title támaszt. Most nézzünk meg egy állapotfigyelő tároló összetevőt:

import React from "react";
 
class Container extends React.Component {
 
    constructor(props) {
        super(props);
 
        this.state = {
 
            time: (new Date()).toString()
 
        };
 
    }
 
 
    componentDidMount() {
        setInterval(() => {
            this.setState({time: (new Date()).toString()});
        }, 1000);
    }
 
 
    render() {
        return <h1>{this.state.time}</h1>;
    }
 
}
 
export default Container;

A konténer alkatrészei render módszer szinte megegyezik a prezentációs komponensével. A különbség az, hogy a tartálykomponens a szövegét önmagából forrja, ahelyett, hogy egy külső értékre támaszkodna, mint a kellék.

Minden másodpercben a tároló összetevő hív setState() hogy frissítse a time kulcs az állapotában. Ez azt eredményezi, hogy a React újra rendereli az összetevőt és megjeleníti az új időt. Konténerünk rendelkezik saját állapotával.

Az egyes típusok jellemzői

Számos egyedi jellemző hajlamos felmerülni mind a prezentációs, mind a konténerkomponenseken belül. Először a prezentációs összetevőket vizsgálva, valószínűleg a kódjaik nagy része a render módszer. Nagyon kevés logikát tartalmaznak, mivel viselkedésüket a külvilág határozza meg.

A prezentációs komponensek boldogan nincsenek tisztában azzal, honnan származnak adataik. Nem tudják, mikor (vagy hogy) változik-e. Néhány példa talán nem is fogadja el a kellékeket. Itt van egy díszítő elem, amely egyszerűen megjelenít egy adott képfájlt:

export () => <img src="https://www.cloudsavvyit.com/logo.png" />

A konténerek alkatrészei sokkal ellentétesek a prezentációs társaikkal. Általában azt találja, hogy webhelye logikájának nagy része egy tároló összetevőbe kerül. A render A módszer meglehetõsen rövid lehet, mivel még sok sort költ az adatok külsõ forrásokból történõ lekérésére, az igényeinek megfelelõ átalakításra, majd állapotba tárolásra.

Egy konténer alkatrész render A módszer egy sorból állhat, amely egy prezentációs komponenst jelenít meg. Most már alaposan elkülönítette az aggodalmakat, mindkét komponensnek külön szerepe van, amely teljes mértékben tiszteletben tartja a másikét. A konténer összetevő az adatokat forrja; a prezentációs komponens a képernyőre teszi.

Így néz ki ez a gyakorlatban:

import React from "react";
 
const View = ({title, body}) => (
    <div>
        <h1>{title}</h1>
        <p>{body}</p>
    </div>
);
 
class BlogPostComponent extends React.Component {
 
    constructor(props) {
        super(props);
 
        this.state = {
 
            blog: null
 
        };
 
    }
 
 
    componentDidMount() {
        fetch("/blog-post.json")
            .then(response => response.json());
            .then(blog => this.setState({blog}));
    }
 
 
    render() {
        return (
            <View
                title={this.state.blog.headline}
                body={this.state.blog.content} />
        );
    }
 
}}

BlogPostComponent a konténer alkatrészünk. Bejegyzést tölt be a hálózaton keresztül. Az adatokat ezután megkapja a View komponens a megjelenítéshez. View nem érdekli, honnan veszi az adatait – a jövőben újra felhasználhatnánk egy harmadik fél API-ból, például a Facebookról vagy a Twitterről letöltött bejegyzések megjelenítésére.

A tárolókomponenseket azért hívják, mert hajlamosak az alkalmazás teljes funkcionális területeit befogadni. Működtetik a projektet, és képviselik az alkalmazás háttérrendszereit.

Egy igazi kódbázisban BlogPostComponent még nagyobb felelőssége lenne. Nyomon kell követnie, hogy a bejegyzés betöltődött-e, és kezelnie kell-e a hibákat a hálózat lekérése során. Következésképpen a render A módszer tartalmazhat néhány alapvető logikát a megjelenített adatok megváltoztatásához – akár hibaüzenetet, haladási sávot, akár prezentációnkat View összetevő. A prezentációs összetevőknek soha nincs nagyobb felelősségük, mint az UI egy adott szakaszának a DOM-ba történő áthelyezése.

A bemutató és a konténer alkatrészek elválasztásának előnyei

Ennek a mintának a használata megkönnyíti a kódbázis rendezését, és megakadályozza, hogy az alkatrészek túl nehézkessé váljanak. Bár ez nem egy kemény és gyors szabály, a két típus szorgalmas elkülönítése javítja a karbantarthatóságot, ahogy a projekt összetevőinek száma növekszik.

Próbáljon utánanézni a refrakcionálás lehetőségeinek, mint egy konténer alkatrész render módszer nő. Valószínű, hogy a tartalmának nagy részét elveheti, és új prezentációs komponensre oszthatja. Ez megkönnyíti a prezentációs kód újrafelhasználását a jövőben. Végül önálló és képes bármilyen adatforrástól függetlenül működni.

Az állapotjelző komponensek ritkábban kerülnek újrafelhasználásra. A nem triviális viselkedések természetesen felhalmozódnak bennük, ami a külvilágtól való függőséget eredményez. Ez nem azt jelenti, hogy ők nem lehet újra felhasználható – a kétlépcsős megerősítő gomb belső állapotot tartalmaz (annak eldöntésére, hogy a „Felhasználó jelszavának visszaállítása” vagy a „Biztos vagy benne?” jelenik meg), de a kódbázisban is telepítésre kerül.

Talán mindennél jobban, ha szándékosan különbséget tesz a Jelen és a Konténer összetevők között, akkor tudatában lehet annak, hogy hol található az alkalmazás állapota. Az állapotú komponensek számának minimalizálása hozzájárul a karbantartható kódbázis kialakításához, és segít elkülöníteni az aggályokat.

Ha nem tudja eldönteni, hogy egy komponensnek állapotban kell-e maradnia, akkor folytassa a kódolást és a refaktort később – valószínűleg túl korai a projekt életciklusában, hogy tudjuk, hol fog összegyűlni a komplexitás (és így az állam).