Я думаю, это просто зависит от того, как вы используете фреймворк. Я лично никогда не сталкивался с этой потребностью, единственный раз, когда я могу представить, что это нужно, - это сериализация объектов, и я использую ember-data, поэтому эта потребность не имеет значения.

Тем не менее, если бы у меня была эта проблема, я бы начал с использования 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 .

Есть несколько стратегий для извлечения исходной структуры «Хэш», которая использовалась для создания объекта ember (с измененными значениями или без них), мой вопрос был в основном о том, как часто это нужно общему сообществу Ember.js. метод .nativeCopy был бы очень хорош для Ember.Object но я ценю необходимость быть чрезвычайно избирательным при добавлении API. Иногда имеет смысл добавить метод, который делает чрезвычайно распространенную операцию более удобной, а иногда нет. У меня такое чувство, что люди не так часто сталкиваются с этой потребностью, как я.

Один конкретный пример, если вам интересно, - это использование Ember.Object для поддержки формы «Создать новый […]». Возможно, форма создания находится прямо под списком элементов. Если вы используете this.store.createRecord для создания пустой модели для поддержки формы, он немедленно добавляет новый элемент в список выше и заполняет значения по мере заполнения формы. Чтобы избежать этого, я могу создать Ember.Object для поддержки формы, но тогда мне нужно вывести значения одно за другим, чтобы перейти к createRecord

Последняя причина, по которой я так часто делаю, - это создание глубокой копии, поскольку реализация Ember.Copyable - это такая боль. Мне нравится дизайн Ember.Copyable но разумная реализация по умолчанию / общая была бы действительно хороша.

Самая большая причина, по которой вам нужны pojo, - это поддержка сторонних библиотек. Datatables, jstree и т. Д. Ожидают простых массивов и объектов javascript и взорвутся структурами данных ember.

@ccarterc вроде, например localforage.setItem - это PITA с Ember.Object
Столкнулся с этим сегодня и пришлось поставить кастомный «беглец» для того.

Наткнулся на эту нужду сегодня. Как сказал @ccarterc , это важно для сторонних библиотек, которые ожидают POJO. Было бы здорово иметь для этого «официальный» метод.

Мне нужна возможность работать с POJO, поэтому я могу отправить свой объект в стороннюю ванильную JS-библиотеку.

да, пожалуйста - борюсь с этим сейчас для стороннего API. мой текущий обходной путь - сделать getProperties для объекта с массивом примерно из 70 полей. это кажется глупым, и было бы здорово иметь функцию для этого ...