Feliz: एल्मिश रिंगबफर का उपयोग करें

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

मुझे यह भी यकीन नहीं है कि प्लंबिंग उसके साथ कैसे काम करेगी, क्योंकि हमें यह संभालना होगा कि वास्तव में प्रभाव कहाँ खपत होते हैं। क्या पहला घटक बस उन सभी को करेगा? मैं इसे प्रदर्शन पर प्रभाव डालते हुए देख सकता था।

ओह समझा। समवर्ती मोड ई के बारे में नहीं सोचा, स्पष्टीकरण के लिए बहुत बहुत धन्यवाद! ठीक है, अभी के लिए बंद हो जाएगा और शायद हम बाद में फिर से आ सकते हैं।

क्षमा करें @Shmew , मैं इस बारे में सोचता रहता हूं अगर मैं गलत नहीं हूं (हालांकि मैं बहुत अच्छी तरह से हो सकता हूं) रिंग बफर का उपयोग एल्मिश में किया जाता है क्योंकि इसे प्लेटफॉर्म के साथ संगत होने की आवश्यकता होती है जहां यूआई और अपडेट फ़ंक्शन अलग-अलग चल सकते हैं धागे। लेकिन useElmish केवल JS में चलेगा, तो क्यों न ऐसा कुछ किया जाए?

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

मैंने कभी इस पर ज्यादा विचार नहीं किया था क्योंकि इस तरह सामान्य Fable Elmish चलाया जाता है।

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

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

@Shmew की जाँच के लिए धन्यवाद! क्षमा करें, मैं रिंग बफर के प्रति थोड़ा जुनूनी हो रहा हूं। एल्मिश में एसिंक्रोनस अपडेट के बारे में हमने जो चर्चा की थी, वह सिर्फ मुझे याद है और यह मुझे थोड़ा चिंतित करता है कि हमारे पास कोड का एक टुकड़ा है जिसे हम वास्तव में नहीं जानते कि यह क्या कर रहा है। IIRC रिंग बफर, मेलबॉक्सप्रोसेसर का प्रतिस्थापन था, ठीक है क्योंकि यह वास्तव में Fable में अतुल्यकालिक नहीं था।

उपयोगकर्ता हमेशा इस बात को लेकर भी भ्रमित रहते हैं कि update सिंक्रोनस रूप से चलता है या नहीं। मेरी वर्तमान सोच यह है कि update समकालिक और तेज होना चाहिए और अतुल्यकालिक/धीमी क्रियाओं को आदेशों पर छोड़ दिया जाना चाहिए। हालांकि जेएस में अंतर बहुत महत्वपूर्ण नहीं होना चाहिए, यह देखते हुए कि आप नए धागे पैदा नहीं कर सकते हैं। यह सुनिश्चित करने के लिए कि अगले जेएस इवेंट लूप में निष्पादन होगा, यह सुनिश्चित करने के लिए एक प्रॉमिस या setTimeout(..., 0) में कमांड कॉल को लपेटने के लिए पर्याप्त होना चाहिए। हालांकि ज्यादातर मामलों में कमांड पहले से ही खुद से वादे करेंगे, और यदि आप बड़ी संख्या में फैक्टोरियल चलाने वाले थ्रेड को ब्लॉक करने की योजना बना रहे हैं, तो कमांड का उपयोग करने से मदद नहीं मिलेगी और इससे कोई बड़ा फर्क नहीं पड़ेगा या तो यूआई इस या अगले ईवेंट में ब्लॉक हो जाता है टिक करें।

वर्तमान में सभी प्रसंस्करण एक वादे (एक प्रभाव हुक के अंदर) के रूप में किया जाता है।

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

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

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

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

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

मैंने सोचा था कि यह एक Program.withReactSynchronous अनुकरण करने का तरीका था लेकिन मुझे अब यकीन नहीं है।

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

यहाँ सूचियों के साथ एक उचित कुशल अपरिवर्तनीय FIFO कार्यान्वयन है। रिवर्स केवल तभी कॉल किया जाता है जब आउटगोइंग सूची खाली होती है और आने वाली वस्तुओं का निर्माण होता है इसलिए निष्पादन आमतौर पर ओ (1) होता है। मैंने मौजूदा उपयोग एल्मिश कार्यान्वयन पर एक नज़र डाली, लेकिन वास्तव में समझ में नहीं आया कि क्या हो रहा था, इसलिए इसे बदलने का मोह नहीं था।

type ListQueue<'T> private (incoming:'T list, outgoing:'T list) =
    new () = ListQueue([], [])

    member this.Push item = 
        match incoming, outgoing with
        | [], [] -> ListQueue([], [item])
        | _ -> ListQueue(item :: incoming, outgoing)

    member this.Pop () = 
        match outgoing with
        | item :: outgoing -> 
            ListQueue(incoming, outgoing), item
        | [] -> 
            match List.rev incoming with
            | [] -> failwith "Cannot Pop from an empty ListQueue"
            | item :: outgoing -> ListQueue([], outgoing), item

    member this.IsEmpty = 
        match incoming, outgoing with
        | [], [] -> true
        | _ -> false