Ember.js: Every-In-Pausen für Schlüssel, die einen Punkt in 3.8.0-beta.1 enthalten

@ Jasonmit Könnten Sie eine PR mit dem fehlgeschlagenen Test senden?

Wir sollten dies definitiv begründen, aber ich bin mir nicht sicher, ob dies am Ende als Fehler angesehen wird. Insbesondere sucht get(obj, 'hello.world') nach obj.hello.world nicht nach obj['hello.world'] ...

Ja, ich bin mir ziemlich sicher, dass dies der Grund ist. Jeder verwendet get, also ist dies eine Art Duplikat des get with dot path-Tickets. Mayyyybe in diesem speziellen Fall müssen wir nach der Landung von ES5-Gettern nicht hier einsteigen, da dies wahrscheinlich sowieso nicht mit Proxys funktioniert?

Insbesondere https://github.com/emberjs/ember.js/blob/master/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L128

Ich bin damit einverstanden, dass ich nicht sicher bin, ob dies als Fehler angesehen wird und ob die Behebung dieses Problems zu Problemen an anderer Stelle oder später führen wird

Ja, und ich denke tatsächlich, dass wir verschiedene Dinge tun, basierend auf den Heuristiken des hier iterierten Objekts:

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

Einige dieser Iteratoren verwenden get ( ObjectIterator.fromIndexable ) und andere nicht ( ObjectIterator.fromForEachable , MapLikeNativeIterator.from ).

Wir betrachten in diesem Fall die fromIndexable . Ich denke, das einzige Problem, wenn man get nicht verwendet, sind Pojos mit cps

@chancancode - ya, ich @jasonmit das Problem möglicherweise Symbol.iterable implementiert

@ Jasonmit Könnten Sie eine PR mit dem fehlgeschlagenen Test senden?

Auf jeden Fall werde ich das jetzt tun und das Problem verknüpfen.

Ja , ich @jasonmit das Problem möglicherweise

Tolle Idee, ich werde das als Workaround ausprobieren.

Falls Sie neugierig sind, warum der Schlüssel Punkte enthält, sind die Schlüssel im Objekt, über die iteriert wird, ISO-Zeichenfolgen (dh 2011-10-05T14:48:00.000Z ), und diese haben Punkte vor dem UTC-Offset.

Sie fragen sich nur, wie der Status davon ist? Vielen Dank an alle

@ amk221 Ich glaube nicht, dass dies behoben wurde. überarbeitet , um den Punkt im Schlüssel zu vermeiden, aber offensichtlich nicht die ideale Lösung für alle.

Hallo allerseits, ich habe eine PR für diese gemacht und um eine Bewertung gebeten: D.

Was kann ich tun, um dies in Gang zu bringen? Wir brauchen das wirklich 🤞

@ amk221 Sie können einen Helfer hinzufügen. So habe ich das Problem gelöst.
Aber stimme zu, dass dies kritisch ist.

Ich habe nur ein paar Stunden damit verschwendet - ich bin super neu bei Ember und das war völlig überraschend.

Für meine App verfolge ich den Status für eine Reihe von Hosts, sodass ein Hash anhand der IP-Adresse oder des Domainnamens eingegeben wird. Es kehrte für alles außer localhost undefiniert zurück und ich machte mich verrückt, um das herauszufinden.

@ devop911 möchte deinen Helfer teilen 😁

@ amk221 Nicht der, den du

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);

Ich habe gerade auch dieses Problem getroffen. Irgendwelche Updates?

Ich bin nicht sicher, ob wir dies beheben können, ohne den allgemeinen Anwendungsfall für get zu regressieren. Wenn wir einen Benchmark erhalten können, der zeigt, dass die Regression nicht schlecht ist, ist es wahrscheinlich in Ordnung, diesen zu get hinzuzufügen, aber wenn nicht, müssten wir den Fix direkt in each-in . Ich vermute, es wäre eine anständige Regression.

Wir könnten manuell nach Proxys suchen und unknownProperty für das Objekt verwenden, wenn es sich um einen Proxy handelt, und ansonsten die normale get-Syntax verwenden, insbesondere wenn ein Objekt mit each-in iteriert wird, was möglicherweise wie erwartet funktioniert.

Langfristig können verfolgte Requisiten nicht früh genug kommen 😩

Lange Rede, kurzer Sinn: Wechseln Sie zu etwas anderem als Ember. Es ist nicht die ganze Mühe wert.

@ devop911 Kommentare wie diese sind nicht sehr konstruktiv oder hilfreich. Wir möchten dieses Problem unbedingt lösen, aber wir möchten auch nicht die Leistung in Benutzeranwendungen für einen Randfall zurückführen, der relativ ungewöhnlich ist. Es ist eine schwierige Situation, als Betreuer zu sein.

Wir werden mit der Zeit eine Lösung dafür finden. Es erfordert nur etwas mehr Arbeit als ein typisches Problem und wir haben uns auf die Versandfunktionen für Octane konzentriert. Ich stimme zu, das ist jedoch wichtig.

@ pzuraq
Lassen Sie die Benutzer entscheiden, wie sie ihre Schlüssel benennen, kann nie ein Randfall sein.

@pzuraq Ich denke, wir sollten zumindest eine Warnung haben, die ausgelöst wird, wenn der Schlüssel zu each-in einen Punkt enthält. Es gibt keine großartige Lösung, ohne Regressionen einzuführen. Sie haben Recht

@ devop911 Meine Einschätzung, dass es sich um einen

Auf der anderen Seite bekommen wir viele Beschwerden, wenn wir die Leistung zurücknehmen. Wenn dies kein heißer Weg wäre, wäre die Lösung definitiv viel früher gekommen. Wie gesagt, es ist eine schwierige Situation, als Betreuer zu sein, besonders wenn Sie versuchen, Dinge zu erledigen. Ich werde sehen, was wir tun können, um jemanden eher früher als später dazu zu bringen, daran zu arbeiten

@ rwwagner90 Ich denke, wir können das Verhalten beheben, daher möchte ich lieber nicht mit der Warnung beginnen, aber wenn wir es nicht beheben können, sollten wir die Benutzer auf jeden Fall warnen.

Behoben durch https://github.com/emberjs/ember.js/pull/18296

Vielen Dank an alle, die eine Lösung gefunden haben ❤️