రియాక్ట్ ఒక భాగం-ఆధారిత నిర్మాణాన్ని కలిగి ఉంది, ఇది మీ కోడ్ బేస్ను పునర్వినియోగ ఫీచర్ యూనిట్లుగా విభజించమని మిమ్మల్ని ప్రోత్సహిస్తుంది. అయితే, అన్ని భాగాలు ఒకేలా ఉండవు. ప్రెజెంటేషనల్ మరియు కంటైనర్ (“స్టేట్ఫుల్” అని కూడా పిలుస్తారు) భాగాలు అనే రెండు సాధారణ రకాలు మధ్య తేడాలను పరిశీలిద్దాం.
ఏదైనా రాష్ట్రం ఉందా?
ప్రారంభించడానికి, ఈ నిబంధనలు ఏదైనా నిర్దిష్ట రియాక్ట్ లక్షణాలను సూచించవని గమనించాలి. మాడ్యులారిటీ మరియు ప్రత్యేక చింతలను నిర్వహించడానికి సహాయపడే రియాక్ట్ భాగాల యొక్క రచనా శైలిని వారు వివరిస్తారు. రెండు రకాల భాగాల ఉనికి బేస్ కోడ్లో చేసిన ఎంపికల నుండి ఉద్భవించింది.
ఒకే ఒక ప్రత్యేకమైన అంశం ఉంది: కంటైనర్ భాగాలు స్థితిని కలిగి ఉంటాయి మరియు ప్రదర్శన భాగాలు ఉండవు. ఆచరణలో, దీని అర్థం కంటైనర్ భాగం ఎల్లప్పుడూ రియాక్ట్ చేయడానికి కాల్ చేస్తుంది setState()
పద్ధతి. ప్రెజెంటేషన్ భాగం ఎప్పటికీ రాష్ట్రాన్ని ఉపయోగించదు.
ఉదాహరణలు చూస్తే
ఇక్కడ సాధారణ ప్రదర్శన భాగం:
import React from "react"; class Presentational extends React.Component { render() { return <h1>{this.props.title}</h1>; } } export default Presentational;
భాగం చాలా సులభం. సింగిల్ చేస్తుంది h1
ట్యాగ్ దాని ద్వారా భాగానికి పంపిన వచనాన్ని ప్రదర్శిస్తుంది title
ఆసరా. ఇప్పుడు స్టేట్ఫుల్ కంటైనర్ భాగాన్ని పరిశీలిద్దాం:
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;
కంటైనర్ భాగం render
పద్ధతి ప్రెజెంటేషన్ కాంపోనెంట్తో సమానంగా ఉంటుంది. వ్యత్యాసం ఏమిటంటే, కంటైనర్ భాగం మద్దతుగా పంపబడిన బాహ్య విలువపై ఆధారపడటానికి బదులు, దాని నుండినే వచనాన్ని పొందుతుంది.
ప్రతి సెకనులో, కంటైనర్ భాగం పిలుస్తుంది setState()
ఫైల్ను నవీకరించడానికి time
దాని రాష్ట్రంలో కీ. ఇది రియాక్ట్ భాగాన్ని తిరిగి అందించడానికి మరియు క్రొత్త సమయాన్ని ప్రదర్శించడానికి కారణమవుతుంది. మా కంటైనర్ దాని స్వంత స్థితిని కలిగి ఉంది.
అన్ని రకాల లక్షణాలు
ప్రదర్శన మరియు కంటైనర్ భాగాలు రెండింటిలోనూ అనేక ప్రత్యేక లక్షణాలు తలెత్తుతాయి. మొదట ప్రెజెంటేషన్ భాగాలను చూస్తే, వాటి కోడ్ చాలావరకు ఉనికిలో ఉంటుంది render
పద్ధతి. వారి ప్రవర్తన బయటి ప్రపంచం నిర్వచించినందున అవి చాలా తక్కువ తర్కాన్ని కలిగి ఉంటాయి.
ప్రెజెంటేషన్ భాగాలు వాటి డేటా ఎక్కడ నుండి వస్తుందో తెలియదు. అది ఎప్పుడు మారుతుందో వారికి తెలియదు (లేదా ఉంటే). కొన్ని ఉదాహరణలు ఆధారాలను కూడా అంగీకరించకపోవచ్చు. ఒక నిర్దిష్ట ఇమేజ్ ఫైల్ను అందించే అలంకార మూలకం ఇక్కడ ఉంది:
export () => <img src="https://www.cloudsavvyit.com/logo.png" />
కంటైనర్ భాగాలు వాటి ప్రదర్శన ప్రతిరూపాలకు చాలా వ్యతిరేకం. మీ సైట్ యొక్క చాలా తర్కం కంటైనర్ భాగం లోపల ముగుస్తుందని మీరు సాధారణంగా కనుగొంటారు. ది render
బాహ్య వనరుల నుండి డేటాను తిరిగి పొందడానికి, మీ అవసరాలకు అనుగుణంగా దాన్ని మార్చడానికి మరియు తరువాత రాష్ట్రంలో నిల్వ చేయడానికి మీరు ఇంకా చాలా పంక్తులను ఖర్చు చేస్తారు కాబట్టి ఈ పద్ధతి చాలా తక్కువగా ఉండవచ్చు.
కంటైనర్ యొక్క ఒక భాగం render
పద్ధతి ప్రెజెంటేషన్ భాగాన్ని తయారుచేసే ఒకే పంక్తిని కలిగి ఉంటుంది. మీరు ఇప్పుడు ఆందోళనల యొక్క బలమైన విభజనను కలిగి ఉన్నారు, రెండు భాగాలు ప్రత్యేకమైన పాత్రను కలిగి ఉంటాయి, అది మరొకటి పూర్తిగా గౌరవిస్తుంది. కంటైనర్ భాగం డేటాను ఉత్పత్తి చేస్తుంది; ప్రెజెంటేషన్ భాగం తెరపై ఉంచుతుంది.
ఆచరణలో ఇది ఎలా ఉందో ఇక్కడ ఉంది:
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
మా కంటైనర్ భాగం. నెట్వర్క్కు పోస్ట్ను అప్లోడ్ చేయండి. అప్పుడు డేటా అందించబడుతుంది View
రెండరింగ్ కోసం భాగం. View
డేటా ఎక్కడ నుండి వచ్చినా సరే – భవిష్యత్తులో మేము ఫేస్బుక్ లేదా ట్విట్టర్ వంటి మూడవ పార్టీ API నుండి తిరిగి పొందిన పోస్ట్లను చూడటానికి దాన్ని తిరిగి ఉపయోగించుకోవచ్చు.
కంటైనర్ భాగాలు అలా పిలువబడతాయి ఎందుకంటే అవి మీ అనువర్తనం యొక్క మొత్తం క్రియాత్మక ప్రాంతాలను కలుపుతాయి. అవి మీ ప్రాజెక్ట్ పని చేస్తాయి మరియు అనువర్తనం యొక్క బ్యాకెండ్ వ్యవస్థలను సూచిస్తాయి.
నిజమైన కోడ్ బేస్ లో, BlogPostComponent
మరింత బాధ్యత ఉంటుంది. ఇది పోస్ట్ అప్లోడ్ చేయబడిందో లేదో పర్యవేక్షించాలి మరియు నెట్వర్క్ నుండి తిరిగి పొందేటప్పుడు లోపాలను నిర్వహించాలి. పర్యవసానంగా, ది render
ప్రదర్శించబడే వాటిని మార్చడానికి ఈ పద్ధతి కొన్ని ప్రాథమిక తర్కాలను కలిగి ఉంటుంది: దోష సందేశం, పురోగతి పట్టీ లేదా మా ప్రదర్శన View
భాగం. DOM లోని వినియోగదారు ఇంటర్ఫేస్ యొక్క నిర్దిష్ట విభాగాన్ని అందించడానికి ప్రెజెంటేషన్ భాగాలకు ఎప్పటికీ ఎక్కువ బాధ్యత ఉండదు.
ప్రదర్శన మరియు కంటైనర్ భాగాలను వేరు చేయడం యొక్క ప్రయోజనాలు
ఈ మూసను ఉపయోగించడం మీ కోడ్ బేస్ను నిర్వహించడానికి మీకు సహాయపడుతుంది మరియు భాగాలు చాలా పెద్దదిగా మారకుండా నిరోధిస్తుంది. కఠినమైన మరియు వేగవంతమైన నియమం కానప్పటికీ, మీ ప్రాజెక్ట్ యొక్క భాగం సంఖ్య పెరిగేకొద్దీ రెండు రకాలను శ్రద్ధగా వేరు చేయడం నిర్వహణను మెరుగుపరుస్తుంది.
కంటైనర్ కాంపోనెంట్గా రిఫ్యాక్టర్ చేయడానికి అవకాశాల కోసం ప్రయత్నించండి render
పద్ధతి పెరుగుతుంది. మీరు దాని కంటెంట్ను ఎక్కువగా తీసుకొని క్రొత్త ప్రెజెంటేషన్ కాంపోనెంట్గా విభజించే అవకాశాలు ఉన్నాయి. ఇది భవిష్యత్తులో ప్రదర్శన కోడ్ను తిరిగి ఉపయోగించడం సులభం చేస్తుంది. ఇది స్వయంచాలకంగా ఉంటుంది మరియు ఏదైనా నిర్దిష్ట డేటా మూలం నుండి స్వతంత్రంగా పనిచేయగలదు.
స్టేట్ఫుల్ భాగాలు తిరిగి ఉపయోగించబడే అవకాశం తక్కువ. అల్పమైన ప్రవర్తనలు సహజంగానే వాటిలో పేరుకుపోతాయి, ఫలితంగా బాహ్య ప్రపంచంపై ఆధారపడతాయి. ఇది అలా కాదు నా వల్లా కాదు తిరిగి ఉపయోగించబడుతుంది – రెండు-దశల నిర్ధారణ బటన్ అంతర్గత స్థితిని కలిగి ఉంటుంది (“వినియోగదారు పాస్వర్డ్ను రీసెట్ చేయి” లేదా “మీకు ఖచ్చితంగా తెలుసా?” అని ప్రదర్శించాలో నిర్ణయించడానికి) కానీ కోడ్ బేస్ అంతటా పంపిణీ చేయబడుతుంది.
అన్నింటికన్నా ఎక్కువగా, ప్రెజెంటేషనల్ మరియు కంటైనర్ భాగాల మధ్య ఉద్దేశపూర్వకంగా వేరు చేయడం వల్ల మీ అప్లికేషన్ యొక్క స్థితి ఎక్కడ ఉందో మీకు తెలుస్తుంది. స్టేట్ఫుల్ భాగాల సంఖ్యను కనిష్టీకరించడం నిర్వహించదగిన కోడ్ బేస్ సృష్టించడానికి సహాయపడుతుంది మరియు ప్రత్యేక ఆందోళనలకు సహాయపడుతుంది.
ఒక భాగం స్థితిని ఉంచాలా వద్దా అని మీరు నిర్ణయించలేకపోతే, తరువాత కోడింగ్ మరియు రీఫ్యాక్టరింగ్ కొనసాగించండి – సంక్లిష్టత (అందువలన రాష్ట్రం) ఎక్కడ సేకరిస్తుందో తెలుసుకోవడం మీ ప్రాజెక్ట్ జీవితచక్రంలో చాలా తొందరగా ఉంటుంది.