रेडक्स को बहुत बड़े डेटा-सेट और इंडेक्सड डीबी

Question

के साथ एकीकृत करने के लिए कैसे करें मेरे पास एक ऐप है जो अपना डेटा प्राप्त करने के लिए सिंक एपीआई का उपयोग करता है, और स्थानीय रूप से सभी डेटा स्टोर करने की आवश्यकता है। डेटा सेट स्वयं बहुत बड़ा है, और मैं इसे स्मृति में संग्रहीत करने में अनिच्छुक हूं, क्योंकि इसमें हजारों रिकॉर्ड हो सकते हैं। चूंकि मुझे नहीं लगता कि वास्तविक डेटा संरचना प्रासंगिक है, मान लीजिए कि मैं एक ईमेल क्लाइंट का निर्माण कर रहा हूं जिसे ऑफ़लाइन एक्सेस करने की आवश्यकता है, और मैं चाहता हूं कि मेरा स्टोरेज तंत्र इंडेक्स डीडी (जो एसिंक है)।

मुझे पता है कि एक साधारण समाधान मेरे राज्य वस्तु के हिस्से के रूप में डेटा संरचना नहीं होना चाहिए और केवल आवश्यक डेटा के साथ राज्य को पॉप्युलेट करना होगा (उदाहरण के लिए - EMAIL_OPEN कार्रवाई ट्रिगर होने पर राज्य पर स्टोर ईमेल सामग्री)। यह काफी सरल है, खासकर रेडक्स-थंक के साथ।

हालांकि, इसका मतलब यह होगा मैं 2 बातें समझौता करने की जरूरत है:

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

क्या इन-मेमोरी स्टेट गुणों के साथ रेडक्स का उपयोग करने के तरीके पर कोई सर्वोत्तम अभ्यास है? मेरे सिर को लपेटने के लिए जो चीज मुझे सबसे मुश्किल लगती है वह यह है कि रेडक्स सिंक्रोनस एपीआई पर निर्भर करता है, और इसलिए मैं अपने राज्य ऑब्जेक्ट को एसिंक स्टेट ऑब्जेक्ट के साथ प्रतिस्थापित नहीं कर सकता (जब तक कि मैं पूरी तरह से रेडक्स को हटा नहीं देता और इसे अपने स्वयं के, एसिंक कार्यान्वयन और कनेक्टर से प्रतिस्थापित नहीं करता)।

मुझे Google का उपयोग करके कोई जवाब नहीं मिला, लेकिन अगर इस विषय पर पहले से ही अच्छे संसाधन हैं तो मुझे भी ध्यान देना अच्छा लगेगा।

अद्यतन: प्रश्न के जवाब दिए लेकिन मैं इसे कैसे लागू किया, मामला किसी में में एक बेहतर explantation देना चाहता था था इसे में चलाता है:

मुख्य विचार दोनों क्लाइंट और सर्वर के परिवर्तन सूचियों बस redux का उपयोग कर बनाए रखना है reducers, और ग्राहक परिवर्तन के साथ सर्वर को अपडेट करने के लिए एक कनेक्टर का उपयोग आईडीबी अद्यतन करने के लिए इन परिवर्तन सूचियों को सुनने के लिए, और यह भी:

1. जब ग्राहक परिवर्तन करता है, reducers का उपयोग ग्राहक परिवर्तन सूची अद्यतन करने के लिए।
2. जब सर्वर अद्यतन भेजता है, सर्वर परिवर्तन सूची अद्यतन करने के लिए reducers का उपयोग करें।
3. एक कनेक्टर स्टोर करने के लिए सुनता है, और राज्य परिवर्तन अपडेट आईडीबी पर। संशोधित वस्तुओं की आंतरिक सूची को भी बनाए रखें।
4. सर्वर अपडेट करते समय, आईडीबी से डेल्टा खींचने और सर्वर पर भेजने के लिए संशोधित वस्तुओं की सूची का उपयोग करें।
5. जब डेटा तक पहुँचने,

इस दृष्टिकोण के साथ ही चेतावनी है कि चूंकि वास्तविक स्थिति आईडीबी में संग्रहीत है, इसलिए हम कुछ खोना है (उदाहरण के लिए redux-thunk का प्रयोग करके) आईडीबी से खींचने के लिए सामान्य क्रियाओं का उपयोग एक राज्य वस्तु (और रिवाइंड/फास्ट-फॉरवर्ड स्टेटस को भी कठिन) के मूल्य के

Answer 1

मुझे लगता है कि आपका पहला झुकाव सही है। अगर (!) आप स्टोर में सबकुछ स्टोर नहीं कर सकते हैं, तो आपको स्टोर में कम स्टोर करना होगा।लेकिन मैं मुझे लगता है कि समाधान बहुत बेहतर ध्वनि कर सकते हैं विश्वास करते हैं:

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

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

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