Redux: कंटेनर बनाम घटक?

• कंटेनर अवयव
• स्मार्ट और गूंगा घटक

मेरे लिए, container मार्ग का हैंडलर है, जो उस मार्ग के लिए रेडक्स की स्थिति को भी खींचता है। फिर मैं अपने राज्य को सहारा के रूप में पास करता हूं।

उदाहरण के लिए,

कंटेनर/गुण.jsx

import React, { Component } from 'react';
import { bindActionCreators } from 'redux';
import { connect }  from 'react-redux';

import * as actions from 'actions/properties';
import Filter from 'components/properties/filter';
import List from 'components/properties/list';
import Pagination from 'components/properties/pagination';

class PropertiesContainer extends Component {
  render() {
    return (
      <section>
        <Filter filter={this.props.properties.params.filter} />
        <List items={this.props.properties.items} isFetching={this.props.properties.isFetching} />
        <Pagination pagination={this.props.properties.params.pagination} />
      </section>
    );
  }
}

function mapState(state) {
  const { properties } = state;

  return { properties };
}

function mapDispatch(dispatch) {
  return {
    actions: bindActionCreators(actions, dispatch),
  };
}

const Connector = connect(mapState, mapDispatch)(PropertiesContainer);

export default Connector;

और, उदाहरण के लिए,

घटक/गुण/पेजिनेशन.jsx

import React, { Component } from 'react';
import Pager from 'components/ui/pager';

class Pagination extends Component {
  render() {
    const { total, offset, limit } = this.props.pagination;
    const current = offset / limit;

    return (
      <Pager total={total} current={current} />
    )
  }
}

export default Pagination;

आपके द्वारा प्रदान किए गए लिंक से पढ़ना:

"A container does data fetching and then renders its corresponding sub-component. "

मुझे और अधिक महसूस होता है कि "कंटेनर" वास्तव में रेडक्स में "स्मार्ट घटक" कहलाते हैं ... और मार्गों/पृष्ठों को अपना स्वयं का फ़ोल्डर मिलना चाहिए।

मुझे यकीन नहीं है कि "कंटेनर" और "रूट हैंडलर" किसी भी तरह से संबंधित क्यों हैं?

अपने ऐप के घटकों को मार्ग के आधार पर समूहित करना एक बहुत ही सामान्य प्रथा है। जैसा कि @theaqua ने बताया, प्रत्येक रूट हैंडलर/घटक को स्मार्ट/कंटेनर घटक बनाना भी आम है। यदि आप CombReducers का उपयोग कर रहे हैं, तो आप अक्सर अपने आप को एक ही तर्ज पर राज्य, मार्गों और कंटेनरों को तोड़ते हुए पाएंगे। इसलिए, वे अक्सर एक साथ जुड़ जाते हैं।

@ronag मुझे नहीं लगता था कि आपको कंटेनर और पेज बनाने की ज़रूरत है। आप रूट हैंडलर और रेडक्स कनेक्टर को राज्य में 1 स्थान पर क्यों नहीं रख सकते हैं? यह बहुत आसान है। इसे सरल रखें।

मेरे आवेदन में मेरे पास केवल 3 मार्ग/पृष्ठ हैं। दूसरी ओर मेरे पास बहुत से स्वतंत्र पैनल/मॉड्यूल हैं। एक विशाल connect बनाना संभव नहीं है मुझे कम से कम इसे पैनलों के संदर्भ में विभाजित करने की आवश्यकता है।

अगर मैं राज्य से लेकर प्रॉप्स तक की सभी मैपिंग करता हूं और एक ही फाइल में लाने वाले सभी डेटा को बनाए नहीं रखा जा सकता है। खासकर अगर मैं एक ही स्थान पर लाने वाले सभी डेटा करता हूं।

यदि आपके पास 3 मार्ग हैं, तो आपको 3 मार्ग संचालकों की आवश्यकता है। उदाहरण के लिए, A.jsx , B.jsx और C.jsx में /containers ।

प्रत्येक कंटेनर में आप redux स्थिति का हिस्सा (संपूर्ण नहीं!) खींचते हैं और क्रियाएं बांधती हैं। फिर आप इसे मेरे उदाहरण जैसे घटकों को पास करते हैं। यह बहुत ही रखरखाव योग्य है, क्योंकि मैं (और मेरी टीम) जानता हूं - रेडक्स से कनेक्ट करें और क्रियाएं हमेशा containers में बांधती हैं, यह कभी भी components में नहीं होगी (जो मेरे उदाहरण में छोटा और अक्सर स्टेटलेस है )

मुझे लगता है कि मैं आपका सुझाव समझता हूं। हालाँकि, जैसा कि मैंने कहा कि वे 3 फाइलें बहुत जटिल हो जाएंगी यदि मैं अपना सारा डेटा वहां लाने में लगा दूं। हमारे कारण में यह मूल रूप से "लॉगिन, ऐप, लॉगआउट" होगा जहां ऐप में लगभग सब कुछ होगा।

हो सकता है कि मैं Relay बहुत अधिक पक्षपाती हूं जहां प्रत्येक घटक में एक कंटेनर होता है जो बताता है कि कौन सा डेटा लाना है और इसे कैसे दिखना चाहिए।

मैं आपके सुझाव का प्रयास करूंगा और देखूंगा कि हम कहां समाप्त होते हैं।

मैं components इनकैप्सुलेटेड रिएक्ट घटकों को कॉल करता हूं जो पूरी तरह से प्रॉप्स द्वारा संचालित होते हैं और Redux से बात नहीं करते हैं। "गूंगा घटकों" के समान। आपके राउटर, डेटा लाने वाली लाइब्रेरी आदि की परवाह किए बिना उन्हें वही रहना चाहिए।

मैं containers रिएक्ट घटकों को कॉल करता हूं जो Redux, राउटर आदि के बारे में जानते हैं। वे ऐप के साथ अधिक युग्मित हैं। "स्मार्ट घटकों" के समान।

@gaearon : बिल्कुल सही। यह उदाहरणों को स्पष्ट करता है। धन्यवाद।

@gaearon तो "गूंगा घटक" स्टेटलेस घटक हैं, जिन्हें एक सरल वाक्यविन्यास में लिखा जा सकता है

var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

क्या मैं सही हूँ?

@soulmachine हाँ।

जरूरी नही। सिंटैक्स बिंदु नहीं है।

"गूंगा" घटक उर्फ ​​"प्रेजेंटेशनल" घटक ऐसे घटक हैं जो प्रॉप्स द्वारा सभी डेटा प्राप्त करते हैं, Redux से अवगत नहीं हैं, और केवल उपस्थिति निर्दिष्ट करते हैं लेकिन व्यवहार नहीं।

@theaqua @gaearon धन्यवाद!

यद्यपि "कंटेनर" शब्द पहले से ही प्रतिक्रिया/रेडक्स नामकरण में काफी लोकप्रिय है, हमने लेआउट/ग्राफिकल कंटेनरों के साथ किसी भी भ्रम से बचने के लिए, जिस प्रोजेक्ट पर मैं काम कर रहा हूं, उसमें हमने उन्हें "कनेक्टर्स" कहने का फैसला किया।

बीटीडब्ल्यू, उन्हें कैसे कॉल करें, पहले यहां चर्चा की गई थी रैकेट/रिएक्शन-रेडक्स # 170। मैं सब कुछ एक components फ़ोल्डर के अंदर रखता हूं और प्रेजेंटेशनल एक स्तर गहरा, components/presentational अंदर, और मुझे लगता है कि यह ठीक है क्योंकि कंटेनर के अलावा ऐप के कुछ हिस्सों द्वारा उनकी आवश्यकता होने की संभावना नहीं है।

@gaearon तो एक घटक है कि dispatch को "गूंगा" या "स्मार्ट" माना जाता है? प्रेषण करने के लिए घटना को वापस शीर्ष घटक पर बबल करने के बजाय कार्रवाई भेजने के लिए एक पत्ता या मध्यवर्ती घटक होना विशेष रूप से उपयोगी होता है।

हाँ, यह कभी-कभी उपयोगी हो सकता है, हालांकि मैं ऐसे घटकों को connect() पसंद करता हूं, इसलिए एक्शन क्रिएटर को एक प्रोप के रूप में इंजेक्ट किया जाता है। इससे कोई फर्क नहीं पड़ता कि आप इसे कैसे कहते हैं :-)

जब आप घटकों का एक मॉड्यूल बना रहे हों तो क्या होगा? उदाहरण के लिए, मान लीजिए मेरे पास हमारे नेविगेशन मेनू <NavMenu> लिए एक अलग नोड मॉड्यूल है, मैं चाहता हूं कि लोग इस तरह कोड करें:

import {NavMenu} from 'my-redux-aware-components';

export function myPage(props) {
  return (<div><NavMenu routes={props.routes} /></div>);
}

तो क्या मैं इसे सिर्फ 'NavMenuContainer' नाम दूं? यह मुझे अजीब लगता है। क्या मुझे इसके बजाय घटक NavMenuComponent का नाम देना चाहिए? दोनों मुझे अजीब लगते हैं। इस मामले में घटक केवल राज्य से 1 फ़ील्ड प्राप्त करने के लिए कनेक्ट को कॉल करता है। क्या इस तरह कनेक्ट होने के लिए कॉल को इनलाइन करना वाकई इतना बुरा है?

export default const NavMenu = connect(state => ({currentPath:state.routing.path})(React.createClas({...}));

आपके विचार सुनने के लिए उत्सुक @gaearon कब (यदि बिल्कुल भी) कनेक्ट कॉल को इनलाइन करना "ठीक" है ...

कोई फर्क नहीं पड़ता कि आप इसे कैसे कहते हैं। इसे NavMenu क्यों नहीं कहते?

मैं इनलाइनिंग के बारे में सवाल नहीं समझता।
यदि आप तुलना कर रहे दो दृष्टिकोण प्रस्तुत करते हैं तो इससे मदद मिलेगी।

ठीक है तो उदाहरण के लिए।
विकल्प 1 (२ अलग फाइलें, कंटेनर के लिए १, घटक के लिए १)

कंटेनर/नवमेनू

import {connect} from 'react-redux';
import NavMenu from '../components/NavMenu';

export default connect(state => ({currentPath:state.routing.path})(NavMenu);

विकल्प 2 (दोनों वाली एक एकल फ़ाइल):
घटक/नवमेनूMe

import {connect} from 'react-redux';

export default connect(state => ({currentPath:state.routing.path})(React.createClass({
  render() {
      return <div>the menu {this.props.currentPath} goes here</div>;
  }
});

इनलाइनिंग से मेरा मतलब है कि केवल एक फ़ाइल (2 फाइलों के विपरीत) है जो कंटेनर और घटक दोनों है क्योंकि राज्य से आवश्यक वर्तमान पथ के बारे में केवल 1 छोटा सा है। क्या यह केवल कुछ ऐसा है जिसे हमेशा टाला जाना चाहिए या क्या इस तरह के साधारण मामलों में ऐसा करना उचित है?

निश्चित रूप से, साधारण मामलों में ऐसा करना उचित है।

अच्छा ठीक है। आप रेखा कब खींचेंगे और कहेंगे "ठीक है, मैं इसे 2 अलग-अलग फाइलों में स्थानांतरित कर दूंगा"?

जब घटक प्रस्तुति के साथ डेटा चिंताओं (डेटा को पुनर्प्राप्त/गणना कैसे करें, कार्यों को कैसे प्रेषित करें) को मिश्रित करना शुरू कर देता है (यह कैसा दिखता है)। जब विभिन्न संदर्भों में परीक्षण या पुन: उपयोग करना कठिन हो जाता है।

@benmonro एक और विचार। यदि आप घटकों का एक मॉड्यूल बना रहे हैं, तो आप कभी-कभी इन घटकों को अपने ऐप के स्टेट ट्री के विभिन्न हिस्सों से जोड़ना चाहेंगे, या विभिन्न राज्यों के साथ अलग-अलग उनकी प्रस्तुति का परीक्षण करना चाहेंगे। इस मामले में, घटकों के इस मॉड्यूल के अंदर connect होने से यह क्षमता सीमित हो जाएगी।

धन्यवाद @gaearon

@sompylasar बहुत अच्छी बात है! धन्यवाद

हम्म ठीक है इसे विभाजित करने के लिए इसे दोबारा करने के लिए मेरे कोड के माध्यम से जाने के बाद, अब मेरे पास एक अनुवर्ती प्रश्न है। मान लीजिए कि मेरे पास <NavMenuItem> कंटेनर भी है। <NavMenu> घटक को <NavMenuItem /> को चाइल्ड एलिमेंट के रूप में संदर्भित करने की आवश्यकता है। क्या मुझे नवमेनू घटक में सिर्फ import NavMenuItem from '../containers/NavMenuItem' करना चाहिए? यह टेस्टेबिलिटी @sompylasar को कैसे प्रभावित करता है?

मैं NavMenuItem को एक शुद्ध प्रस्तुतिकरण घटक बनाऊंगा जिसमें सभी आवश्यक डेटा NavMenu द्वारा प्रॉप्स के माध्यम से पास किए जाएंगे। यह इसे अलग से परीक्षण करने की अनुमति देगा। तो, आपके पास दो प्रेजेंटेशनल (NavMenu, NavMenuItem) और एक कनेक्टेड (connect(...)(NavMenuItem) ) कंपोनेंट होगा।

इस चर्चा में एक बात मुझे याद आ रही है: जब आपके पास उन्हें एक फ़ाइल में रखा जाता है, तो आप परीक्षण के लिए उथले प्रतिपादन का उपयोग नहीं कर सकते। मैंने देखा है कि लोग इसके आसपास काम करने के लिए प्रेजेंटेशनल कंपोनेंट और कंटेनर कंपोनेंट दोनों का पर्दाफाश करते हैं, और फिर अलग-अलग टेस्ट करते हैं, इसलिए इस मामले में मेरे पास यह स्पष्ट करने के लिए दो फाइलें होंगी कि ये दो चीजें हैं। यह यहां चिंताओं को अलग करने और इस तथ्य पर भी प्रकाश डालता है कि प्रस्तुतिकरण घटक स्वतंत्र और पुन: प्रयोज्य है।

एफडब्ल्यूआईडब्ल्यू मैंने अपनी वर्तमान सोच को दर्शाने के लिए प्रेजेंटेशनल और कंटेनर कंपोनेंट्स आलेख को अपडेट किया।

हम अब अपडेट किए गए दस्तावेज़ों में कंटेनर घटक बनाने को हतोत्साहित नहीं करते हैं.
http://redux.js.org/docs/basics/UsageWithReact.html

Redux doc में आपके वास्तविक उदाहरण में @gaearon ऐसा लगता है कि घटकों में बच्चे के रूप में कंटेनर हो सकते हैं।
क्या मै गलत हु? यह एक गूंगा घटक की टेस्टेबिलिटी को कैसे प्रभावित कर सकता है जो इसके अंदर एक स्मार्ट प्रस्तुत करता है?
हालांकि मुझे पदानुक्रम में घटकों को नवीनतम होने का तरीका नहीं मिल रहा है ...

मेरे पास एक ऐप है जो एक साधारण डेटा सूची घटक (गूंगा) प्रस्तुत करता है।
इसके अंदर हर वस्तु को स्टोर से जोड़ना होता है, इसलिए यह एक स्मार्ट है।

डॉक्टर के अनुसार यह ठीक है, लेकिन क्या यह कुछ समस्या ला सकता है?

धन्यवाद!

यह एक गूंगा घटक की टेस्टेबिलिटी को कैसे प्रभावित कर सकता है जो इसके अंदर एक स्मार्ट प्रस्तुत करता है?

यह सेट अप करने के लिए परीक्षण को थोड़ा कठिन बना देता है (आपको स्टोर को भी प्रारंभ करने की आवश्यकता है)। जब यह एक असुविधा होती है, तो अधिक प्रस्तुतिकरण घटकों को निकालें जो children स्वीकार करते हैं ताकि आप कंटेनर घटकों को अंदर पास कर सकें। सामान्य तौर पर, विभाजन आप पर निर्भर करता है, और आपको ट्रेडऑफ़ (लेखन में आसानी, रिफैक्टरिंग, परीक्षण, आदि) का मूल्यांकन करने और अपने लिए घटकों को अलग करने का तरीका चुनने की आवश्यकता होती है।

ठीक है, तो कोई सही तरीका नहीं है। हमें मामले दर मामले का मूल्यांकन करना होगा.. कई
धन्यवाद!!

Il lunedì 8 फरवरी 2016, डैन अब्रामोव नोटिफिकेशन @github.com हा
स्क्रिटो:

यह एक गूंगा घटक की परीक्षण क्षमता को कैसे प्रभावित कर सकता है जो इसके अंदर प्रस्तुत करता है
एक स्मार्ट?

यह सेट अप करने के लिए परीक्षण को थोड़ा कठिन बना देता है (आपको प्रारंभ करने की आवश्यकता है
दुकान भी)। जब यह असुविधा हो, तो और निकालें
प्रस्तुति घटक जो बच्चों को स्वीकार करते हैं ताकि आप कंटेनर पास कर सकें
अंदर के घटक। सामान्य तौर पर, विभाजन आप पर निर्भर है, और आपको करने की आवश्यकता है
ट्रेडऑफ़ का मूल्यांकन करें (लेखन में आसानी, रिफैक्टरिंग, परीक्षण, आदि), और
अपने लिए घटकों को अलग करने का तरीका चुनें।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/rackt/redux/issues/756#issuecomment -181143304।

लुका कर्नलो
+39 345 8948718
लुका [email protected]

'लेआउट घटकों' के बारे में क्या? मेरा मतलब है कि जब आपके पास कई कंटेनर होते हैं जिन्हें राउटर/नेविगेटर को पास करने के लिए एक घटक में होने की आवश्यकता होती है, तो यह रैपिंग घटक 'कंटेनरों का गूंगा प्रस्तुतिकरण कंटेनर' होगा?

@ Emilios1995 मेरे पास एक ही मुद्दा है ...
मेरे पास एक पृष्ठ घटक है जो लेआउट घटक के अंदर उपयोग करता है।
इस लेआउट घटक में मेनू, शीर्षलेख, पाद लेख हैं .. सामग्री पृष्ठ द्वारा लेआउट में पारित किया गया बच्चा है ..
मेनू और हेडर कंटेनर हैं !! तो लेआउट संभावित रूप से एक कंटेनर है, लेकिन स्टोर से कनेक्ट नहीं है..

हालांकि, अगर मैं मेनू और हेडर को लेआउट में पास करने का प्रयास करता हूं, तो मेरे पास एक पृष्ठ (कंटेनर) है जो लेआउट (घटक) प्रस्तुत करता है और इसे मेनू और हेडर (कंटेनर) में भेजता है।

ऐसा करना पदानुक्रम सही है, लेकिन मुझे प्रत्येक पृष्ठ में मेनू और शीर्षलेख दोहराना है, और उनमें से प्रत्येक मेरे लिए प्रत्येक पृष्ठ में समान हैं ..

@LucaColonnello मैं कोड के बिना इस मुद्दे को बिल्कुल समझ नहीं

यथाशीघ्र

इल सबाटो 27 फरवरी 2016, डैन अब्रामोव नोटिफिकेशन @github.com हा
स्क्रिटो:

@LucaColonnello https://github.com/LucaColonnello मैं काफी नहीं हूं
कोड के बिना समस्या को समझें। क्या मैं आपसे a . बनाने के लिए कह सकता हूँ
आपकी समस्या को दर्शाने वाले एक साधारण उदाहरण के साथ StackOverflow प्रश्न? मैं हो
देखने के लिए खुश रहो।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/756#issuecomment -189672067।

लुका कर्नलो
+39 345 8948718
लुका [email protected]

@gaearon यह कोई मुद्दा नहीं है, मुझे लगता है कि यह एक सवाल है जो मैंने यहां बनाया है: http://stackoverflow.com/questions/35729025/ should-the-route-handlers-use-containers-or-presentational-components ? noredirect=1#comment59133192_35729025

मुझे लगता है कि माध्यम पर डैन का लेख
https://medium.com/@dan_abramov/smart -and-dumb-components-7ca2f9a7c7d0#.3y00gw1mq
सभी मुद्दों को स्पष्ट करता है...

२०१६-०३-०१ १८:१९ जीएमटी+०१:०० एमिलियो स्रौगो नोटिफिकेशन @github.com

@gaearon https://github.com/gaearon यह कोई मुद्दा नहीं है, मुझे लगता है कि यह है
बल्कि एक प्रश्न जो मैंने यहाँ बनाया है:
http://stackoverflow.com/questions/35729025/ should-the-route-handlers-use-containers-or-presentational-components?noredirect=1#comment59133192_35729025

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/reactjs/redux/issues/756#issuecomment-190820426 ।

लुका कर्नलो
+39 345 8948718
लुका [email protected]

@gaearon मुझे आश्चर्य है कि यदि एक प्रेजेंटेशनल घटक में कंटेनर घटक हो सकते हैं, तो इसे पुन: प्रयोज्य कैसे किया जा सकता है?
एफवाईआई:

• https://medium.com/@lars.jagare/pure -components-ftw-63e6e6c733f0#.yw9hmwjuq
• https://medium.com/@rpominov/how -does-this-work-when-we-use-containers-inside-presentational-components-cb458e818913#.rnxlghull

मुझे आश्चर्य है कि यदि एक प्रस्तुतिकरण घटक में कंटेनर घटक हो सकते हैं, तो इसे पुन: प्रयोज्य कैसे किया जा सकता है?

यदि इसके सभी उपयोग परिदृश्यों में एक विशिष्ट कंटेनर शामिल है, तो मुझे नहीं लगता कि इसके बारे में पुन: प्रयोज्य नहीं है। और यदि नहीं, तो इसे this.props.children स्वीकार करें और अन्य प्रस्तुतिकरण घटक बनाएं जो विशिष्ट कंटेनर या प्रस्तुतिकरण घटकों को अंदर से पास करें।

@gaearon प्रतिक्रिया-राउटर पर [रूट घटक] कंटेनर घटक है?

• मार्ग.जेएस

<Route path="/" component={Root}>
      <IndexRoute component={Main} />
      <Route path="/account/signIn" component={SignIn} />
</Route>

• root.js

export default class Root extends React.Component {
  render() {
    return (
      <div>
        <div id="container" className="container">
          {this.props.children}
        </div>
      </div>
    );
  }

धन्यवाद।

@gaearon ऊपर आपने कहा था कि आप प्रेषण तक पहुंच प्राप्त करने के लिए घटकों को कनेक्ट करना पसंद करते हैं (जैसा कि इसे मूल घटकों से नीचे पारित करने के विपरीत)।

यदि आप इन घटकों को जोड़ते हैं, और उनके पास प्रॉप्स भी हैं जो _could_ को रेड्यूसर से मैप किया जा सकता है जो वर्तमान में माता-पिता द्वारा पारित किया जा रहा है, तो क्या आप इन्हें connect से आने के लिए रिफैक्टर करेंगे? या माता-पिता द्वारा पारित रखने के लिए ownProps का उपयोग करें।

क्या दो विकल्पों के बीच कोई कार्यात्मक/प्रदर्शन अंतर है?

मुझे विशाल रेडक्स परियोजनाओं के साथ काम करने का ज्यादा अनुभव नहीं है लेकिन मैं प्रतिक्रिया/रेडक्स फ़ाइल संरचनाओं को अनुकूलित करने के बारे में बहुत कुछ शोध और सोच रहा हूं। मुझे बताएं कि क्या इसका कोई मतलब है या नहीं:

src/
  components/
    header/ 
      navigation.js # nav menu list
      index.js # Header component
  modules/
    header/
      actions.js # header actions (sticky scroll, collapse mobile menu, etc...)
      reducer.js # header actions reducer (export to modules index)
      index.js # HeaderContainer (connect to Header component)
    index.js # combineReducers and export default configureStore (and middleware)

एक और अवधारणा:

src/
  components/
    navigation.js
    logo.js
    link.js
    list.js
    item.js
  modules/
    header/
      actions.js # header actions 
      wrapper.js # header class (smart) component - to wrap header with functionality (was previously classified as container)
      container.js # header functional (dumb) component - to contain universal components
      index.js # header actions reducer - to export into modules rootReducer 

या घटकों, कंटेनरों और रेडक्स मॉड्यूल को अलग रखना बेहतर है (भले ही वे एक ही नाम साझा करते हों)? किसी भी इनपुट के लिए धन्यवाद।

मैंने एंटरप्राइज़ स्तर की प्रतिक्रिया-रेडक्स परियोजनाओं के साथ काम किया है और अपने अनुभव के माध्यम से, मैं एक बात कह सकता हूं कि यह पूरी तरह से आप पर निर्भर करता है कि आप अपने प्रोजेक्ट के आर्किटेक्चर को कैसे परिभाषित करते हैं। मैं किसी भी कंटेनर/घटक आधारित वास्तुशिल्प विविधताओं का पालन नहीं करता क्योंकि वे इस अर्थ में अव्यावहारिक हैं कि रिएक्ट का उद्देश्य पुन: प्रयोज्य घटकों को यूआई बनाना है।

इसलिए मैं मॉड्यूल के आधार पर संपूर्ण परियोजनाओं को समूहीकृत करने का एक सरल दृष्टिकोण लेकर आया हूं और इसने अब तक स्केलेबिलिटी, रखरखाव और कोड पठनीयता के मामले में वास्तव में अच्छा काम किया है।

मेरे लिए, कंटेनर और स्मार्ट-घटक बिल्कुल समान हैं। सरल परिभाषा है:
एक कंटेनर/स्मार्ट-घटक वह है जिसमें जेएसएक्स मार्कअप + इवेंट हैंडलर + एपीआई कॉल + रेडक्स का कनेक्ट/एमएसटीपी/एमएसडीपी होता है।
एक गूंगा घटक विशुद्ध रूप से प्रस्तुतिकरण, कार्यात्मक घटक है।