इसलिए हमने हाल ही में हमारी कंपनी में हमारे विशाल व्यापार वेब एप्लिकेशन के निर्माण के लिए फ्रंट-एंड तकनीक के रूप में प्रतिक्रिया व्यक्त की है। हाल ही में कहकर, मेरा मतलब है कि हमारे पास रिएक्ट के साथ कोई पिछला अनुभव नहीं है (हमारे पास एंगुलरजेएस की एक बड़ी पृष्ठभूमि है), और विशाल एप्लिकेशन कहकर, मेरा मतलब है कि यह बहुत बड़ा और बहुत सारे गतिशील और कार्यक्षमता के साथ बहुत गतिशील है।एक विशाल व्यापार अनुप्रयोग के लिए प्रतिक्रिया आर्किटेक्चर
क्योंकि हमारे पास बहुत सारे बड़े घटक होंगे जो सभी एक बहुत ही महत्वपूर्ण भूमिका निभाते हैं और उनके अंदर जटिल तर्क है, और क्योंकि हम चाहते हैं कि वे आसानी से प्लग करने योग्य और पुन: प्रयोज्य हों, हम चाहते हैं कि वे जितना संभव हो उतना अलग हो जाएं बाहरी दुनिया और हमारे आवेदन के अन्य हिस्सों, क्योंकि अन्यथा उनके आकार और जटिल कार्यक्षमता के कारण उन्हें विकसित करना और उन्हें बनाए रखना बहुत असंभव होगा। यही कारण है कि हमने कम से कम शुरुआत में रेडक्स का उपयोग न करने का फैसला किया है, जबकि हम केवल अलग-अलग घटकों को विकसित कर रहे हैं, क्योंकि यह घटक अलगाव से समझौता करता है और पूरे अनुप्रयोग डेटा प्रवाह तर्क को समझने में असंभव बनाता है जब बहुत जटिल होते हैं अवयव। हालांकि मुझे विश्वास है कि हमारी पसंद गलत हो सकती है, क्योंकि जैसा कि मैंने पहले ही उल्लेख किया है, हमें प्रतिक्रिया के साथ कोई अनुभव नहीं है।
जैसा कि मैंने पहले ही उल्लेख किया है, एप्लिकेशन बहुत गतिशील है। इसका मतलब है कि घटक वास्तव में डेटा द्वारा प्रस्तुत किए जाते हैं। हम विभिन्न कॉन्फ़िगरेशन प्रदाता कक्षाओं का उपयोग करते हैं जो हमारे एपीआई एंडपॉइंट्स के साथ हमारे अनुप्रयोग की कॉन्फ़िगरेशन के टुकड़े प्राप्त करने के लिए इंटरैक्ट करते हैं, जैसे नेविगेशन, पेज, विभिन्न रूपों, सूचियों आदि की कॉन्फ़िगरेशन, और फिर उस कॉन्फ़िगरेशन से पढ़े गए घटकों को प्रस्तुत करने का प्रयास करें।
समस्या कुछ हफ्तों के बाद प्रतिक्रिया के साथ गति प्राप्त करने के लिए संघर्ष कर रही है और सही समस्याओं और हमारी समस्याओं के सामान्य समाधानों की खोज करने के बाद, हम अपने चालक दल में बात कर रहे हैं, शायद प्रतिक्रिया सही तकनीक नहीं है हम, क्योंकि यह यूआई लाइब्रेरी है, घटना को ढांचा नहीं है, और यह हमें बहुत मदद नहीं करता है, लेकिन केवल अपने प्रतिपादन नियमों को जोड़ता है जिसे हमें गतिशीलता और घटक स्वतंत्रता प्राप्त करने के लिए कई बार तोड़ना पड़ता है।
घटक अलगाव और डेटा प्रवाह प्रबंधन को ध्यान में रखते हुए, मैंने व्यक्तिगत रूप से सुना है कि फ्रंट एंड डेवलपमेंट एल्म के लिए एक भाषा है जिसमें बहुत मजबूत डेटा प्रवाह आर्किटेक्चर है जहां प्रत्येक घटक का अपना मॉडल होता है जो दूसरों से अलग होता है, लेकिन मैं यह नहीं पता कि यह एक कोशिश के लायक है, क्योंकि यह हमारी बड़ी आवश्यकताओं के बहुत जल्द भी हो सकता है।
कारण मैं यहां इस प्रश्न को लिख रहा हूं कि मैं उन लोगों से अंतर्दृष्टि प्राप्त करने की आशा करता हूं जिनके पास विशाल फ्रंट-एंड अनुप्रयोगों के साथ काम करने पर ठोस पृष्ठभूमि है। मैं जानना चाहता हूं कि इस तरह के एक आवेदन को प्रतिक्रिया के साथ विकसित करना संभव है, भले ही प्रतिक्रिया ऐसी जटिलता और गतिशीलता के लिए उपयुक्त है, भले ही हमें वास्तव में रेडक्स या कुछ और चाहिए, क्या पथ, प्रथाओं, विचारधाराओं का पालन करना चाहिए। यदि आप मेरे प्रश्न को सही ढंग से समझते हैं, तो यह अधिक आर्किटेक्चर पक्ष है जिसे हम तकनीकी से तुलना में संघर्ष कर रहे हैं। हो सकता है कि हम सिर्फ उस रास्ते पर चल रहे हैं जो अधिक से अधिक संघर्ष और जटिलता की ओर जाता है लेकिन उत्पादन की ओर नहीं।
खुशी की संरचना तैयार करना है की देखभाल। 'रेडक्स' के बारे में बात करते हुए, मैंने इसके साथ एक गतिशील फॉर्म घटक लिखने की कोशिश की है और बहुत जल्द उलझन में आया है जब मुझे विभिन्न स्रोतों से राज्य में कॉन्फ़िगरेशन और डेटा फ़ीड करने की आवश्यकता होती है और फिर फॉर्म को सही तरीके से प्रस्तुत किया जाता है और इसके विभिन्न हिस्सों को सिंक में मिलता है । और उसके बाद सत्यापन भाग भी लात मारी, और फिर भिन्नता फ़ील्ड प्रकारों को बनाते हैं, जैसे स्वत: पूर्ण जो ऑनलाइन एपीआई से अपने विकल्पों को लोड करता है। हालांकि, मुझे अभी भी लगता है कि भ्रम की संभावना पुस्तकालय/ढांचे के अनुभव और ज्ञान की कमी के कारण हो सकती है। – Salivan