Ember.js: 3.8.0-beta.1のピリオドを含むキーの各インブレーク

@jasonmitテストに失敗したPRを送信できますか？

私たちは間違いなくこれを根本原因にする必要がありますが、これが最終的にバグと見なされるかどうかはわかりません。 具体的には、 get(obj, 'hello.world')はobj['hello.world']ではなくobj.hello.worldを検索します...

ええ、それが理由だと確信しています。各インはgetを使用するので、これはget with dotpathチケットの複製のようなものです。 たぶん、この特定のケースでは、ES5ゲッターを着陸させた後にget in hereを使用する必要はありません。これは、おそらくプロキシでは機能しないためです。

具体的にはhttps://github.com/emberjs/ember.js/blob/master/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L128

これがバグと見なされるかどうか、そしてこれを今すぐ修正することで他の場所で問題が発生するのか、将来的に問題が発生するのかわからないことに同意します

ええ、私は実際、ここで繰り返されているオブジェクトのヒューリスティックに基づいて、さまざまなことをしていると思います。

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

それらのイテレータのいくつかはget （ ObjectIterator.fromIndexable ）を使用し、いくつかは使用しません（ ObjectIterator.fromForEachable 、 MapLikeNativeIterator.from ）

この場合、 fromIndexableを見ています。 getを使用しない場合の唯一の問題はcpsを使用したpojosだと思います

@ chancancode-ええ、 @ jasonmitがオブジェクトにSymbol.iterable実装させることで問題を回避できる可能性があるため、私はそれを指摘するだけです

@jasonmitテストに失敗したPRを送信できますか？

間違いなく、私は今それを行い、問題をリンクします。

@jasonmitは、オブジェクトにSymbol.iterableを実装させることで問題を

素晴らしいアイデアです。回避策として試してみます。

キーにピリオドがある理由がわからない場合は、繰り返されるオブジェクトのキーはISO文字列（つまり、 2011-10-05T14:48:00.000Z ）であり、UTCオフセットの前にピリオドがあります。

これのステータスが何であるか疑問に思っていますか？ 皆さんありがとう

@ amk221これが解決されたとは思いません。キーのピリオドを回避するためにアプリをリファクタリングすることになりましたが、明らかにすべての人にとって理想的なソリューションではありません。

みなさん、こんにちは。レビューをお願いして、これのPRをしました：D

これを進めるために私にできることはありますか？ 私たちは本当にこれが必要です🤞

@ amk221ヘルパーを追加できます。 それが私が問題を解決した方法です。
しかし、これが重要であることに同意します。

これで数時間を無駄にしました-私はEmberにとても慣れていないので、これは完全に驚くべきことでした。

私のアプリでは、多数のホストのステータスを追跡しているため、IPまたはドメイン名でハッシュを入力します。 localhost以外のすべてについて未定義が返され、私はこれを理解しようと夢中になっていた。

@ devop911あなたのヘルパーを共有するように気をつけてください😁

@ amk221あなたが求めているものではありませんが、私はこれをたくさん使うことになりました：

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

私もこの問題にぶつかりました。 更新はありますか？

getの一般的な使用例を回帰せずに、これを修正できるかどうかはわかりません。 回帰が悪くないことを示すベンチマークを取得できる場合は、これをgetに追加することはおそらく問題ありませんが、そうでない場合は、修正をeach-in直接ビルドする必要があります。 それはまともな回帰だろうと私は思う。

プロキシを手動でチェックし、オブジェクトがプロキシの場合はunknownPropertyを使用できます。それ以外の場合は、 each-inを使用してオブジェクトを反復するときに、通常のget構文を使用します。これは期待どおりに機能する可能性があります。

長期的に追跡された小道具はすぐに来ることができません😩

短編小説：Ember以外のものに切り替えます。 それはすべてのトラブルの価値はありません。

@ devop911のコメントは、それほど建設的でも

これに対する修正はそのうちにわかります。通常の問題よりも少し多くの作業が必要であり、Octaneの出荷機能に重点を置いています。 私は同意しますが、これは重要です。

@pzuraq
キーに名前を付ける方法をユーザーに決定させることは、決してエッジケースにはなり得ません。

@pzuraq少なくとも、 each-inのキーにピリオドが含まれている場合にスローされる警告が必要だと思います。 しかし、回帰を導入せずに優れたソリューションはありません、あなたは正しいです

@ devop911エッジケースであるという私の評価は、この問題が開かれて以来、このバグの報告が全体的にほとんど見られなかったという事実に基づいていました。 これがすべてのEmberアプリケーションが依存する動作である場合、絶対に優先度の高い修正でしたが、キーにピリオドを使用する人はあまりいないようです。

反対に、パフォーマンスを低下させるたびに、多くの苦情が寄せられます。 これがホットパスでなければ、修正は間違いなくずっと早く行われたでしょう。 私が言ったように、特にあなたが物事を成し遂げようとしているとき、メンテナーとしているのは難しい状況です😩誰かがこれに後でではなく早く取り組むようにするために私たちができることを見ていきます

@ rwwagner90動作を修正できると思うので、警告を開始したくありませんが、修正できない場合は、ユーザーに確実に警告する必要があることに同意します。

https://github.com/emberjs/ember.js/pull/18296で修正済み

解決策を考え出してくれてありがとう❤️