Ember Computedプロパティは非同期コードで使用する/含まれることを意味しましたか？

Question

私は経験豊富なEmber.js開発者です。ガイドでは、計算されたプロパティの例を完全な名前（同期、簡単、姓と名義に依存）で見つけることができます。野生では、ただし、非同期的な方法でコンピューティングプロパティの使用法がたくさんあることがわかります（例えば、最初の実行と戻り値はundefined）。

この非同期の計算プロパティを見ると、計算されたプロパティが非同期コードで使用されることが増えています。それはトラブルを求めていませんか？

一般的な問題は、他のComputed Property（CP2）が非同期CP1に依存していることです。 CP2はCP1を取得しますが、undefinedを取得します（CP1は後で非同期で値を設定するため）。 CP2はCP2（undefined）の間違った値で計算を終了します。 CP1はそれ自身を設定しますが、CP2はテンプレート内で参照されないため（CP1が変更されたときに常に再計算され、その値が常に必要です）、CP2はそれ以上再計算されません一部のJavaScript呼び出しで参照されます。

実際の例は、注文のアイテムに基づいた（電子商取引店からの）合計注文の計算です。計算されたプロパティは、アイテムとの非同期関係に依存します。これには、税タイプなどの他の非同期関係が含まれる可能性があります。

Answer 1

計算されたプロパティと約束が混ざっていると思います。そうしないとしない。私はこの問題を複数回見つけました。特に深いネストされたアソシエーションでは問題があります。

私は電子商取引サイトでも作業していました。最初は、サイトのレンダリング時に多くの計算が解決されなかったことがわかりました。その理由は、計算上の財産（計算に使用される）に約束していたからです。後で、結果を計算ロジックに渡す前に、すべての関係を解決する必要があることを認識しました。私はこのステップをサービスで行った。私が意味することを示す一例：

たとえば、注文には多くのアイテムがあり、合計価格を計算するとします。価格はアイテムのフィールドです。代わりの

：

total: Ember.computed("order.items.@.price", function() { 
    return this.get("order.items").reduce((sum, obj) => { 
    return sum + obj.get("price"); 
    }); 
}); 

私はこれを行う：

itemsがどこかに上記の約束の結果として渡され

total: Ember.computed("items.@.price", function() { 
    return this.get("items").reduce((sum, obj) => { 
    return sum + obj.get("price"); 
    }); 
}); 

。

私はこれを見つけましたpostはwhy-you-should-notをよく説明しています。

似たような質問をしました。 Keenはこれについてのより多くのアイデアを聞く。