Supongo que solo depende de cómo estés usando el marco. Personalmente, nunca encontré esta necesidad, la única vez que puedo imaginar que querría esto sería para la serialización de objetos y uso ember-data, por lo que esa necesidad no es relevante.

Dicho esto, si tuviera este problema, empezaría usando Ember.ObjectProxy y vería hasta dónde me llevaba. Aquí hay un ejemplo: http://emberjs.jsbin.com/kapenomivu/1/edit?js , salida

función genérica que itera sobre las propiedades de un objeto

para esto es hasOwnProperty

siéntase libre de usar, Ember.keys que es más o menos Object.keys

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

Dicho esto, si tuviera este problema, empezaría usando Ember.ObjectProxy y vería hasta dónde me llevaba. Aquí hay un ejemplo: http://emberjs.jsbin.com/kapenomivu/1/edit?js , salida

Probablemente lo recomendaría en contra de esto, ¿por qué no usar el pojo directamente?

@stefanpenner Creo que esa es realmente una pregunta para el OP. Supongo que estaba asumiendo que tenía una clase que había calculado propiedades / funciones / observadores / etc. No había considerado simplemente iterar con Ember.keys , pensé que eso incluiría cosas de la clase (lo juro en el pasado), pero me sorprendió gratamente descubrir que no era así.

Solo por curiosidad, ¿por qué recomendaría no usar Ember.ObjectProxy ?

Editar: Solo para aclarar, la solución Ember.keys es mucho más limpia y obtiene mi voto. Solo tenía curiosidad si tenía algún pensamiento negativo específicamente alrededor de ObjectProxy .

Hay algunas estrategias para extraer la estructura "Hash" original que se usó para crear el objeto ember (con o sin valores modificados), mi pregunta era principalmente sobre la frecuencia con la que la comunidad general de Ember.js necesita esto. un método .nativeCopy sería realmente bueno en Ember.Object pero aprecio la necesidad de ser extremadamente selectivo con las adiciones de API. A veces tiene sentido agregar un método que hace que una operación extremadamente común sea más conveniente y, a veces, no. Tengo la sensación de que la gente no se encuentra con esta necesidad tan a menudo como yo.

Un ejemplo concreto, si tiene curiosidad, es usar un Ember.Object para respaldar un formulario "Crear nuevo […]". Quizás el formulario de creación esté justo debajo de una lista de elementos. Si usa this.store.createRecord para crear un modelo en blanco para respaldar el formulario, inmediatamente agrega un nuevo elemento a la lista anterior y completa los valores a medida que completa el formulario. Para evitar esto, podría crear un Ember.Object para respaldar el formulario, pero luego tengo que sacar los valores uno por uno para pasar a createRecord

Una última razón por la que hago esto con frecuencia es para crear una copia profunda, ya que implementar Ember.Copyable es una molestia. Me gusta el diseño de Ember.Copyable pero una implementación sensata predeterminada / genérica sería realmente agradable.

La principal razón para necesitar pojo's es el soporte de bibliotecas de terceros. Datatables, jstree, etc., todos esperan matrices y objetos simples de JavaScript y explotarán con estructuras de datos de ascuas.

@ccarterc como, por ejemplo, localforage.setItem - es PITA con Ember.Object
Me enfrenté a él hoy y tuve que ponerle personalizado "escaper" para eso.

Me encontré con esta necesidad exacta hoy. Como dijo @ccarterc , esto es crucial para las

Quiero la capacidad de trabajar con un POJO, para poder enviar mi objeto a una biblioteca JS vanilla de terceros.

sí, por favor, luchando con esto ahora para una API de terceros. mi solución actual es hacer getProperties para un objeto con una matriz de aproximadamente 70 campos. esto parece una tontería y tener una función que hacer sería genial ...