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

उस ने कहा, अगर मुझे यह समस्या है, तो मैं Ember.ObjectProxy का उपयोग करके शुरू करूंगा और देख सकता हूं कि यह मुझे कितना दूर मिला। यहां एक उदाहरण दिया गया है: http://emberjs.jsbin.com/kapenomivu/1/edit?js , आउटपुट

सामान्य कार्य जो किसी वस्तु के गुणों पर पुनरावृति करता है

यह वही है जो hasOwnProperty के लिए है

उपयोग करने के लिए स्वतंत्र महसूस करें, Ember.keys जो कमोबेश Object.keys

Ember.keys(Ember.Object.create({ foo: 1 }))
>  [ 'foo' ]

उस ने कहा, अगर मुझे यह समस्या है, तो मैं Ember.ObjectProxy का उपयोग करके शुरू करूंगा और देख सकता हूं कि मुझे कितना दूर मिला। यहां एक उदाहरण दिया गया है: http://emberjs.jsbin.com/kapenomivu/1/edit?js , आउटपुट

मैं इसके खिलाफ अनुशंसा करता हूं, क्यों न केवल pojo सीधे उपयोग करें?

@stefanpenner मुझे लगता है कि यह वास्तव में ओपी के लिए एक सवाल है। मुझे लगता है कि मैं मान रहा था कि उसके पास एक वर्ग था जिसने गुणों/कार्यों/पर्यवेक्षकों/आदि की गणना की थी। मैंने केवल Ember.keys साथ पुनरावृति पर विचार नहीं किया था, मैंने सोचा था कि इसमें कक्षा से सामान शामिल होगा (मैं उस दिन वापस शपथ लेता हूं), लेकिन यह जानकर सुखद आश्चर्य हुआ कि ऐसा नहीं हुआ।

जिज्ञासा से बाहर, आप Ember.ObjectProxy का उपयोग करने के विरुद्ध अनुशंसा क्यों करेंगे?

संपादित करें: बस स्पष्ट करने के लिए, Ember.keys समाधान बहुत साफ है और मेरा वोट प्राप्त करता है। यदि आप विशेष रूप से ObjectProxy आसपास कोई नकारात्मक विचार रखते हैं तो बस उत्सुक थे।

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

एक ठोस उदाहरण, यदि आप उत्सुक हैं, तो "नया बनाएं [...]" फ़ॉर्म का समर्थन करने के लिए Ember.Object कर रहा है। शायद निर्माण प्रपत्र वस्तुओं की सूची के ठीक नीचे है। यदि आप फॉर्म को वापस करने के लिए रिक्त मॉडल बनाने के लिए this.store.createRecord का उपयोग करते हैं, तो यह तुरंत उपरोक्त सूची में एक नया आइटम जोड़ता है और फॉर्म भरते ही मान भर देता है। इससे बचने के लिए मैं फॉर्म को वापस करने के लिए Ember.Object बना सकता हूं, लेकिन फिर मुझे createRecord पास करने के लिए मूल्यों को एक-एक करके प्राप्त करना होगा

एक आखिरी कारण यह है कि मैं इसे बहुत कुछ करता हूं क्योंकि Ember.Copyable को लागू करने के बाद से एक गहरी प्रतिलिपि बनाना एक ऐसा दर्द है। मुझे Ember.Copyable का डिज़ाइन पसंद है लेकिन एक समझदार डिफ़ॉल्ट/सामान्य कार्यान्वयन वास्तव में वास्तव में अच्छा होगा।

pojo की जरूरत का सबसे बड़ा कारण थर्ड पार्टी लाइब्रेरी सपोर्ट है। डेटाटेबल्स, जेस्ट्री, इत्यादि सभी सादे जावास्क्रिप्ट सरणी और वस्तुओं की अपेक्षा करते हैं और एम्बर डेटा संरचनाओं के साथ उड़ जाएंगे।

@ccarterc जैसे, जैसे localforage.setItem - यह एम्बर के साथ पिटा है। ऑब्जेक्ट
आज इसका सामना करना पड़ा और उसके लिए कस्टम "एस्केपर" रखना पड़ा।

आज इस सटीक जरूरत में भाग गया। जैसा कि @ccarterc ने कहा, यह तीसरे पक्ष के पीओजेओ की उम्मीद कर रहे हैं। ऐसा करने के लिए "आधिकारिक" विधि होना बहुत अच्छा होगा।

मैं एक पीओजेओ के साथ काम करने की क्षमता चाहता हूं, इसलिए मैं अपनी वस्तु को किसी तृतीय पक्ष वेनिला जेएस लाइब्रेरी में भेज सकता हूं।

हाँ कृपया - इसके साथ अब एक तृतीय पक्ष एपीआई के लिए संघर्ष कर रहा है। मेरा वर्तमान कामकाज किसी ऑब्जेक्ट के लिए getProperties करना है जिसमें लगभग 70 फ़ील्ड की सरणी है। यह मूर्खतापूर्ण लगता है और ऐसा करने के लिए एक कार्य करना बहुत अच्छा होगा ...