Ember.js: [グリマー2]「バックトラッキングの再レンダリング」がアサーションになりました

参考までに、アプリにこれらの警告のいくつかがありました。 具体的には、コンポーネントのinit内のサービスの一部のプロパティを更新しました。これにより、ページ上の他の何かが異なるレンダリングをトリガーします。

次の実行ループでプロパティの変更をスケジュールすることで、この警告を修正するのは非常に簡単です。 （かなり大きな）アプリのすべての警告を追跡して修正するのに約1時間かかりました。 これは技術的には重大な変更ですが、追加の作業が発生したとしても、あなたの評価に同意します。

@fivetanleyがここでエラーメッセージを改善するのは思います。 @krisseldenと@stefanpennerには、これらの問題を追跡するためのワークフローがあることを知っています。おそらく、これに関するいくつかの指示を与えるのに役立つ可能性があります。

@joukevandermaas run.next（）は、このエラーの優れた修正ではありませんが、これらのエラーに圧倒されている場合は、なぜそこに行くのかは理解しています。 データの逆流がすでにレンダリングされているものを無効にしている理由を理解することをお勧めします。

おそらく、任意のコンポーネントに注入できるサービスに小道具を設定すると、そのセットがすでにレンダリングされたものを無効にする可能性が高くなります。 一般に、set（）はレンダリングフック中の内部状態でのみ使用され、入力やサービスに関連付けられていない、またはset（）はイベントで使用されるというパターンである必要があります。入力状態は、レンダリングされるまでに解決される必要があります。

@joukevandermaas run.next（）は、このエラーの優れた修正ではありません。

この場合、glimmer2は「重複した作業が発生しているため、パフォーマンスの高いアプリが必要な場合は、これは必要ありません」と通知しているため、パフォーマンスの問題が発生します。 以前の場合、残り火はこれを吸収しますが、パフォーマンスが大幅に低下します。

ここでは、知識を共有するための作業がさらにいくつかあります...最終的には、これがアプリの健全な前進であると信じています。 しかし、私たちは誰もが利益を得るために利用できるツールと知識を持っていることを確認する必要があります:)

Emberの進行状況を比較的密接にフォローしている人（twitter、ここgithub、メーリングリストなど）として、この問題は私にひっかかっているので、Ember 2.10の一部として着陸した場合、特に他の人を驚かせる可能性があると思います。これに関連する非推奨の警告は、動作が3.0までサポートされることを具体的に示しています。 この振る舞いがGlimmer2で機能しないことがどこでも社会化されているのを見たことがないと思います（私は単にそれを見逃したかもしれませんが）。

これがEmber2.10の一部として着陸した場合、特にそれに関連する非推奨の警告が3.0まで動作がサポートされることを具体的に述べているため、これが他の人を驚かせる可能性があると思われます。 この振る舞いがGlimmer2で機能しないことがどこでも社会化されているのを見たことがないと思います（私は単にそれを見逃したかもしれませんが）。

うん、ここでいくつかのメッセージ/詳細を改善する必要があります。

これで2.10リリースになりました。 これは2.10リリースのブログ投稿で言及されますか？

これは2.10のブログ投稿では言及されておらず、前述のように、非推奨の警告では3.0までサポートされると以前に述べられていたため、私は驚きました。

これによって影響を受ける使用パターンがあります。 問題は私の使用パターンであり、この特定の変更ではないと確信していますが、適切な代替使用パターンがどのようなものになるかについての入力が必要です。

基本的に、フィルター可能なデータセットを表示するページがあります。これを実現するために、Emberの計算値を使用して、ページ上のいくつかのクエリパラメーターの値に基づいてデータをフィルター処理しています。 ただし、無効な入力（文字や数字ではないなど）がユーザー入力からquery-paramsに追加されるのを防ぐために、次のパターンがあります。

 filteredModel: Ember.computed('model', /*list of individual query params*/, function(){
    let model = this.get('model').filterBy('pdf.pdf_path.url'); //removes all records that don't have a pdf uploaded
    this.get('queryParams').forEach((filter)=> { // for each possible filter
      if ((this.get(filter).length > 0)) { //if the filter has content...
        //guardian pattern to prevent invalid inputs
        let valid = new RegExp('^[A-Za-z0-9 _]*[A-Za-z0-9][A-Za-z0-9 _]*$');
        while (this.get(filter).length > 0 && !valid.test(this.get(filter))){
          this.set(filter, this.get(filter).slice(0,-1));
        }
        //block of code where the model gets filtered
        //...
        //...
    });
    return model;
  }),

したがって、基本的に、フィルター処理されたモデルがどのように見えるかを計算したときに、フィルター値のいずれかに無効な文字が含まれている場合は、有効になるまで最後の文字を削除します。 誰かがこれらの入力の妥当性チェックを行うためのよりクリーンな方法の提案を持っていますか？

これも驚きでした。特に、アプリが2.9で実行されているときに警告メッセージが表示されなかったためです。 2.10にアップグレードすると、アプリケーションはロードされず、このエラーを参照します。 他の誰かがこの振る舞いを見たことがありますか？

@revanar私はここから完全に離れている可能性がありますが、CPは実際には2つの異なるもののようです。1つはフィルター処理されたモデルを返すCPで、もう1つはフィルターを更新するためのものです。 フィルタ部分の更新をオブザーバブルに移動します。 または、これがコンポーネントであり、クエリパラメータをコンポーネントに渡す場合は、ロジックをdidReceiveAttrsフックに移動します。 「バックトラッキングの再レンダリング」エラーが発生した私の経験から、CPからset操作を移動すると、エラーがなくなるはずだと思います。

これも大変な時期です。 私は多くの問題を修正しましたが、この非推奨エラーが発生している1つの例は不可解です。

Assertion Failed: You modified transitioningIn twice on <app<strong i="6">@component</strong>:link-to::ember1159> in a single render.

残り火の内部プロパティが複数回更新されているため、障害が発生しているようです。 残念ながら、Seleniumテスト中に再現されるため、デバッグが困難です（Seleniumドライバーは、テストの実行中に開発ツールが機能しないようにします）。 サインインプロセスの最後に行われたcontroller.transitionToRoute呼び出しまで、問題の少なくとも1つのインスタンスを追跡しましたが、いくつかの異なるシナリオで発生しているようです。

これのトラブルシューティングを続行する方法がわかりません。

@chancancodeは、この非推奨エラーを無効にするための機能フラグについて言及しましたが、 https：//github.com/emberjs/ember.js/blob/master/FEATURES.mdにそれに関する情報がありません

ember 2.10の移行でも、これが主な問題点です。 これらの問題の多くも修正しています。 これらのエラーを修正するための単一/明確な戦略はないようです。 ユースケースに応じて、以下のアプローチを試みました

1. コードをEmber.run.nextラップする
2. 可能な限り、 setterコードをcomputed propertiesからライフサイクルフックまたはevent handlersに移動します。
3. コンポーネントのライフサイクルフックのさまざまな組み合わせを試す

私たちはこれにも多くの困難を抱えています。 過去数年にわたって、残り火のデータストアキャッシュから特定のタイプの最初の要素を自動的に選択するかなりの量のドロップダウンを蓄積してきました。 これにより、ページの一部がドロップダウン選択によって駆動されるため、再レンダリングが発生します。 ドロップダウンが使用されている各ページのリストの最初の項目を入力して選択するために同じコードを繰り返したくないので、どうすればよいかよくわかりません。

@scottmessingerフィードバックをありがとう。 コンポーネントを使用すると、かなりうまくいくことになりました。 私はなんとかバックトラッキングエラーを取り除くことができました、そして私のコードはそれのためにかなりきれいだと思います。

Kris Seldenには、これらをデバッグするための便利なヒントがあります。

ここで手順の概要を詳しく説明しました： https ：

私はバックトラッキングアサーションメッセージの改善に取り組んでい2.10.2-with-improved-backtracking-assertionビルドをカットしました：

前：

message.message_goal.description回のレンダリングで<(subclass of Ember.Model):ember3486> message.message_goal.description 2回変更しました。 これはEmber1.xでは信頼性が低く低速でしたが、サポートされなくなりました。 詳細については、 https：//github.com/emberjs/ember.js/issues/13948を参照してください。

後：

message.message_goal.description回のレンダリングで<(subclass of Ember.Model):ember3486> message.message_goal.description 2回変更しました。 それはでレンダリングされたcomponent:message-edit-expanding-container-componentとで変更component:rules/predicate-date-value-component 。 これはEmber1.xでは信頼性が低く低速でしたが、サポートされなくなりました。 詳細については、＃13948を参照してください。

準備が整う前にやるべきことがいくつかありますが、数人の人がアプリでこれを試してみると非常に便利です。 / ccで@fivetanley、@bryanhickerson、@revanar、@phammers、@scottmessinger、@ tharrington1、@ manimis902、@jakesjews、@ elwayman02。 アプリに理想的でないアサーションメッセージが表示された場合はお知らせください。

試してみるには、 bower.jsonを更新して、次のように残り火の依存関係を含めます。

{
  "name": "backtracking",
  "dependencies": {
    "ember": "intercom/ember#2.10.2-with-improved-backtracking-assertion",
    "ember-cli-shims": "0.1.3"
  },
  "resolutions": {
    "ember": "2.10.2-with-improved-backtracking-assertion"
  }
}

このビルドを実行しているサンプルアプリケーションは、 https ： 。

1.11.0カナリアビルドをカットしました

これはタイプミスですか？

@rwjblueありがとう、これはタイプミスでした。 更新しました

@GavinJoyceこれを引き受けてくれてありがとう！ 私はこれを私たちのアプリで試しましたが、前のメッセージよりも間違いなく_もっと_役に立ちます。 残念ながら、変更されたと通知されたプロパティは、エラーメッセージで示されたどちらの場所でも明らかに変更されていないため、この問題を簡単に修正することはできません。 その理由はよくわかりませんが、来年はさらに掘り下げていきたいと思います。

@Dhaulagiri興味があれば、

FWIWこれに関連する別の問題を見つけました： https ：

また、タブコントロールを残り火の紙に持ってくるための進行中の取り組みでバグを見つけようとしたときに@GavinJoyceによる

@bjornharrtell私が試すことができる

^残り火の紙の問題に飛び込むのに少し時間がかかりました（https://github.com/miguelcobain/ember-paper/pull/590）。 のようだ：

• 新しいエラーメッセージは、現在のエラーメッセージよりも便利でした
• 生成されたコンテンツを適切に処理できなかったため、完全ではありませんでした。 （ {{yield}}を含むコンポーネントは、有用なソースとして報告されましたが、おそらくそれほど有用ではありませんでした）

アドオンのバグである場合とそうでない場合がありますが、 https：//github.com/DockYard/ember-one-way-controls/issues/136でこのエラーが発生しました

問題が見つかりました。
エントリポイントを持つミックスインを使用して、ミックスされたコントローラーの同じプロパティを更新しています。 これらは明らかに異なるプロパティです。なぜなら、それらは単に異なるコントローラーに属し、アサーションが失敗してjsをブロックするからです。
ミックスインをいくつかのコントローラーにアンラップしてテストし、ルート間を移行して再現しました。再現されませんでした。

今のところ、私はミックスインを取り除こうとしているので、単にそれを殺して回避策を作成します。

この再レンダリングの問題が発生している有効なユースケースがあると思います。 私たちのアプリには、いくつかの状態（OK、検証、警告、エラー）を含むボタンがあります。 これは、現在の状態を表示し、特定のことが発生したときに検証し、検証またはアクティブ化の結果に基づいて、さまざまなもの（スピナー、さまざまなボタンテキスト、さまざまなボタンクラス）を表示するコンポーネントです。

init()で検証を確認し、検証の応答に基づいて、適切なボタンの状態を設定します。 ボタンクラスは、ボタンの状態に基づいて適切なクラスを設定する計算プロパティです。 initで発生するため、インスタンス化時にステータスokで開始し、応答に基づいてバージョンと最終状態を検証しているため、検証に移行するため、このエラーがトリガーされているようです。 ただし、ユースケース自体は妥当であるように思われるため、発生している状態の変化も妥当であるように見えます。

@ tundal45は、間違ったエラーであると思われることを

@ Blackening999 @ tundal45ユースケースをいじくり回すことができますか？

@chancancode @ Blackening999すぐにここに投稿しようと思います。 迅速な対応ありがとうございます。

@chancancode https://ember-twiddle.com/936d549b5625b0cf4f3c945d0ed04d3b?openFiles=components.button-with-state.jsがひねりになり

これはいくつかの計算されたプロパティで見られますが、そのうちの1つは単純なEmber.computed.orです。 この場合、 @ manimis902の提案はどれも当てはまらないので、適切な回避策は何でしょうか。

機能のフラグは@chancancodeで言及されているtharrington1言及

フラグが存在しないことを私が知る限り、 @ cbou

これらの非推奨通知を処理する方法が完全にはわかりませんでした。また、修正が有効かどうかもわかりませんでしたが、 init()コンポーネントフックでAJAXリクエストを実行していたため、別の値の変更がトリガーされました。サービスのプロパティ（リモートサーバーにアクセスするかどうかを追跡/表示するため）。

AJAXリクエストコードをinit()コンポーネントフックからdidRender()コンポーネントフックに移動しましたが、非推奨の通知が解決されたようです。

@ lvl99私も同じことをしました。

エンタープライズプロジェクトを2.3からEmber2.12にアップグレードしようと懸命に取り組んでいます。 私たちのプロジェクトには、検証アドオンと個別のフォームコンポーネントアドオンがあります。 検証アドオンはEmber.componentsで機能して検証エラーを生成し、フォームコンポーネントアドオンはヘルパーを介して検証アドオンによって生成されたエラーを表示します。 アドオンは複雑すぎてソースコードを共有できません。 したがって、私たちが直面しているケースを説明するために、次のひねりを作成しました。

与えられた例には、独自の検証エラーを生成する責任がある2つのコンポーネント（ person-detailとaddress-detail ）が含まれています。 address-detailによって生成された検証エラーは、 errors計算されたプロパティ内でスローされたアクションを介して、含まれているコンポーネント（ person-detail ）にカスケードされます。 各コンポーネントによって生成されたエラーは、ヘルパーerror-formatterの助けを借りて、 error-displayerコンポーネント内に表示されます。 提供されているコードは、ご覧のとおり正常に機能しています。

しかし; 次のような非推奨の警告があります： DEPRECATION: Theエラーproperty ofis an Ember.Binding connected to validatable.errors.name , but Ember.Binding is deprecated. Consider using anエイリアスcomputed property instead. [deprecation id: ember-metal.binding] See http://emberjs.com/deprecations/v2.x#toc_ember-binding for more details.これを回避するため。 ヘルパーerror-formatter移動し、行番号9をコメントアウトし、行番号8のコメントを解除して、警告の説明で提案されているようにします。

今、私たちは悪名高いAssertion Failed: You modified "error" twice on <Ember.Object:ember338> in a single render. It was rendered in "component:error-displayer" and modified in "component:error-displayer". This was unreliable and slow in Ember 1.x and is no longer supported. See https://github.com/emberjs/ember.js/issues/13948 for more details.にぶつかりました。なぜこのエラーが発生するのか理解しています。 address-detail s errors計算プロパティ内でアクションをトリガーすると、 errors計算プロパティのperson-detailが再計算され、既にレンダリングされているコンテンツがこのエラーを引き起こしているためです。 。 これが私たちが学びたいことです：

1. Ember.BindingとEmber.computed.aliasは、再計算（再レンダリング）フェーズに関して、確かにまったく異なる動作をします。 正確な違いは何ですか？ 前者の代わりに後者を使用することを提案することは、コードを壊しているようです。 少なくとも私たちの場合は。
2. 計算されたプロパティ内からアクションをトリガーすることは問題ですか？ そうであれば; それを回避するための可能な提案は何ですか？
3. Ember.run.scheduleOnce('afterRender', ...)ステートメントでトリガーするラッピングアクションを検討しています。 これは正しい方法ですか？
4. ついに; 今すぐコードを壊しているところに戻って、任意のフィールドに何かを入力してください。 驚くべきことに、コンポーネントは複数回再レンダリングされます。 これはバグに関連している可能性があります。

FWIW、場合によっては予想よりも頻繁にコンポーネントが再レンダリングされるのを見てきました。 再レンダリングの原因を追跡することは、実行ループと同期されることが多いため、非常に時間がかかります。 この領域にショートカットやデバッグのトリックがあるかどうか知りたいです。

デバッグビルドでこのアサーションをキャッチまたは抑制する方法はありますか？ ほとんどの場所で上記のようにリファクターを介してこれを追跡して修正しましたが、かなり頑固なものが1つか2つあります。 ある特定のケースでは、オブジェクトを破壊してから遷移します。 破棄されたオブジェクト（API上）は、さらにいくつかのオブジェクトをアンロード/破棄するためにプッシャー通知を送信します。

プロダクションビルドでは、オブジェクトを破棄してからとにかく移行するだけなので、再レンダリングは問題になりません（したがって、ルート全体が破棄されます）。 ただし、開発ビルドでのアサーションは、サイトを復元するために更新が必要なため、非常に苛立たしいものです。 エラーが発生する理由は理解できますが、この場合、エラーを回避するために非常に複雑なリファクタリングが行われ、ルート全体が破壊されているため、いずれの場合も問題ありません。 これをキャッチ/抑制/警告に変更する方法はありますか？ try / catchとルートのエラーハンドラーを試しましたが、どちらも検出しませんでした。

@ feanor07すでにレンダリングされたプロパティを無効にするアクションをget内から送信すると、データの逆流が発生します。サイクルを使用したバインディングでは、順方向が勝者として検出され、サイレントに選択されますが、これがフロースルーされた場合、これには大きなコストがかかります。いくつかのことがあり、ソースに戻ります。

基本的に、循環依存関係があり、データをフローダウンする必要があります。検証を実行する前にエラーをレンダリングしないでください。 モデルとエラーを生成する親コンポーネントで検証して、フォームをブロック内にレンダリングできます。

@ feanor07 Ember.run.scheduleOnce...は機能しませんset Ember.run.schedule("afterRender", () => { ... });を

@neilthawaniはエラーを隠す可能性がありますが、必ずしも問題を解決するとは限りません。 このエラーは、おそらく1回だけ設定する必要があるのに、値を2回設定していることを示しています。 set 1つをscheduleに入れることで、2番目のセットを遅らせて、別の実行ループで発生するようにします。 1回だけレンダリングする必要があるときに、2回レンダリングするという主要な問題は修正されていません。レンダリングが別々の実行ループで行われるようになったため、Emberをだまして問題があったことを認識させませんでした。

@ elwayman02うーん。 ありがとう。 基本的に完全にポイントを逃した。

編集：それで苦労した後、私は私が快適であったよりもいくつかのafterRendersを挿入しました。 データvizコンポーネントの1つに、ツールチップを切り替えるclickハンドラーがあります。 Ember.run.schedule("afterRender", () => { ... });内にisDisplayingフラグを設定すると、実際の問題をデバッグできました。これは、実際には、データvizコンポーネントとツールチップコンポーネントの両方を呼び出すコントローラーのバックトラックでした。

tl; dr：私はそれをそこに保持しませんでした（ Maximum call stack size exceededエラーも一度発生しました）が、実際の問題が明らかになるまで、それを使用することはデバッグに役立ちました。

アップグレードしたばかりの他の人のためのPSA：上記の@GavinJoyceによって言及された改善された「バックトラッキング再レンダリング」アサーションエラーは、実際にはEmber2.11に含まれています。 また、2.11に直接ジャンプすると役立つ場合があることもれています。

みんな、私はいくつかの助けが必要です：このエラーは、別のプロパティに「属する」モデルプロパティを使用しようとすると表示されます。 空白のプロジェクトを作成しましたが、それでも同じことが表示されます。 私は何が間違っているのですか？

また、バックエンドでは、.NetCoreとJSONAPI .Net Core（https://github.com/Research-Institute/json-api-dotnet-core）を使用しています-指示に従います。

この時点でUIレンダリングは壊れていますが、データが読み込まれ、目的の値を確認できます。

    // Profile Model:
    import DS from 'ember-data';
    export default DS.Model.extend({
        'firstName': DS.attr(),
        'lastName': DS.attr(),
        'applicationUser': DS.attr(),
        'contactProfile': DS.belongsTo('address', {
            async: true
        }),
        'companyProfile': DS.belongsTo('address'),
        'companyMailingAddress': DS.belongsTo('address'),
        "companyPhysicalAddress": DS.belongsTo('address')
    });

    // Address Model:
    import DS from 'ember-data';
    export default DS.Model.extend({
        'address1': DS.attr(),
        'address2': DS.attr(),
        'city': DS.attr(),
        'state': DS.attr(),
        'zipCode': DS.attr(),
        'country': DS.attr(),
        'website': DS.attr(),
        'phoneNumber1': DS.attr(),
        'phoneExtension1': DS.attr(),
        'phoneNumber2': DS.attr(),
        'phoneExtension2': DS.attr(),
        'email': DS.attr(),
    });
    // Adapter settings
    import DS from 'ember-data';

    export default DS.JSONAPIAdapter.extend({
        namespace: 'api/json',
    });
    DS.JSONAPISerializer.reopen({
        keyForAttribute(key) {
            return key;
        },
        keyForRelationship(key) {
            return key;
        }
    });
    // Route
    import Ember from 'ember';

    export default Ember.Route.extend({
        model() {
            return Ember.RSVP.hash({
                profile: this.store.findRecord('profile', 1)
            });
        }
    });

    // Template
   {{model.profile.contactProfile.address1}}

そして私が得るエラー：
アサーションに失敗しました：「model.profile.contactProfile」を2回変更しました@model：profile :: ember543：1>単一のレンダリングで。 それに描画された「テンプレート：燃料-燃えさし/内部/プロファイル/ template.hbs 」とに修飾された「テンプレート：燃料-燃えさし/内部/プロファイル/ template.hbs 」。 これはEmber1.xでは信頼性が低く低速でしたが、サポートされなくなりました。 詳細については、 https：//github.com/emberjs/ember.js/issues/13948を参照してください。

PS：プロパティを取得するためにEmber.computedメソッドを使用しようとしましたが、それは機能しているようです。 これは必要ですか？

更新：データが{{#each}}ヘルパー内で正常に読み込まれるが、テンプレートに直接読み込まれないことも発見しました。

@lbarsukov
おそらく、 https：//github.com/emberjs/data/issues/5023に関連しており、バックトラッキングの再レンダリングは、 linksプロパティが設定されているjsonapi応答の関係によって引き起こされます。

これは私にとっての問題であり、Ember Data2.13.2の後に始まりました。 ember-data：2.13.2を使用して、これで問題が解決するかどうかを確認してください。

@ daniel-de-witここでマスターに親指を立てる-これは実際に機能します。 それは今、私がそれをするのに必要なことをします、私はそれに満足しています。

@lbarsukov @ daniel-de-witこの問題を修正する新しいバージョンの残り火データをリリースしました。

@lbarsukovこれはあなたの定義された関係と関係があると思います。 belongsTo 1つ（またはいくつか）がhasManyます。

質問と回答の2つのモデルがあるとします。 質問に対して10の回答を返したが、各質問シリアライザーがその回答を参照している場合は、関係を適切に定義する必要があります。

// Question Model:
    export default DS.Model.extend({
        'answers': DS.hasMany('answers'), // if you never reference question.answers you can omit this
        ...
    });

// Answer Model:
    export default DS.Model.extend({
        'question': DS.belongsTo('question'),
        ...
    });

データが複数の質問/回答のペアの定義に出くわし、存在しない場合は1-1の関係を期待して、レンダリングの途中で質問が変更されたと推測します。

最初の投稿から、いくつかのフックが言及されました：

これはかなり極端な例ですが、問題を示しています。 initに加えて、didInitAttrs、didReceiveAttrs、willInsertElement、およびwillRenderも、レンダリングプロセス中に同期的に発生します。 さらに、バックトラッキングは、双方向にバインドされたプロパティの動作から生じる問題であることがよくあります。

didInsertElementフックとdidRenderフックがチャームのように機能するのに、他のフックがtwice renderエラーで失敗するのはなぜですか？

@BenjaminHorn @ Blackening999 @Dhaulagiri @DingoEatingFuzz @ Gaurav0 @GavinJoyce @Redsandro @TRMW @ Turbo87 @aklkv @alidcastano @backspace @bdiz @bgentry @bjornharrtell @bryanhickerson @buschtoens @caseklim @cbou @chancancode @danaoira @ダニエル・ド・ウィット@fivetanley @fotinakis @gabrielgrant @ghost @jakesjews @janmisek @joukevandermaasこれはまだ問題です、おそらく私たちは閉じる必要があります、あなたはどう思いますか？

アプリのエラーのインスタンスを修正しました。

これに遭遇したときはいつでも、それがもう起こらないように物事を再配置することができたので、閉じても大丈夫だと思います。

はい、閉じてください

時代の終わり😬

👍

古い問題を提起して申し訳ありません。

たとえば、私がレンダリングしているとしましょう

{{this.myBool}}

エラーはError: Assertion Failed: You modified "myBool" twice

次のように変更することでエラーを修正できます。

{{if this.myBool true false}}

同様に、クラス名バインディングが問題を引き起こしている場合

私は変更することができます：

classNameBindings: ['myBool']

に

classNameBindings: ['myBool:yes:no']

このように警告を消すことができるのなら、なぜEmberは私のためにそれを処理できないのですか？

これが私が使っていたデモコードです：

https://ember-twiddle.com/db7f6e382bd0b1de91447881eebb62a5?openFiles=templates.components.my-component.hbs%2C

それらのどれも問題を「修正」しません。 本番モードに切り替えたか、アサーション/検出コードにバグがあります。 いずれにせよ、値を消費する側ではなく、値を割り当てる/設定する側を修正する必要があります。

Ok。 ありがとうございました。 明示的なsetがあるため、この元の投稿で概説されているバックトラッキングの問題を理解しています

しかし、私のデモのひねりでは、私が見る限りsetはありません。

_Edit_それは間違っていました、つまり、例のようにテンプレートの_subsequent_部分からset来ていないということです

うーん、私はひねりでエラーが発生していません、私がすべきクリックのシーケンスは何ですか？

[開く]をクリックしてから、[閉じる]をクリックします。 ただし、親ではなく、生成された子コンポーネントの閉じるボタン。

問題は、ティアダウン中に、既にレンダリングされたプロパティでsetを呼び出すコンポーネントでfocusOutが呼び出されることです。 コンポーネントがどのようにフォーカスとタイミングセマンティクスを失うのか100％わかりません。 あなたが試したバリエーションは、追跡システムを混乱させ、根本的な問題を覆い隠してしまうと確信しています。 新しい号でこれを追跡しましょう。 それが有効な問題かどうかはわかりませんが、そこで調査を行いましょう。