<p>डीवीए 2.0</p>

कैसे ts के लिए देशी समर्थन के बारे में?

अनमॉडलिंग करते समय, क्या आप अप्रयुक्त राज्य डेटा को नष्ट करने के लिए एक रेड्यूसर पास करने का समर्थन करने पर विचार करते हैं? https://github.com/dvajs/dva/issues/769

कैसे डीवा-क्ली का नाम बदलकर रोडहोग कर दिया गया? ऐसा न हो कि अवधारणा भ्रमित हो।

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

ऐसी अनुकूलन योजनाएं भी हैं जिन्हें प्लग-इन के रूप में भी समर्थित किया जा सकता है, जैसे dva.use(reselect) , एक्सप्रेस मिडलवेयर तंत्र की तरह, केवल स्थिर प्लग-इन अंतर्निहित हैं, और अन्य अलग से समर्थित हैं , और गाथा भी उपलब्ध हो सकती है

@nihgwu मैं गलत था, जिसका अर्थ है कि,

मैं प्लग-इन समाधान से सहमत हूं, क्या ऐसा करना संभव है:

view - dva-core - [插件]

उनमें से, वर्तमान dva के बराबर भाग है:

• डीवा-कोर
• द्वा-सागा
• रूटर

अंतिम दो प्लगइन्स हैं।

क्या डीवीए को एक पुस्तकालय के रूप में तैनात किया जा सकता है जो विचारों और डेटा के बीच संबंधों को व्यक्त करने पर केंद्रित है? दृश्य किस प्रकार का ढांचा है, और डेटा स्रोत कौन सी विधि है, सभी को बदलने योग्य बनाया गया है? फिर, 1.0 के साथ सुचारू रूप से अपग्रेड करने के लिए, dva को dva-core और saga के डिफ़ॉल्ट संयोजन के रूप में परिभाषित करें?

मुझे नहीं पता कि अंतर्निहित इनकैप्सुलेशन इंस्टेंस प्रकार के प्रेषण प्रकार का समर्थन करने के लिए सुविधाजनक है या नहीं?

dispatch({
  type: model => model.product.loadAll,
})

याद रखने वाली स्ट्रिंग भी परेशानी होती है, और अक्सर नामस्थान लिखना भूल जाते हैं, यदि ड्रॉप-डाउन प्रॉम्प्ट है, तो पुनर्निर्माण करना भी सुविधाजनक है~

मुझे नहीं पता कि क्या राज्य के सभी डेटा के लिए डिफ़ॉल्ट रूप से रिड्यूसर का एक सेट प्रदान करना संभव है
अधिकांश परिदृश्यों में, मुझे मैन्युअल रूप से एक रेड्यूसर लिखने की आवश्यकता होती है, जो केवल एक फ़ील्ड के लिए एक मान निर्दिष्ट कर सकता है, इसलिए यदि मैं डिफ़ॉल्ट रूप से मेरे लिए एक तैयार एकल-फ़ील्ड सेट विधि प्रदान कर सकता हूं, तो यह काफी अच्छा होगा।

क्या रेड्यूसर को एक पेड़ के रूप में लागू किया जा सकता है? अब की तरह, एनएस स्प्लिट को तर्क को समतल करने के लिए मजबूर किया जाता है। एक मॉडल एक रेड्यूसर की जड़ से मेल खाता है, और नीचे बहुत सारे रेड्यूसर लटक रहे हैं।

@xufei मुझे लगता है कि गाथा मूल में होनी चाहिए, और यह गाथा के dva नहीं है। ऐसा लगता है कि कार्यान्वयन के दृष्टिकोण से गाथा को प्लग-इन में निकालना मुश्किल है।

@xufei मुझे क्षमा करें, मुझे यह भी लगा कि आपको ts में लिखने की बात करनी चाहिए, लेकिन मुझे नहीं लगता कि यह आवश्यक है। आखिरकार, dva का इंटरफ़ेस भी सरल है, और इसे ts के साथ फिर से नहीं लिखा जा सकता है क्योंकि फाइलें टाइप करें।

@sorrycc अलग गाथा मैं एक उदाहरण भी देता हूं। यह सच है कि dva का मूल redux + redux-saga है, लेकिन कार्यान्वयन के दृष्टिकोण से, हम इसे कॉलबैक हुक के माध्यम से प्लग-इन में अलग कर सकते हैं।

क्या अपरिवर्तनीय.जेएस का समर्थन किया जा सकता है?

प्रदर्शन अनुकूलन में Immutable.js का समर्थन करें, Immutable.js की प्रमुख भूमिका है

रोडहोग पैकेजिंग बहुत अधिक प्रदर्शन-खपत है। देखें कि क्या आप इसे अनुकूलित कर सकते हैं। यदि आप कर सकते हैं, तो इसे जितना संभव हो उतना अनुकूलित करें। अब आपको सर्वर द्वारा प्रोजेक्ट बनाने से पहले अन्य कंटेनरों को रोकना होगा, अन्यथा सर्वर अटक जाएगा।

Immutable.js को हटा दिया गया है। लॉश और स्प्रेड ऑपरेशंस का संयोजन भी अपरिवर्तनीय प्रभाव प्राप्त कर सकता है। और लॉश मूल रूप से बिल्ट-इन है।

वास्तव में, dva 1.x का विकास अनुभव पहले से ही बहुत अच्छा है, जैसे कि Immutable.js, स्प्लिट सागा, देशी समर्थन ts का समर्थन करना है, यह अनावश्यक लगता है, सभी डेवलपर के आत्म-प्रेमी हैं, और यह बहुत अधिक नहीं है वास्तविक विकास दक्षता और अनुभव के लिए। प्रभाव।

व्यक्तिगत रूप से, 4 बिंदु हैं जिन पर dva 2.x द्वारा विचार करने की आवश्यकता है:

1. सेवा परत का अनुकूलन, चाहे इसे मॉडल में निकाला जा सकता है, और एकीकृत तरीके से पैक किया जा सकता है, मूल रूप से request परवाह नहीं करता है, और फिर डिफ़ॉल्ट रूप से नेटवर्क अपवाद हैंडलिंग प्रदान करता है, और अब मूल रूप से आपको इसकी आवश्यकता है अपने आप से request.js लिखने के लिए;

2. यह दृश्य परत के प्रभाव कॉलबैक की समस्या है। व्यावसायिक तर्क को मॉडल डेटा में पूरी तरह से अलग करना और इसे प्रभाव में संसाधित करना अवास्तविक (बहुत बोझिल) है, इसलिए इस क्षेत्र में अधिक सुरुचिपूर्ण समाधान की आवश्यकता है।

3. यह dva के आसपास के समुदायों का निर्माण है। वर्तमान में, मचान के प्रकार उदाहरणों में समृद्ध हैं, लेकिन अधिक निर्माण की आवश्यकता है। ऐसा लगता है कि लक्ष्य कोणीय के संसाधन स्तर तक पहुंचना या समुदाय को ही प्रतिक्रिया देना है।

4. बिल्ड टूल्स, प्रदर्शन, फ़ंक्शंस इत्यादि (वर्तमान में नकली) की वृद्धि अभी भी थोड़ी परेशानी है

मेरे लिए, जो चीज मुझे सबसे ज्यादा चिंतित करती है वह है router का अलगाव। मुझे लगता है कि dva केवल redux + redux-saga शामिल करने की आवश्यकता है। redux समुदाय जितना संभव हो उतना कम करने की वकालत करता है, इसलिए 1.x पैकेजिंग react-router और fetch अनावश्यक महसूस करते हैं, साथ ही ऊपर उल्लिखित Immutable । यह डेवलपर की वरीयता के अंतर्गत आता है। एक अनुरक्षक के रूप में, यह झुकाव नहीं होना चाहिए। डेवलपर की वरीयता के लिए, इसे प्लग-इन के रूप में समर्थित किया जा सकता है। सेवा परत की समस्या भी है। यदि आवश्यक हो तो , आप स्वयं plugin लिख सकते हैं, इसे dva-core में शामिल नहीं किया जाना चाहिए

@nihgwu राउटर निकालने का उद्देश्य क्या है?

@nikogu ने बहुत कुछ किया है, और नौसिखियों को नुकसान होगा, पता नहीं सिद्धांत क्या है।लेकिन अगर डॉक्टर विस्तृत है, तो यह भी संभव है

राउटर को हटाने का उद्देश्य क्या है

@निकोगु

वर्तमान में, डीवीए का आवेदन दायरा थोड़ा संकीर्ण है, और यह प्रतिक्रिया समुदाय से दृढ़ता से जुड़ा हुआ है, स्वाभाविक रूप से दृश्य सहित, और प्रतिक्रिया-राउटर से भी दृढ़ता से जुड़ा हुआ है। लेकिन इसका उपयोग करने के बाद, मैंने पाया कि कुछ जगहों पर राउटर की आवश्यकता नहीं है, जैसे वायरलेस मल्टी-पेज एप्लिकेशन; कुछ जगहों पर प्रतिक्रिया-राउटर लागू नहीं होता है, जैसे प्रतिक्रिया-मूल; कुछ जगहों पर प्रतिक्रिया की आवश्यकता नहीं होती है, जैसे नोड , इलेक्ट्रॉन और एप्लेट्स।

मुझे लगता है कि डीवीए और अधिक कर सकता है।

@nikogu राउटर से दूर हो जाता है क्योंकि हमारे पास अलग-अलग राउटर हो सकते हैं। उदाहरण के लिए, आरएन में, मैं प्रतिक्रिया-नेविगेशन का उपयोग कर सकता हूं, और प्रतिक्रिया-नेविगेशन भी वेब का समर्थन करता है, जिसे बेहतर अनुकूलन प्राप्त करने के लिए प्लगइन द्वारा पूरी तरह से समर्थित किया जा सकता है

मैं समझता हूं कि डीवीए वेब विकास ढांचे का एक पूरा सेट प्रदान करने के बजाय एक नए रूप में रेडक्स और सागा कोड और तर्क का आयोजन करता है, जैसे एक्सप्रेस, जो वेब सर्वर के बुनियादी कार्यों को प्रदान करने के लिए नोड के मौजूदा एपीआई का भी उपयोग करता है। क्या आप बॉडी, कुकी से निपटते हैं और आप कौन सा टेम्प्लेट इंजन चुनते हैं जिसे मिडलवेयर के माध्यम से अनुकूलित किया जा सकता है

यदि आप एक पूर्ण समाधान चाहते हैं, तो आप अपने स्वयं के उपयोग के dva-ant = dva-core + dva-plugins लागू कर सकते हैं

dva का संयोजन redux और saga का संयोजन होना चाहिए, क्योंकि ये दोनों डेटा स्थिति प्रवाह के मूल हैं, और अन्य को केवल डेटा पर निर्मित बाह्य उपकरणों के रूप में माना जा सकता है, और प्लग-इन या अन्य विधियों द्वारा समर्थित किया जा सकता है। हम एक्सप्रेस और Django की तुलना कर सकते हैं, कम करने और अधिक करने के बीच विशिष्ट अंतर, कुछ लोग बड़े और पूर्ण पसंद करते हैं, लेकिन जेएस समुदाय छोटे लेकिन सुंदर का सम्मान करता है

जहाँ तक सीधे redux का उपयोग करने का सवाल है, मैं dva का उपयोग करने का मुख्य कारण यह है कि dva redux की कोड संरचना और तर्क को सरल बना सकता है और उत्पादन क्षमता में सुधार कर सकता है। यह redux पर आधारित dva का मूल भी है।

यदि हम आँख बंद करके अधिक करते हैं, तो dva के अनुप्रयोग परिदृश्य संकरे और संकरे हो जाएंगे। उदाहरण के लिए, RN में प्रतिक्रिया-राउटर का उपयोग नहीं किया जा सकता है (v4 पहले से ही समर्थन करता है लेकिन बहुत बुनियादी है), RN भी लाने के साथ आता है, और अन्य मजबूत बाइंडिंग हैं . पुस्तकालय भी उन्नयन निर्भरता समस्याओं का कारण बनेगा। यह अभी भी प्रतिक्रिया-राउटर है। V4 RN का समर्थन करता है, लेकिन dva अभी भी V2 है। इसका उपयोग करने से पहले हमें प्रतिक्रिया-राउटर को अपग्रेड करने के लिए dva की प्रतीक्षा करनी होगी। यदि यह एक प्लग है- में और स्वतंत्र रूप से अपग्रेड करें, ऐसी कोई समस्या नहीं होगी

ऊपर dva-core से मेरा मतलब है कि छोटे कोर को dva-core के रूप में मानना, राउटर और इस तरह की अन्य चीजों को लेना, और फिर कुछ डिफ़ॉल्ट एकीकरण योजनाएं विकसित करना, जैसे कि कंपनी का आंतरिक एकीकृत संस्करण, मिडिल और बैक ऑफिस के लिए , और H5 के लिए, छोटे प्रोग्राम, सर्वर-साइड रेंडरिंग, आदि के लिए।

2:00:
1. वास्तविक विकास में, मॉडल में व्यावसायिक तर्क लागू किया गया है, और फ़ाइल बहुत बड़ी है। दूसरे और सेवा के बीच क्या संबंध है? सेवा या अनुरोध को बिल्ट-इन किया जा सकता है
2. प्रतिक्रिया-राउटर को सिस्टम के स्वयं के प्लग-इन में बदलें, या जो भी हो, उद्देश्य निर्भरता को मुक्त करना है

2.0 कब शुरू होगा?

प्लग करने योग्य ssr समाधान राउटर के प्रबंधन को सारगर्भित करता है। सर्वर साइड पहले रूटिंग अनुरोध को ले सकता है और स्टेट ट्री को इनिशियलाइज़ करने के लिए साझा dva () का उपयोग कर सकता है। ऐसा लगता है कि जैसे-जैसे dva अपग्रेड करना जारी रखता है, सर्वर रेंडरिंग में कमजोर है नई सुविधाओं का अनुप्रयोग।

टाइपस्क्रिप्ट और आरएन।उम्मीद है बेहतर सहयोग मिलेगा

दूसरे के बारे में सोचें, डिफ़ॉल्ट namespace

डीवीए का उपयोग करने की प्रक्रिया में, हमेशा ऐसे मामले होंगे जहां reducer को किसी उपसर्ग की आवश्यकता नहीं है, और डीवीए के वर्तमान कार्यान्वयन को namespace प्रदान करना होगा, इसलिए मेरे पास एक प्रस्ताव है, यदि namespace है default (या global , * ), हमें लगता है कि model तहत reducers उपसर्ग के बिना है

व्यक्तिगत रूप से कुछ बिंदुओं पर विचार करें:

• redux-saga पर निर्भर नहीं है, इसलिए आप आसानी से कुछ सुविधाएं जोड़ सकते हैं (जैसे async/प्रतीक्षा समर्थन)
• कई छोटे मॉड्यूल में विभाजित करें (उदाहरण के लिए, एक स्टोर, एक राउटर)
• नेस्टेड मॉडल का समर्थन करें

हमने हाल ही में vuex को redux आधार पर मॉडल किया https://github.com/d-band/yax

यह अनुशंसा की जाती है कि सर्वर को सर्वर साइड पर रेंडर किया जा सकता है, और आगे और पीछे के सिरों को एक साथ लिखा जा सकता है!

क्या मैं मार्ग निर्देशिका का नाम निर्धारित कर सकता हूं? उदाहरण के लिए, कंटेनर का उपयोग करें
वास्तव में, मैं मॉडल, सेवा और कंटेनर को एक साथ रखकर, फ़ंक्शन द्वारा कैटलॉग को विभाजित करना चाहता हूं, अन्यथा कई कैटलॉग में कूदने से हृदय का प्रवाह नष्ट हो जाएगा। यह जानने के लिए कि उदात्त के ऊपर वाले टैब में user.js क्या खोला गया है, मैंने इसे पहले ही इस तरह नाम दिया है: user.jsx, user.model.js, user.service.js। user/model.js, service.js, container.js . को एक साथ रखें

निर्देशिका संगठन जैसे @zheeeng अब समर्थित हैं, और dva के पास निर्देशिका संगठन पर कोई प्रतिबंध नहीं है।

@xufei
@sorrycc

अनमॉडलिंग करते समय, क्या आप अप्रयुक्त राज्य डेटा को नष्ट करने के लिए एक रेड्यूसर पास करने का समर्थन करने पर विचार करते हैं?

मैन्युअल नियंत्रण बहुत परेशानी भरा है, जीसी के एक सेट को सीधे लागू करने की अनुशंसा की जाती है

कृपया pathToRegexp को अपग्रेड करें, इसके पार्स और संकलन विधियों का सीधे उपयोग नहीं किया जा सकता है

अन्य परियोजनाओं या प्रौद्योगिकी स्टैक के साथ युग्मन को कम करने, कॉन्फ़िगरेशन से समझौता बेहतर है।

प्रभाव व्यवसाय बहुत भारी है, और मॉडल-विस्तार का विचार काफी अच्छा है

@nihgwu व्यक्तिगत रूप से सहमत हैं कि "

@sorrycc क्या

मैं दृढ़ता से आशा करता हूं कि डीवा-क्ली टाइपस्क्रिप्ट बॉयलरप्लेट उत्पन्न करना चुन सकता है

dva-core पहले से ही WeChat एप्लेट में उपयोग किया जा सकता है

@yautah ने कोशिश की? कोशिश करने के बाद आप योजना को साझा कर सकते हैं।

मुझे लगता है कि dva-core को केवल redux डेटा स्ट्रीम री-एनकैप्सुलेशन प्रदान करने की आवश्यकता है, क्या अन्य प्लग-इन के रूप में प्रदान किए जा सकते हैं, या उपयोगकर्ताओं के लिए उन्हें चुनना बेहतर होगा, जैसे पैकेजिंग और रूटिंग स्कीम।

स्टाइलस का समर्थन करने के लिए डीवा-क्ली का समर्थन करने की आशा है

समर्थन एसएसआर नहीं।

एचआरएम को कैसे कॉन्फ़िगर करें, एपीआई लेखन अपेक्षाकृत कम है