Ember.js में राज्य प्रबंधक के बारे में सर्वोत्तम अभ्यास

Question

एम्बर.जेएस में StateManager अभी तक अच्छी तरह से प्रलेखित नहीं है, इसलिए मुझे इसके उपयोग के संबंध में कुछ प्रश्न हैं।

1. क्या किसी को केवल राज्य प्रबंधक के भीतर से .goToState पर कॉल करने का प्रयास करना चाहिए?
2. मुझे कभी-कभी दृश्य प्रबंधक राज्य में दृश्य मिररिंग विधियां मिलती हैं, उदा। save: -> StateManager.send("save")। क्या यह समझ में आता है या क्या मुझे कुछ याद आ रहा है?
3. क्या मॉडल के सभी संशोधन (आमतौर पर) राज्य प्रबंधक के माध्यम से जाना चाहिए?
4. यदि किसी दृश्य में अलग-अलग राज्य हैं, तो इसे ViewState का उपयोग करके बाल राज्यों के साथ मॉडल किया जाना चाहिए, या क्या मुझे गणना की गई संपत्तियों का उपयोग करना चाहिए और उस जानकारी को केवल दृश्य में रखने के लिए गुणों को देखना चाहिए (राज्य प्रबंधक के विचारों को आंतरिक राज्य के बारे में जानने के बिना) *

* एक उदाहरण एक तीन-चरण रूप है, जहां एक ही टेम्पलेट सभी राज्यों लेकिन विभिन्न क्षेत्रों के लिए प्रयोग किया जाता है दिखाए जाते हैं/तीन चरणों में छिपा हो सकता है।

Github संदर्भ: https://github.com/emberjs/ember.js/tree/master/packages/ember-states/lib

Answer 1

क्या किसी को केवल प्रबंधक के भीतर से .goToState को कॉल करने का प्रयास करना चाहिए?

शायद। मैं निश्चित रूप से यह नहीं जानता, लेकिन ऐसा लगता है कि राज्य प्रबंधक जानता है कि आप किस राज्य में हैं, यह कानूनी राज्य संक्रमण लागू करने का स्थान है। यदि आपने राज्य प्रबंधक के बाहर से .goToState को बुलाया है, तो आप वास्तव में यह जानने के बिना कर रहे हैं कि आप किस स्थिति में हैं, और यह कभी-कभी ठीक है (शायद यह एक ऐसा राज्य है जहां आप वास्तव में किसी अन्य राज्य से पहुंच सकते हैं) यह एक महान आदत नहीं है होने के लिए

मुझे कभी-कभी राज्य में प्रबंधक में मिररिंग विधियां मिलती हैं, उदाहरण के लिए सहेजें: -> StateManager.send ("सहेजें")। जो समझ में आता है या क्या मुझे कुछ याद आ रहा है?

मुझे यह पसंद है कि इस बारे में क्या कहना है।

क्या मॉडल (आमतौर पर) के सभी संशोधन राज्य प्रबंधक के माध्यम से जाना चाहिए?

जिस तरह से मैं राज्यचाप का उपयोग करता हूं, नहीं। मैंने कुछ लोगों को स्टेटचर का उपयोग कर नियंत्रक परत के लिए बहुत अधिक प्रतिस्थापन के रूप में देखा है, और यदि आप इस तरह काम कर रहे हैं, तो हाँ, इसे राज्य प्रबंधक के माध्यम से जाना चाहिए। पैटर्न विचारों से मॉडल के प्रत्यक्ष हेरफेर से बचने के लिए है; चाहे यह एक नियंत्रक परत है या बीच में एक राज्य प्रबंधक मेरे लिए एक महत्वपूर्ण बिंदु की तरह लगता है।

जिस तरह से मैं राज्य चार्ट का उपयोग करता हूं, हालांकि, राज्य प्रबंधक को आवेदन की स्थिति का प्रबंधन करने के लिए बनाया जाता है। यह मॉडलों के संशोधन के लिए यातायात प्रबंधक खेल सकता है यदि वह संशोधन आवेदन की स्थिति को बदल देगा (उदाहरण के लिए यदि कोई अपडेट पूरा होने पर प्रगति संकेतक है), लेकिन ऐसा लगता है कि मॉडल अपडेट इसके जनादेश का हिस्सा नहीं हैं; वे नियंत्रकों से संबंधित हैं।

एक दृश्य विभिन्न राज्यों में है, तो उस बच्चे राज्यों के साथ एक ViewState का उपयोग कर मॉडलिंग की जानी चाहिए, या मैं ( को गणना गुण और दृश्य गुण का उपयोग करना चाहिए राज्य प्रबंधक बिना ही ध्यान में रखते हुए कि जानकारी पकड़ आंतरिक राज्य के विचारों को जानना)?

मुझे लगता है कि राज्य प्रबंधक को दृश्य की आंतरिक स्थिति को जानना चाहिए (या जानना चाहिए)।

जिज्ञासा से, क्या आप वेब विकास पृष्ठभूमि, या डेस्कटॉप/मोबाइल ऐप विकास पृष्ठभूमि से आ रहे हैं? मैं वेब विकास से आया, और राज्य चार्ट मेरे लिए एक नई अवधारणा थी। मैंने डेविड हेल ('वेयर पीडीएफ!) द्वारा the canonical State Chart paper पढ़ने के लिए बहुत उपयोगी पाया। यह एक अकादमिक पेपर के लिए आश्चर्यजनक रूप से पठनीय है और मूल राज्य चार्ट अवधारणा बताता है कि अधिकांश स्प्राउटकोर/एम्बर दुनिया 2010 के अंत से उपयोग कर रही है (यानी Michael Cohen को ध्यान में रखते हुए ध्यान में रखा गया था।)

Answer 2

अपनी बात के बारे में :

मैं कभी कभी अपने आप को देखने पर राज्य प्रबंधक में तरीकों को प्रतिबिंबित करने लगता है, जैसे save: -> StateManager.send("save")। क्या यह समझ में आता है या क्या मुझे कुछ याद आ रहा है?

आप अपने Handlebars टेम्पलेट में action सहायक का उपयोग करें और अपने StateManager रूप target

{{action "send" target="App.stateManager"}} 

सेट और send घटना अपने App.stateManager लिए भेज है सकता है।