ReactJS फ्लक्स एप्लिकेशन निर्देशिका संरचना

Question

मेरी टीम वर्तमान में फेसबुक के फ्लक्स आर्किटेक्चर का उपयोग कर ReactJS में लिखे गए बड़े एप्लिकेशन पर काम कर रही है। यह अभी भी अपने बचपन में अभी भी है लेकिन यह बहुत जल्द बढ़ने जा रहा है। इसमें 50 से अधिक छोटे घटक दृश्य होंगे, बहुत सारे कार्य, स्टोर और कार्य-निर्माता होंगे।

वर्तमान में, हमारी निर्देशिका संरचना लगता है कि -

App 
|___ module_1 
| |___ components 
| | |___ component1.react.js 
| | |___ component2.react.js 
| |___ module1ActionCreators.js 
| |___ module1Constants.js 
| |___ module1store.js 
| 
|___ module_2 
    |___ ... (same structure as above) 

इस दृष्टिकोण के साथ समस्याओं में से एक यह है कि module_x फ़ोल्डर के रूप में इस अनुप्रयोग बढ़ता संख्या में बड़ी तेजी से हो जाएगा।

क्या किसी के पास यह साझा करने के लिए कुछ भी है कि उन्होंने अपने ऐप को कैसे संरचित किया? हमारे अनुभव में, फेसबुक के उदाहरण ऐप्स (टोडो और चैट) में छोटे ऐप्स के लिए एक आर्किटेक्चर उपयुक्त है, लेकिन एक बार उन स्टोर्स, घटकों और कार्यों में संख्या बढ़ने के बाद, प्रबंधन करना कठिन हो जाता है।

अग्रिम धन्यवाद।

Answer 1

सामान्य निर्देशिका संरचना अधिक इस तरह है:

 
js 
├── AppBootstrap.js 
├── AppConstants.js 
├── AppDispatcher.js 
├── actions 
│ ├── AppActions.js 
│ ├── FriendActions.js 
│   └── PhotoActions.js 
├── components 
│ ├── AppRoot.react.js 
│ ├── friends 
│ │ ├── Friend.react.js 
│ │ ├── FriendList.react.js 
│ │ └── FriendSection.react.js // a querying-view, AKA controller-view 
│ └── photos 
│  ├── Photo.react.js 
│  ├── PhotoCategoryCard.react.js 
│  ├── PhotoCategoryCardTitle.react.js 
│  ├── PhotoGrid.react.js 
│  └── PhotoSection.react.js // another querying-view 
├── stores 
│ ├── FriendStore.js 
│ ├── PhotoStore.js 
│ └── __tests__ 
│  ├── FriendStore-test.js 
│  └── PhotoStore-test.js 
└── utils 
    ├── AppWebAPIUtils.js 
   ├── FooUtils.js 
    └── __tests__ 
     ├── AppWebAPIUtils-test.js 
     └── FooUtils-test.js 

सीएसएस निर्देशिका आमतौर पर, घटकों निर्देशिका का एक दर्पण की तरह लग रहा घटक प्रति एक सीएसएस फ़ाइल के साथ। कुछ लोग इन दिनों घटक पर अपनी सभी स्टाइल इनलाइन करना पसंद करते हैं।

उन सभी को ओवरथिंक न करें - स्टोर और क्वेरीिंग-व्यू या "सेक्शन" के बीच हमेशा 1: 1 है, जैसा कि इस उदाहरण में है।

और वास्तव में आपको केवल अपने ऐप के लिए सही करने की आवश्यकता है। यह मतभेद नहीं है। डेटा प्रवाह सामग्री, नियंत्रण में उलटा और दुकानों का decoupling - यह आपकी फ़ाइलों को व्यवस्थित करने के तरीके से कहीं अधिक महत्वपूर्ण विचार हैं।

Answer 2

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

एक के लिए, यदि आप ब्रोस्वरिफा जैसे कुछ का उपयोग कर रहे हैं, तो आपकी आवश्यकता कॉल पर सापेक्ष पथिंग सुंदर है। दूसरा, जब आप एक विशेष घटक पर काम कर रहे हों तो विभिन्न फ़ोल्डरों में फ़ाइलों को शिकार करने की ज़रूरत नहीं है, यह एक बड़ा समय बचाने वाला है।

प्रेषक, सहायक कार्य, बूटस्ट्रैपर आदि जैसे क्रॉस कटिंग चिंताओं के लिए, मेरे पास समकक्ष ऐप मॉड्यूल है। यह हमेशा ऐसा लगता है कि प्रत्येक फ़ाइल के लिए एक समझदार जगह है जिसके साथ मैं काम कर रहा हूं, और नए देव सहसंबंधित फ़ाइलों को खोजने के लिए संघर्ष नहीं करते हैं (समस्याग्रस्त जब आपके मॉड्यूल उपसर्ग साझा कर सकते हैं)।

स्विचिंग के बाद से मैंने पीछे नहीं देखा है।