أعتقد أن الأمر يعتمد فقط على كيفية استخدامك للإطار. أنا شخصياً لم أجد هذه الحاجة أبدًا ، والمرة الوحيدة التي يمكنني تخيل أنني أرغب في ذلك سيكون من أجل تسلسل الكائنات واستخدام بيانات ember ، لذلك فإن هذه الحاجة ليست ذات صلة.

ومع ذلك ، إذا كانت لدي هذه المشكلة ، فسأبدأ باستخدام 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 أعتقد أن هذا حقًا سؤال لـ OP. أعتقد أنني كنت أفترض أنه كان لديه فصل دراسي قام بحساب الخصائص / الوظائف / المراقبين / إلخ. لم أفكر فقط في التكرار باستخدام Ember.keys ، اعتقدت أن ذلك سيشمل أشياء من الفصل (أقسم بالعودة إلى اليوم الذي حدث فيه ذلك) ، لكنني فوجئت بسرور عندما اكتشفت أنها لم تفعل ذلك.

بدافع الفضول فقط ، لماذا تنصح بعدم استخدام Ember.ObjectProxy ؟

تحرير: فقط للتوضيح ، الحل Ember.keys بكثير ويحصل على تصويتي. كنت مجرد فضول إذا كان لديك أي أفكار سلبية على وجه التحديد حول ObjectProxy .

هناك بعض الاستراتيجيات لاستخراج بنية "Hash" الأصلية التي تم استخدامها لإنشاء كائن الجمرة (بقيم معدلة أو بدونها) ، وكان سؤالي في الغالب حول عدد المرات التي يحتاج فيها مجتمع Ember.js العام إلى هذا. ستكون طريقة .nativeCopy رائعة حقًا على Ember.Object لكنني أقدر ضرورة أن تكون انتقائيًا للغاية مع إضافات API. في بعض الأحيان يكون من المنطقي إضافة طريقة تجعل عملية شائعة للغاية أكثر ملاءمة وأحيانًا لا تكون كذلك. لدي شعور بأن الناس لا يواجهون هذه الحاجة بقدر ما أفعل.

أحد الأمثلة الملموسة ، إذا كنت فضوليًا ، هو استخدام Ember.Object لدعم نموذج "Create New […]". ربما يكون نموذج الإنشاء أسفل قائمة العناصر مباشرةً. إذا كنت تستخدم this.store.createRecord لإنشاء نموذج فارغ لدعم النموذج ، فإنه يضيف على الفور عنصرًا جديدًا إلى القائمة أعلاه ويملأ القيم أثناء ملء النموذج. لتجنب ذلك ، قد أقوم بإنشاء Ember.Object لدعم النموذج ، ولكن بعد ذلك يجب أن أخرج القيم واحدة تلو الأخرى لتمريرها إلى createRecord

أحد الأسباب الأخيرة لفعل هذا كثيرًا هو إنشاء نسخة عميقة نظرًا لأن تنفيذ Ember.Copyable يمثل ألمًا كبيرًا. يعجبني تصميم Ember.Copyable لكن التنفيذ الافتراضي / العام سيكون رائعًا حقًا.

السبب الأكبر للحاجة إلى pojo's هو دعم مكتبة الطرف الثالث. تتوقع كل من Datatables و jstree وما إلى ذلك مصفوفات وكائنات جافا سكريبت عادية وسوف تنفجر بهياكل بيانات جمرة.

ccarterc مثل ، على سبيل المثال localforage.setItem - إنها PITA مع Ember.Object
في مواجهة ذلك اليوم واضطررت إلى وضع "escaper" مخصص لذلك.

ركض في هذه الحاجة بالضبط اليوم. كما قال ccarterc ، هذا أمر بالغ الأهمية بالنسبة للجهات الخارجية التي تتوقع POJOs. سيكون من الرائع أن يكون لديك طريقة "رسمية" للقيام بذلك.

أريد القدرة على العمل مع POJO ، حتى أتمكن من إرسال العنصر الخاص بي إلى مكتبة Vanilla JS لجهة خارجية.

نعم من فضلك - تكافح مع هذا الآن لجهة خارجية API. الحل الحالي الخاص بي هو إجراء getProperties لكائن به مصفوفة تتكون من حوالي 70 حقلاً. هذا يبدو سخيفًا وسيكون وجود وظيفة للقيام بذلك أمرًا رائعًا ...