Je suppose que cela dépend de la façon dont vous utilisez le framework. Personnellement, je n'ai jamais trouvé ce besoin, la seule fois où je peux imaginer le vouloir, ce serait pour la sérialisation d'objets et j'utilise des données de braise, donc ce besoin n'est pas pertinent.

Cela dit, si j'avais ce problème, je commencerais par utiliser Ember.ObjectProxy et je verrais jusqu'où cela m'a mené. Voici un exemple : http://emberjs.jsbin.com/kapenomivu/1/edit?js ,sortie

fonction générique qui itère sur les propriétés d'un objet

c'est à ça que sert hasOwnProperty

n'hésitez pas à utiliser, Ember.keys qui est plus ou moins Object.keys

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

Cela dit, si j'avais ce problème, je commencerais par utiliser Ember.ObjectProxy et je verrais jusqu'où cela m'a mené. Voici un exemple : http://emberjs.jsbin.com/kapenomivu/1/edit?js ,sortie

Je recommanderais probablement contre cela, pourquoi ne pas simplement utiliser le pojo directement ?

@stefanpenner Je pense que c'est vraiment une question pour l'OP. Je suppose que je supposais qu'il avait une classe qui avait calculé des propriétés/fonctions/observateurs/etc. Je n'avais pas envisagé d'itérer simplement avec Ember.keys , je pensais que cela inclurait des éléments de la classe (je le jure à l'époque), mais j'ai été agréablement surpris de constater que ce n'était pas le cas.

Juste par curiosité, pourquoi déconseilleriez-vous l'utilisation de Ember.ObjectProxy ?

Edit : Juste pour clarifier, la solution Ember.keys est beaucoup plus propre et obtient mon vote. J'étais simplement curieux de savoir si vous aviez des pensées négatives spécifiquement autour de ObjectProxy .

Il existe quelques stratégies pour extraire la structure "Hash" d'origine qui a été utilisée pour créer l'objet ember (avec ou sans valeurs modifiées), ma question portait principalement sur la fréquence à laquelle la communauté générale Ember.js en avait besoin. une méthode .nativeCopy serait vraiment sympa sur Ember.Object mais j'apprécie la nécessité d'être extrêmement sélectif avec les ajouts d'API. Parfois, il est logique d'ajouter une méthode qui rend une opération extrêmement courante plus pratique et parfois ce n'est pas le cas. J'ai l'impression que les gens ne rencontrent pas ce besoin aussi souvent que moi.

Un exemple concret, si vous êtes curieux, est d'utiliser un Ember.Object pour soutenir un formulaire "Créer un nouveau […]". Peut-être que le formulaire de création se trouve juste en dessous d'une liste d'éléments. Si vous utilisez this.store.createRecord pour créer un modèle vierge pour soutenir le formulaire, il ajoute immédiatement un nouvel élément à la liste ci-dessus et remplit les valeurs au fur et à mesure que vous remplissez le formulaire. Pour éviter cela, je pourrais créer un Ember.Object pour sauvegarder le formulaire, mais je dois ensuite extraire les valeurs une par une pour passer à createRecord

Une dernière raison pour laquelle je le fais souvent est de créer une copie en profondeur, car la mise en œuvre de Ember.Copyable est une tâche difficile. J'aime le design de Ember.Copyable mais une implémentation par défaut/générique saine serait vraiment très bien.

La principale raison d'avoir besoin de pojo est la prise en charge d'une bibliothèque tierce. Les tables de données, jstree, etc. attendent tous des tableaux et des objets javascript simples et exploseront avec des structures de données de braise.

@ccarterc comme, par exemple localforage.setItem - c'est PITA avec Ember.Object
Face à elle aujourd'hui et a dû mettre des "échappements" personnalisés pour cela.

A couru dans ce besoin exact aujourd'hui. Comme l'a dit @ccarterc , cela est crucial pour les bibliothèques tierces qui attendent des POJO. Ce serait bien d'avoir une méthode "officielle" pour le faire.

Je veux pouvoir travailler avec un POJO, afin que je puisse envoyer mon objet dans une bibliothèque JS vanille tierce.

oui s'il vous plaît - aux prises avec cela maintenant pour une API tierce. ma solution de contournement actuelle consiste à faire getProperties pour un objet avec un tableau d'environ 70 champs dessus. cela semble idiot et avoir une fonction à faire serait génial...