Ember.js: chaque coupure sur les clés contenant un point dans la version 3.8.0-beta.1

@jasonmit pourriez-vous envoyer un PR avec le test échoué?

Nous devrions certainement enraciner la cause, mais je ne suis pas sûr que cela soit considéré comme un bogue à la fin. Plus précisément, get(obj, 'hello.world') cherchera obj.hello.world non obj['hello.world'] ...

Oui, c'est à peu près sûr que c'est la raison pour laquelle chaque entrée utilise get, donc c'est en quelque sorte une copie du ticket get with dot path. Mayyyybe dans ce cas précis, nous n'avons pas besoin d'utiliser get in here après l'atterrissage des getters ES5 car cela ne fonctionne probablement pas avec les proxys de toute façon?

Plus précisément https://github.com/emberjs/ember.js/blob/master/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L128

Je suis d'accord, je ne suis pas sûr que cela soit considéré comme un bogue et si la résolution de cela maintenant causera des problèmes ailleurs ou plus tard

Oui, et je pense en fait que nous faisons différentes choses en fonction de l'heuristique de l'objet itéré ici:

https://github.com/emberjs/ember.js/blob/7df81ec411b2da73086f63bf6a26b113dfa5a1a2/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L290 -L298

Certains de ces itérateurs utilisent get ( ObjectIterator.fromIndexable ) et d'autres pas ( ObjectIterator.fromForEachable , MapLikeNativeIterator.from )

Nous examinons le fromIndexable dans ce cas. Je pense que le seul problème avec ne pas utiliser get est les pojos avec cps

@chancancode - @jasonmit pourrait éventuellement contourner le problème en faisant implémenter l'objet Symbol.iterable

@jasonmit pourriez-vous envoyer un PR avec le test échoué?

Certainement, je vais le faire maintenant et lier le problème.

oui, je le souligne seulement parce que @jasonmit pourrait éventuellement contourner le problème en faisant que l'objet implémente Symbol.iterable

Excellente idée, je vais essayer ça pour contourner le problème.

Si vous êtes curieux de savoir pourquoi nous avons des points dans la clé, les clés de l'objet en cours d'itération sont des chaînes ISO (c'est-à-dire 2011-10-05T14:48:00.000Z ) et celles-ci ont des périodes avant le décalage UTC.

Vous vous demandez simplement quel en est le statut? Merci a tous

@ amk221 Je ne crois pas que cela ait été résolu, nous avons fini par refactoriser notre application pour éviter le point dans la clé mais évidemment pas une solution idéale pour tout le monde.

Salut à tous, j'ai fait un PR pour celui-ci, demandant un avis: D

Est-ce que je peux faire pour faire avancer les choses? Nous avons vraiment besoin de ça 🤞

@ amk221, vous pouvez ajouter un assistant. C'est comme ça que j'ai résolu le problème.
Mais convenez que c'est essentiel.

Je viens de perdre quelques heures là-dessus - je suis super nouveau à Ember et c'était complètement surprenant.

Pour mon application, je suis le suivi de l'état d'un groupe d'hôtes, donc je saisis un hachage par l'adresse IP ou le nom de domaine. Il retournait indéfini pour tout sauf localhost et je me rendais fou en essayant de comprendre cela.

@ devop911 prend soin de partager votre aide 😁

@ amk221 Ce

import { helper } from '@ember/component/helper';
import _ from 'lodash';

export function hashToArray([h]) {
  return _.map(h, function(value, key) {
    return {
      key: key,
      value: value,
    }
  });
}

export default helper(hashToArray);

Je viens de frapper ce problème aussi. Les mises à jour?

Je ne suis pas sûr que nous puissions résoudre ce problème sans régresser le cas d'utilisation courant pour get . Si nous pouvons obtenir un benchmark qui montre que la régression n'est pas mauvaise, alors c'est probablement bien d'ajouter ceci à get , mais sinon, nous devrons construire le correctif directement dans each-in . Je soupçonne que ce serait une régression décente.

Nous pourrions rechercher manuellement les proxies et utiliser unknownProperty sur l'objet s'il s'agissait d'un proxy, et sinon utiliser la syntaxe get normale spécifiquement lors de l'itération d'un objet en utilisant each-in , qui peut fonctionner comme prévu.

Les accessoires suivis à long terme ne peuvent pas arriver assez tôt 😩

Longue histoire courte: passez à autre chose que Ember. Cela ne vaut pas la peine.

@ devop911 des commentaires comme celui-là ne sont ni très constructifs ni utiles. Nous voulons absolument résoudre ce problème, mais nous ne voulons pas non plus régresser les performances des applications des utilisateurs pour un cas de pointe qui est relativement rare. C'est une situation difficile à vivre en tant que mainteneur.

Nous trouverons un correctif pour cela à temps, cela nécessite juste un peu plus de travail qu'un problème typique et nous nous sommes concentrés sur les fonctionnalités d'expédition pour Octane. Je suis d'accord, c'est important cependant.

@pzuraq
Laisser les utilisateurs décider, comment nommer leurs clés, ne peut jamais être un cas extrême.

@pzuraq Je pense que nous devrions au moins avoir un avertissement qui est lancé si la clé de each-in comprend un point. Il n'y a pas de bonne solution sans introduire de régressions, vous avez raison

@ devop911 mon évaluation du fait qu'il s'agit d'un cas de pointe était basée sur le fait que nous avons vu très peu de rapports de ce bogue dans l'ensemble depuis que ce problème a été ouvert. Si c'était un comportement sur lequel toutes les applications Ember s'appuyaient, cela aurait été un correctif de priorité plus élevée, absolument, mais il semble que peu de gens utilisent des points dans leurs clés.

D'un autre côté, nous _do_ recevons beaucoup de plaintes chaque fois que nous régressons les performances. Si ce n'était pas un chemin chaud, le correctif serait certainement venu beaucoup plus tôt. Comme je l'ai dit, c'est une situation difficile dans laquelle se trouver en tant que responsable de la maintenance, surtout lorsque vous essayez de faire avancer les choses see Je vais voir ce que nous pouvons faire pour que quelqu'un travaille dessus le plus tôt possible

@ rwwagner90 Je pense que nous pouvons corriger le comportement, donc je préfère ne pas commencer à avertir, mais si nous ne pouvons pas le réparer, je conviens que nous devons absolument avertir les utilisateurs.

Corrigé par https://github.com/emberjs/ember.js/pull/18296

Merci à tous d'avoir trouvé une solution ❤️