2017-05-18 9 views
11

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

आम तौर पर रिएक्ट मिलिओ के लिए नया होने के नाते, मुझे रिले का कोई पूर्व ज्ञान नहीं है, लेकिन इसे मेरे स्टार्टअप समुदाय और मेरे वेब-देव सहयोगियों में दोस्तों से सिफारिश पर चुना गया है। मुझे कुछ हद तक सीखने की अवस्था के बारे में भी चेतावनी दी गई थी, लेकिन आगे बढ़ने का फैसला किया - मैं पहले से ही जेएस के साथ एक उग्र लड़ाई लड़ रहा हूं और एक नए मोबाइल प्लेटफॉर्म के 0.xx संस्करण से लड़ रहा हूं, तो क्या सही है, है ना? :-) मैं एक QueryRenderer, जो था एक बड़ी राहत :-)

तो, सवाल पर साथ अपने प्रोजेक्ट को सही ढंग से मेरी GQL सर्वर के माध्यम से एक पूरे सेट और पंच करने में कामयाब रहे

मैं मुझे कंटेनर/घटक संबंध, और सामान्य रूप से कंटेनर संरचना का पता लगाने में कठिनाई होती है। पढ़ना the docs on composition मदद की है, लेकिन मैं QueryRenderer

  • QueryRenderer की भूमिका डॉक्स द्वारा कहा जाता है कि हर रिले पेड़ के लिए रूट कंटेनर होने के लिए अधिक संदेह में अभी भी कर रहा हूँ। क्या इसका मतलब है कि हमारे ऐप में रूट के लिए QueryRenderer होना चाहिए? या प्रत्येक नेविगेशन पथ की जड़ पर (यानी हमारे ऐप में टैब)? या सिर्फ प्रत्येक कंटेनर घटक के लिए (प्रस्तुतिकरण/गूंगा/शुद्ध घटकों के विपरीत, प्रतिक्रिया के अनुसार)? ध्यान दें कि मैं राय की तलाश नहीं कर रहा हूं, लेकिन सर्वोत्तम अभ्यास के लिए तर्क :-)
  • FragmentContainer (या उस मामले के लिए कोई अन्य कंटेनर) 0-के बिना 'पैरेंट' घटक में काम कर सकता है?
  • QueryRenderer बच्चों के कंटेनर से जुड़ा हुआ कैसे है? क्या यह उन सभी डेटा का योग प्राप्त करता है जो बच्चे के कंटेनर चाहते हैं, और फिर बच्चे के कंटेनर कैश से पढ़ते हैं, या? यदि ऐसा है, तो मैंने रिले के पेशेवरों को गलत समझा है - हम इस धारणा के तहत हैं कि प्रत्येक घटक प्रत्येक अन्य घटकों से स्वतंत्र रूप से डेटा पुनर्प्राप्त कर सकता है, और प्रत्येक घटक को अन्य घटकों की डेटा आवश्यकताओं (माता-पिता/बाल घटकों सहित) के बारे में कुछ भी नहीं पता है।)। मुझे लगता है कि यह धारणा मुझे QueryRenderer, और "रूट" कंटेनर की आवश्यकता के बारे में भी भ्रमित करती है।
  • यदि QueryRenderer एक 'पैरेंट'/'रूट' रिले कंटेनर रिले पेड़ में है, तो इसे इसके अनुरोध के आधार पर दृश्य घटकों को कैसे प्रस्तुत करना है? और इसका अनुरोध क्यों करना है? कब और किसके लिए हमें QueryRenderer का उपयोग करना चाहिए?

किसी भी मदद की बहुत इस विषय को लाने के लिए :-)

उत्तर

5

तो, हमारे ऐप के साथ कुछ और काम करने के बाद, मैंने सोचा कि मैं अपने विचारों और अनुभवों के बारे में पोस्ट करने के लिए वापस आऊंगा, उम्मीद है कि यह किसी की मदद करेगा।

बिल्डिंग @Peter Suwara के महान पोस्ट पर, हम एक समान रणनीति पर पहुंचे शुरू में

  • एक रूट/माता-पिता एनएवी पेड़
  • पेड़ में प्रत्येक स्क्रीन के लिए, एक QueryRenderer सभी के लिए रूट के रूप में किया है प्रस्तुतिकरण/गूंगा घटकों यह उप-घटक

के भीतर डेटा निर्भरता घोषित करने के लिए की तरह हम हालांकि उसका जवाब नीचे टिप्पणी में चर्चा

  • उपयोग टुकड़े शामिल , यह दृष्टिकोण हमेशा सबसे अच्छा नहीं हो सकता है। आगे की चर्चा के आंतरिक रूप से के बाद, हम निष्कर्ष पर पहुंचा भी कई मामलों में जहां इस सब के बाद कारणों की एक जोड़ी के लिए कोई औचित्य नहीं है देखते हैं कि:

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

    कुछ और सोचा और चर्चा के बाद, हम इस नियम के-अंगूठे जब एक रिले पेड़ की एक नई QueryRenderer 'जड़' बनाने के लिए के लिए के साथ आया था:

    जब भी आप के लिए एक नया QueryRenderer बनाएं एक नई त्रुटि-हैंडलिंग रणनीति की आवश्यकता है

    यह बहुत ही व्यावहारिक कारण के लिए हुआ कि डेटा की त्रुटियों/लोडिंग को संभालने का एकमात्र मौका है, लेकिन यह उपयोगकर्ता-प्रवाह और संरचना के तरीके में भी हमें समझ में आया , आमतौर पर दो चीजें टकराती हैं - जब आप एक नए 'प्रवाह'/भाग में पहुंचते हैं तो आप नेटवर्क त्रुटियों को संभालने का एक नया तरीका चाहते हैं एप्लिकेशन। हो सकता है कि फेसबुक पर कुछ स्मार्ट सिर हमारे सामने इस बारे में सोचा? :-)

    अंगूठे के सभी नियमों के साथ, यह केवल एक दिशानिर्देश है, न कि नियम, और इसमें अपवाद भी हैं। हालांकि, यह हमारे लिए आंतरिक रूप से समझ में आता है - कम से कम अभी के लिए।

    इन विचारों पर किसी भी और सभी प्रतिक्रियाओं का बहुत स्वागत है, क्योंकि मुझे लगता है कि आधिकारिक दस्तावेज़ कम से कम कहने के लिए कमजोर हैं, और समुदाय चर्चा तब तक हमारे पास है जब तक दस्तावेज़ और सामान्य पैटर्न समय के साथ तय नहीं हो जाते हैं।

  • +0

    यदि पर्याप्त लोग उत्तर को ऊपर उठाते हैं, तो अंततः मैं इसे भविष्य में इस पोस्ट पर जाने वाले किसी भी व्यक्ति के लिए "स्वीकृत" के रूप में चिह्नित करूंगा। मैं इंतजार करूँगा और देख सकता हूं कि अन्य लोग हमारी रणनीति के साथ पहले सहमत हैं, हालांकि :-) – jhm

    +0

    क्या यह घटक रेंडर करते समय केवल टुकड़ों के लिए डेटा लाने के लिए पर्याप्त स्मार्ट नहीं है? उदाहरण के लिए, आपके पास एक खंड के साथ रूट क्वेरी हो सकती है ... User_friends; मेरा मानना ​​है कि रिले इस तरह के टुकड़े के लिए डेटा लाएगा जब घटक इसका उपयोग करता है। अगर मैं गलत हूं तो कृपया मुझे सही करें –

    +1

    खुद को जवाब देकर, मैंने अभी एक बच्चे के टुकड़े की कोशिश की है जो माता-पिता QueryRenderer के अंदर है और वास्तव में, क्वेरीरेंडर बच्चे के टुकड़े के लिए डेटा प्राप्त करता है, भले ही बच्चे को अभी तक प्रस्तुत नहीं किया जाता है। वैसे भी, मुझे दोनों उत्तरों को ऊपर उठाना होगा, क्योंकि वास्तव में यह विशिष्ट स्थिति पर निर्भर करता है =) –

    7

    धन्यवाद की सराहना की है। मैं भी रिएक्टनेटिव के साथ रिले में जा रहा हूं, और कुछ रोमांचक परिणामों के साथ।

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

    सर्वोत्तम प्रथाओं के संबंध में मैं यह सुनिश्चित नहीं कर सकता कि आपके क्वेरीरेंडर और खंडकंटनर को कैसे पेश किया जाए, हालांकि मैं डेटा प्रस्तुत करने के हमारे तरीके का वर्णन कर सकता हूं।

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

    • मार्गदर्शक फ़्लो (प्रतिक्रिया-नेविगेशन, ढेर/टैब नाविक)
    • स्क्रीन (QueryRenderer) यूआई
    • विजेट/घटक (fragmentContainer)

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

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

    मुझे अन्य लोगों के दृष्टिकोणों को सुनने में दिलचस्पी होगी कि वे एक नौसेनात्मक प्रतिक्रिया-मूल ऐप के भीतर रिले कैसे लागू करते हैं।

    +0

    अरे पीटर, इस तरह के विस्तृत उत्तर लिखने के लिए समय निकालने के लिए धन्यवाद :-) कुछ चर्चा के बाद, यह वही रणनीति थी जिस पर हम पहुंचे थे, और जब मैंने आपकी पोस्ट देखी तो आज इसे आजमा देना चाहता था - तो शायद न तो हम बहुत दूर हैं ;-) दुर्भाग्यवश, इसे लागू करने की कोशिश करते समय, एक और समस्या में भाग गया, और इसे यहां पोस्ट किया (jhalborg) https://github.com/facebook/relay/issues/1665। एक बार जब मैं इसे काम कर लेता हूं, तो मैं यहां वापस आऊंगा और अपने अनुभवों को जोड़ दूंगा – jhm

    +0

    मुझे आश्चर्य है, हालांकि, यदि टैब में से किसी एक बच्चे के रूप में स्टैक एनएवी में गहरी नौसेना का पेड़ है तो यह सबसे अच्छा तरीका है - ऐसे मामले में, क्वेरीरेंडरर बहुत सारे डेटा लाएगा जो उपयोगकर्ता के लिए प्रासंगिक नहीं हो सकता है, इससे पहले कि वह स्टैक एनवी पेड़ में गहराई से स्क्रीन हिट करे, और इसलिए यह एक और क्वेरी रूटर को एक नई "रूट" "स्टैक एनवी पेड़ के नीचे आगे - आपको क्या लगता है? – jhm

    +1

    सुनने के लिए बहुत बढ़िया हम एक ही पृष्ठ पर हैं। संदेश के लिए धन्यवाद। अनावश्यक डेटा के संबंध में। हम वर्तमान में इसे देख रहे हैं। अभी के लिए, हमें जो कुछ भी चाहिए वह सिर्फ क्वेरी से हटा दिया गया है। मैं वास्तव में मेटा डेटा के संबंध में एक दिलचस्प मुद्दा में चला गया है। जहां यूआई एक क्वेरी के परिणामों को प्रतिबिंबित नहीं करता है, लेकिन एक प्रोप का उपयोग करके पारित किया जाता है। विवरण काफी जटिल हैं इसलिए यहां नहीं जायेंगे। लेकिन अब तक हमारा समाधान हमारी आवश्यकताओं को पूरा करने लगता है। रास्ते में कुछ विसंगतियां होने पर भी मूल रूप से परिणामों का उत्पादन करने के लिए यह बहुत तेज़ है। –

    संबंधित मुद्दे