DiscourseのEmber 4へのアップグレード

Discourse で使用されている Ember のバージョンを更新したいと考えています。

現在、3.15 を使用していますが、4.1 への移行を目指しています。

今年末までにこの作業を完了することを目標としています。なお、本トピックはロードマップであり、すべての計画と推定値は暫定的なものです。特定のアップグレードや変更に関する重要な議論を行う場ではありません。したがって、ここでの会話は焦点を絞って進めましょう。これらのアップデートがあなたのサイト/プラグイン/テーマに与える影響に関する質問は、本トピックの範囲外です。計画されている変更はすべてフロントエンド(Ember アプリ)のみを対象としています。

導入する変更については非常に慎重に進めます。すべての公式プラグイン/テーマは更新されます**(CDCK が顧客のために行ったカスタム作業を含む)**。また、人気のある非公式プラグイン/テーマの更新に向けた PR も送信します。

独自に作成したカスタムプラグイン/テーマをお持ちの方もご安心ください。必要な変更を行うための十分な時間を確保するために、廃止予定の警告を追加し、必要な告知を適時に行います。必要に応じて、これらの変更のサポートも提供いたします。

まずは目標から始めましょう。もちろん利用可能な最高バージョンへの移行を目指していますが、現在から最終目的地までの間に中間目標を設定する必要があります。

段階的なアップデートを行う予定です。4.1 への大規模なアップデートを一度に行うのではなく、この作業を6つのステージに分割します。各ステージは1つの Ember アップグレードに焦点を当てます。

ステージ サイズ アップデート
1 size-l Ember 3.15 → Ember 3.16
2 size-m Ember 3.16 → Ember 3.25
3 size-xl Ember 3.25 → Ember 3.26 (パート1 - 一般)
Ember 3.25 → Ember 3.26 (パート2 - テンプレート)
Ember 3.25 → Ember 3.26 (パート3 - jQuery)
Ember 3.25 → Ember 3.26 (パート4 - Octane 準備)
Ember 3.25 → Ember 3.26 (パート5 - Octane)
4 size-l Ember 3.26 → Ember 3.27 (パート1 - 一般)
Ember 3.26 → Ember 3.27 (パート2 - RenderTemplate)
Ember 3.26 → Ember 3.27 (パート3 - レガシービルトインコンポーネント)
5 size-s Ember 3.27 → Ember 3.28
6 size-s Ember 3.28 → Ember 4.1

これらの特定のバージョンを選択したのは、それらが導入する非推奨機能と作業量、およびそれに伴うリスクに基づいています。

より明確にするために、これらをさらに詳しく分解してみましょう。

アップデートごとの非推奨機能

ステージ 1 (size-l)

Ember 3.15 → Ember 3.16

このアップデートは1つの非推奨機能のみを導入します。

  1. ember-CLI resolver を使用し、レガシーなグローバル resolver を使用しない :link: - 期限: 4.0.0 - size-l

    Discourse には独自の resolver があり、現在 Ember.DefaultResolver を拡張しています。

    推奨される修正は、カスタム resolver をすべて廃止し、Ember-CLI の resolver を使用することです。これは言うは易し、行うは難しで、プラグインやテーマを処理するためのかなりのカスタムロジックを持っているためです。

    代わりに Ember.DefaultResolver を拡張するのではなく、Ember-CLI resolver を拡張するという妥協案が機能します。

ステージ 2 (size-m)

Ember 3.16 → Ember 3.25

このアップデートは8つの非推奨機能を導入します。

  1. @ember/string#loc および {{loc}} :link: 期限: 4.0.0 - :heavy_check_mark:

  2. Without for - Ember のビルトイン非推奨機能 :link: 期限: 4.0.0 - :heavy_check_mark:

  3. Without since - Ember のビルトイン非推奨機能 :link: 期限: 4.0.0 - :heavy_check_mark:

  4. tryInvoke from @ember/utils :link: 期限: 4.0.0 - :heavy_check_mark:

  5. Meta Destruction APIs :link: - 期限: 3.25.0 - :heavy_check_mark:

    これらは使用していないため、ここでは何も行う必要はありません。

  1. Ember getter を使用し、undefined を明示的にチェックする :link: - 期限: 4.0.0 - size-s

    これは単純な非推奨機能です。コードベースから getWithDefault を削除するだけでよく、使用している場所はわずかです。

  2. String prototype extensions :link: - 期限: 4.0.0 - size-m

    これも単純でリスクの低い変更ですが、Ember の拡張された文字列プロトタイプをかなり多くの場所で使用しています。簡単な確認によると、コアとプラグイン/テーマの間で約 100 箇所以下で使用しているようです。 これらを更新した後、次のような設定で Ember がそのプロトタイプを拡張しないようにする必要があります。

    EXTEND_PROTOTYPES: {
       String: false
    }
    

    environment ファイルに追加します。

  3. htmlSafeisHTMLSafe@ember/string からインポートする :link: - 期限: 4.0.0 - size-m

    このアップデートでは #7 と大きな重複があり、単純でリスクが低いはずです。

ステージ 3 (size-xl)

3.25 から 3.26 へのアップグレードはかなり複雑です。ここで大部分の「追いつき」を行います。合計16の非推奨機能があります。このアップデートを5つのパートに分割し、すべての非推奨機能が処理された後にのみバージョンを上げる予定です。

Ember 3.25 → Ember 3.26 (パート1 - 一般)

このパートは、比較的処理しやすい9つの非推奨機能に対応します。

  1. Array Observers :link: - 期限: 4.0.0 - :heavy_check_mark:

  2. Component Manager Capabilities :link: - 期限: 4.0.0 - :heavy_check_mark:

  3. Modifier Manager Capabilities :link: - 期限: 4.0.0 - :heavy_check_mark:

  4. Optional Feature: application-template-wrapper :link: - 期限: 4.0.0 - :heavy_check_mark:

  5. classBinding and classNameBindings as args in templates :link: - 期限: 4.0.0 - :heavy_check_mark:

    これらは使用していないため、何も行う必要はありません。

  1. Transition methods of routes and controllers :link: - 期限: 5.0.0 - size-m

    この非推奨機能は routescontrollers からいくつかのメソッドを削除します。複雑な変更に見えるかもしれませんが、実際には単純です。必要な場合にのみ Router をサービスとして注入し、そこから呼び出すようにすればよいです。難しい点は、これらを多くの場所で使用しており、すべてを更新する必要があることです。

  2. Browser Support Policy :link: - 期限: 4.0.0 - size-s

    ~~これは比較的単純な変更です。Ember は 4.0 以降 IE11 をサポートしなくなります。良い点は、私たちはすでに長い間 IE11 をサポートしていないことです。変更が必要なことは、本番環境で IE11 向けのトランスパイルを停止することだけです。
    discourse/app/assets/javascripts/discourse/config/targets.js at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHub

    いくつかの基本的なテストを行い、この変更により本番環境の Ember-CLI インストールでメインバンドルとベンダーバンドルから約 60kb (gzip) または約 6% を節約できることがわかりました。

  3. {{hasBlock}} and {{hasBlockParams}} :link: - 期限: 4.0.0 - size-s

    これらをいくつかの場所で使用しています。これは単純でリスクの低いリネームです。

  4. {{with}} helper :link: - 期限: 4.0.0 - size-s

    これはほとんど使用していませんが、修正が必要です。{{let}} または {{if}} / {{else}} の組み合わせに置き換えるだけです。

Ember 3.25 → Ember 3.26 (パート2 - テンプレート)

このパートは主に .hbs テンプレートに関連する非推奨機能に焦点を当てます。ここでは3つの非推奨機能に注目する必要があります。

  1. Property Fallback Lookup :link: - 期限: 4.0.0 - size-l

    Ember 4.0 からこれは機能しなくなります。

    Hello, {{name}}!
    

    テンプレートにプロパティがある場合、次のように先頭に this を付けて参照する必要があります。

    Hello, {{this.name}}!
    

    これはすべてのテンプレートで行う必要があります。ここでの痛みを軽減する方法があります。ember-no-implicit-this-codemod を試して、どこまで進められるか見てみましょう。

    1 PR につき 1 ファイルの変更を制限することに賛成です。これにより、レビューが容易になり、問題が発生した場合のロールバックも容易になります。

  2. Accessing named args via {{attrs}} :link: - 期限: 4.0.0 size-xl

    {{attrs}} オブジェクトは Ember 4.0 で削除されます。変更自体は非常に単純で、Ember の例はかなり優れています。

    変更前:

    {{attrs.foo}}
    {{this.attrs.foo.bar}}
    {{deeply (nested attrs.foobar.baz)}}
    

    変更後:

    {{@foo}}
    {{@foo.bar}}
    {{deeply (nested @foobar.baz)}}
    

    これはすべてのテンプレートで行う必要があります。この変更をテンプレートを角括弧構文に変換することと組み合わせることができます。私は角括弧の大きなファンで、標準のカスタムウェブコンポーネント構文に非常に近いからです。

    ここでの進捗を早める可能性があるのは ember-angle-brackets-codemod です。これを実験して、どこまで進められるか見てみましょう。非推奨機能を処理し、輝く角括弧構文を提供してくれます。

    このパートの #1 と同様に、1 PR につき 1 テンプレートを修正してテストすることに賛成です。

  3. <LinkTo> positional arguments :link: - 期限: 4.0.0 - size-m

    これも混乱を減らすことを目的とした非推奨機能です。link-to で位置引数を使用している場所がいくつかあります。これらを次のように修正できます。

    変更前:

    {{link-to "About Us" "about"}}
    {{#link-to "about"}}About Us{{/link-to}}
    {{#link-to "post" @post}}Read {{@post.title}}...{{/link-to}}
    

    変更後 (角括弧を使用):

     <LinkTo @route="about">About Us</LinkTo>
     <LinkTo @route="about">About Us</LinkTo>
     <LinkTo @route="post" @model={{@post}}>Read {{@post.title}}...</LinkTo>
    

Ember 3.25 → Ember 3.26 (パート3 - jQuery)

これについてあなたがすでに知らないことはほとんどありません。新しい Ember アプリは jQuery を使用しておらず、Ember 4.0 で削除されます。

このパートでは1つの非推奨機能に焦点を当てます。

  1. Optional Feature: jquery-integration :link: - 期限: 4.0.0 - size-xl

    過去数年間で、jQuery の使用を減らすために多大な進歩を遂げてきました。まだ必要な場所があり、特にコンポーザーや使用しているいくつかのベンダーライブラリの依存関係です。この変更の詳細には立ち入りません。要するに、jQuery の使用から離れるべきです。

    しかし、強調しておきたいのは、jQuery をどこでも排除しても、Ember 4.0 に準備ができるまでこのオプションを true に設定し続けるべきだということです。制御できないカスタムテーマ/プラグインを持つサイトの移行を円滑にするための計画が必要です。言い換えれば、作業は行いますが、オプションをオフにするに関する非推奨警告と共存します。

Ember 3.25 → Ember 3.26 (パート4 - Octane 準備)

このパートでは、ファイルが Octane に準備できることに焦点を当てます。2つの非推奨機能を処理します。

  1. Optional Feature: template-only-glimmer-components :link: - 期限: 4.0.0 - size-m

    これは理論的には単純な変更ですが、このオプションを切り替える前に行う必要がある暗黙的な作業があります。

    現在のテンプレートのみコンポーネントが glimmer セマンティクスと互換性があることを確認する必要があります。いくつかのテストを行い、このオプションをオンにするとテストが失敗しました。ここにコアにあるいくつかのテンプレートのみコンポーネントの例を示します。

    - app/templates/components/activation-email-form.hbs
    - app/templates/components/cancel-link.hbs
    - app/templates/components/categories-with-featured-topics.hbs
    - app/templates/components/category-name-fields.hbs
    - app/templates/components/color-input.hbs
    - app/templates/components/custom-html-container.hbs
    - app/templates/components/emoji-group-buttons.hbs
    - app/templates/components/emoji-group-sections.hbs
    - app/templates/components/empty-state.hbs
    - app/templates/components/ip-lookup.hbs
    - app/templates/components/modal-footer-close.hbs
    - app/templates/components/popup-menu.hbs
    - app/templates/components/reviewable-created-by-name.hbs
    - app/templates/components/reviewable-created-by.hbs
    - app/templates/components/reviewable-field-editor.hbs
    - app/templates/components/reviewable-field-text.hbs
    - app/templates/components/reviewable-field-textarea.hbs
    - app/templates/components/reviewable-field.hbs
    - app/templates/components/reviewable-flagged-post.hbs
    - app/templates/components/reviewable-post-header.hbs
    - app/templates/components/reviewable-post.hbs
    - app/templates/components/reviewable-scores.hbs
    - app/templates/components/reviewable-tags.hbs
    - app/templates/components/reviewable-topic-link.hbs
    - app/templates/components/score-value.hbs
    - app/templates/components/selected-posts.hbs
    - app/templates/components/subcategories-with-featured-topics.hbs
    - app/templates/components/text-overflow.hbs
    - app/templates/components/user-fields/confirm.hbs
    - app/templates/components/user-fields/dropdown.hbs
    - app/templates/components/user-fields/multiselect.hbs
    - app/templates/components/user-fields/text.hbs
    - app/templates/components/user-profile-avatar.hbs
    - app/templates/components/user-summary-users-list.hbs
    

    また、Admin/テーマ/プラグインのテンプレートを確認し、このオプションをリリースする前にすべてが機能することを確認する必要があります。

    頭の中で、生の .hbr テンプレートがこれにどのように適合するかは正確にはわかりません。ただし、@david は glimmer ベースのトピックリストに取り組んでいます。したがって、生のテンプレートを完全に排除できるかもしれません。

  2. Implicit Injections :link: - 期限: 4.0.0 size-xl

    暗黙的な注入を至る所で使用しています。次のように初期化子で行います。
    discourse/app/assets/javascripts/discourse/app/pre-initializers/inject-discourse-objects.js at ac79c5efc61d259705eeb487ca21d0ec3c535807 · discourse/discourse · GitHub

    Ember は暗黙的な注入から離れています。推奨される進路は、可能な限り多くのオブジェクトをサービスに変換し、必要な場所で明示的に注入することです。もちろん、サービスが最適ではないいくつかのケースがあるかもしれません。そのような場合、必要なときに次のように直接オブジェクトを検索できます。

    getOwner(this).lookup('thing:main')
    

    もう一つのオプション(パフォーマンスへの影響に応じて)は、Ember クラスを独自の Discourse クラスでラップすることです。その後、アプリ全体でこのクラスを使用します。GlimmerComponent Class のように。
    discourse/app/assets/javascripts/discourse/app/components/glimmer.js at fa0c796baf9a7f64a3b27823b1aa4b370a74c3eb · discourse/discourse · GitHub これにより、このタスクは size-l または size-m になります。

    いずれにせよ、この変更にはいくつかの検討が必要です。

Ember 3.25 → Ember 3.26 (パート5 - Octane)

これは 3.25 → Ember 3.26 アップグレードの最終段階です。この時点で1つの非推奨機能が残りますが、それは大きなものです。

  1. Edition: Classic :link: - 期限: 4.0.0 - size-xl

    バージョンを Octane に切り替える前に、クラスをネイティブクラスに変換し、コンポーネントを Glimmer コンポーネントに変換する時間を費やしたいと思います。少しの痛みが伴いますが、それは価値があります。ember-native-class-codemod がその痛みの一部を軽減するはずです。どこまで進められるか見てみましょう。

    考慮すべき点やワークフローの問題がたくさんあります。強調したいのは、テンプレートで述べたのと同じ流れに従うことです - 1 PR につき 1 コンポーネントを修正してテストします。

ステージ 4

Ember 3.26 → Ember 3.27 アップグレードは12の非推奨機能を導入します。これらを3つのパートに分割することを提案します。すべての非推奨機能が処理された後にバージョンを上げます。

Ember 3.26 → Ember 3.27 (パート1 - 一般)

  1. Reopening Classic Component Super Class :link: - 期限: 4.0.0 - :heavy_check_mark:

  2. Class-based template compilation plugins :link: - 期限: 4.0.0 - :heavy_check_mark:

  3. LinkTo @disabled-when argument :link: - 期限: 4.0.0 - :heavy_check_mark:

    これらは使用していないと思うので、ここでは何も行う必要はありません。

  1. Deprecate Route#disconnectOutlet :link: - 期限: 4.0.0 - size-s

    これは1つの場所でしか行っていません。それは build-category-route で、修正は単純です。

  2. Invoking Helpers Without Arguments and Parentheses In Named Argument Positions :link: - 期限: 4.0.0 - size-s

    どこでもこれを行っていないと思うので、時期が来たら確認します。本質的には、引数を渡さずにヘルパーを呼び出すことです。

    たとえそのようなものを使用しても、括弧を追加するだけです。したがって、

    <SomeComponent @arg={{someHelper}} />
    

    <SomeComponent @arg={{(someHelper)}} />
    

    になります。

    someHelper の周りの括弧に注意してください。

  3. Run loop and computed dot access :link: - 期限: 4.0.0 - size-m

    . を使用して computed 関数にアクセスしています。decorators アドオンでこれを行います。例えば、次のようになります。
    discourse/app/assets/javascripts/discourse-common/addon/utils/decorators.js at b05fddaa7ce3968ffc70cd8d4bf290e15d06eb11 · discourse/discourse · GitHub

    また、いくつかの散在するワンオフもあります。私がわかる限り、これらを修正することは主にインポート方法を修正することです。

    したがって、computed.filter は次のようにインポートする必要があります。

    import { filter } from '@ember/object/computed';
    

    外部ベンダーの buffered-proxy アドオンのバージョンは . を使用して computed 関数にアクセスしています。これを上げる必要があります。

    また、いくつかの場所で . を使用して run 関数にアクセスしています。ただし、同じ修正が適用されます。インポート方法を更新する必要があります。特にテーマとプラグインは、run でこれを行う場所がかなりあるかもしれません。

  4. Deprecate the Ember Global :link: - 期限: 4.0.0 - (#size ?)

    Ember は 4.0 以降グローバルコンテキストでは利用できなくなります。詳細な調査なしにここでの作業量/影響を推定するのは難しいです。ただし、@cvx がこのパターンを排除するために多大な作業を行っていることは知っています。

Ember 3.26 → Ember 3.27 (パート2 - renderTemplate)

このパートは1つの非推奨機能にのみ焦点を当てます。

  1. Deprecate Route#renderTemplate :link: - 期限: 4.0.0 - size-l

    要するに、Ember 4.0 では名前付きアウトレットを使用できません。したがって、これは機能しません。

    {{outlet "thing"}}
    

    コアだけで renderTemplate を約 30 の場所で使用しています。アップグレード自体はかなり単純です。{{#in-element}} と、以前の名前付きアウトレットでレンダリングしていたもののプレースホルダーとして単純な空の HTML 要素を使用できます。

Ember 3.26 → Ember 3.27 (パート3 - レガシービルトインコンポーネント)

このパートはビルトインレガシーコンポーネントに焦点を当て、4つの非推奨機能を処理します。

  1. Importing Legacy Built-in Components :link: - 期限: 4.0.0
  2. Built-in Components Legacy Arguments :link: - 期限: 4.0.0
  3. Built-in Components Legacy HTML Attribute Arguments :link: - 期限: 4.0.0
  4. Reopening Legacy Built-in Components :link: - 期限: 4.0.0

これらにサイズを追加しなかったのは… それは本当に依存します。説明しましょう。

CheckboxTextFieldTextAreaLinkComponent などのレガシービルトインコンポーネントは Ember 4.0 で削除されます。これらをかなり多くの場所で使用しており、いくつかの非推奨パターンも使用しています。

Ember はそれらを引き続き使用できるアップグレードパスを提供しますが、異なる方法でインポートする必要があります。ただし、Ember から更新を受け取らず、凍結されたままになります。すべてを排除できることを願っていますが、それは少し複雑かもしれません。この変更は時期が来たときにさらに議論が必要です。

ステージ 5

Ember 3.27 → Ember 3.28

これはバージョンアップのみなので size-s です。3.28 は 3.x 開発サイクルの最後の LTS リリース です。3.27 以降に新しい非推奨機能は導入されず、状況が落ち着くまで数週間停止するのに適したバージョンです。

3.28 LTS は 2022 年 8 月までサポートされます(バグ修正とセキュリティパッチの両方)

この「休憩」にはいくつかの利点があります。

  1. 問題が発生するかどうかを確認する時間が得られます
  2. 安定したバージョンをリリースする場合、それは 3.28 上になります
  3. 自己管理のテーマとプラグインに関する必要な告知を行う時間が得られます
  4. jQuery → no jQuery が可能な限りスムーズになることを確認する時間が得られます。

ステージ 6

数週間経過した後、ようやくバージョンを Ember 4 に上げることができます。

Ember 3.28 → Ember 4.1

これで、3.x サイクルの最後の非推奨機能として、オプションの jQuery 統合をオフに切り替えることができます。

このアップデートは2つの小さな非推奨機能を導入します。

  1. Deprecate Ember.assign :link: - 期限: 5.0.0 - size-s

    コアでは使用していませんが、テーマ/プラグインを確認する必要があります。いずれにせよ、単純なリネームです。

  2. AutoLocation Class :link: - 期限: 5.0.0 - size-s

    理論的には、Ember 環境ファイルで locationType: 'auto'locationType: 'history' に変更するだけで、そのまま機能するはずです。

ワークフロー

冒頭で述べたように、これらのアップデートには非常に注意深く対応します。すべての公式プラグイン/テーマを各アップデートでテスト/修正/固定し、人気のある非公式プラグイン/テーマにも PR を送信します。

ここでの目標は、開発を遅らせたり頭痛の種を作ったりすることではありません。したがって、PR は厳密にスコープされ、1 PR につき 1 つの変更で、大きすぎないものになります。

理想的な世界では、すべての変更は他の人の仕事を中断せずにバックグラウンドで発生します。これが、PR を短く簡潔に保つ理由です。また、混合パターンはあまり好きではありません。したがって、ファイルごとに中間状態に陥りたくありません。コンポーネントは classic か Glimmer のどちらかであり、テンプレートは波括弧か角括弧のどちらかを使用し、その中間はありません。

このロードマップが明確であることを願っています。冒頭で述べたように、これは一般的なトップレベルの概要に過ぎません。不明確、不正確、または気にならないことがあれば、ぜひお知らせください。

コア: すべて完了しました :white_check_mark:

プラグイン:

discourse-events

discourse-data-explorer


@Johani おそらくEmber 4を直接ブロックするものではありませんが、ミックスインもロードマップで検討する価値があるかもしれません。

さらに、Glimmerコンポーネントのような一部の新しいフレームワーククラスは、Emberのミックスインをまったくサポートしていません。将来的には、ミックスインはフレームワークから削除され、直接置き換えられることはありません。

トピックリストがGlimmerコンポーネントに移行し、生のテンプレートを廃止するのはいつ頃になりそうでしょうか?

今後3〜6ヶ月で着手できることを期待していますが、確定ではありません。

現在、「JavaScriptの近代化」チームの主な焦点は、DiscourseをEmber 4.x以降(3.28はすでにEOL)に移行させることです。

Hi @david

興味本位で、テーマ設定についてのおすすめはありますか? Discourse の大幅なテーマ変更(単純化、より「ソーシャルメディア風」にする、開発者中心でなくす、スレッドではなくコメント付き投稿を使用する)を検討しています。

今後 6 か月間で Discourse のフロントエンドに予定されている変更の量を考えると、試みる前に待つべきでしょうか?

Cheers,
Simon

サイモン様

現時点での不確実性から、明確な回答を差し上げることは困難です。

CDCKでは、既存バージョンのコアに対して、お客様向けの新しいテーマを開発中です。トピックリストの書き換えなど、大きな変更は当初オプトインとなるため、適応させる時間は十分にあります。

一般的に、「推奨」API(プラグインのアウトレットなど)を使用し、テンプレートのオーバーライドを避けることで、より簡単な移行パスが得られます。

@david、ありがとうございます。参考になります。

よろしく、
サイモン

Octane の Glimmer と「データダウン、アクションアップ」アプローチを考慮した場合、モデルの変更にどのように対処するのでしょうか?

プラグインのアウトレットに関して課題があることに気づきました。以前は双方向バインディングがありましたが、Glimmer コンポーネントをアウトレットにアタッチすると、そのオプションがなくなります。

プラグインアウトレット経由の双方向バインディングは確立されたパターンであり、場合によってはプラグインアウトレット経由で渡されたモデルを更新したいことがあります。

Ember のドキュメントでこの推奨事項に気づきました。

特に:
「2番目のオプションは、残りのすべてのコンポーネントに対して ember-native-class-codemod を実行することです。これにより、それらは @ember/component からインポートするコンポーネントに変換され、従来のコンポーネントと同じ API をすべて保持しますが、ネイティブクラス構文で表現されます。」

ご意見をお待ちしております。

双方向バインディングの変更は、引数の再代入を指しますが、ミューテーションは引き続き可能です。

たとえば、Glimmerコンポーネントでは次のようなことは許可されていません。

this.args.topic = blah

しかし、このようなこと:

this.args.topic.title = "blah"

は依然として可能です。

実際、{{hash}} を使用して引数を渡す方法のため、現在のところプラグインアウトレットで引数を再代入することはできないと思います。そのため、この点での変更は期待していません。:crossed_fingers:

多くの公式テーマ/プラグインはすでにGlimmerコンポーネントをプラグインアウトレットコネクタとして使用しており、現在のmetaのドキュメントではその方法が説明されています。

Glimmerコンポーネントは、開発者エクスペリエンスの向上とパフォーマンスの向上を提供します。しかし、クラシックコンポーネントからGlimmerコンポーネントへの即時の移行を急ぐ必要はないことに注意してください。クラシックコンポーネントはEmber 5でも引き続きサポートされています。

現時点で最も重要なことは、テーマ/プラグインのすべての非推奨メッセージを解決することです。今後数週間/数ヶ月でアップグレード戦略に関する投稿をさらに行いますが、コアをアップグレードの準備が整うようにするための進捗は順調です。Discourseの実験的なEmber 5.3ブランチもあり、過去数週間、内部インスタンスで正常に実行しています!:tada:

ああ!それは非常に興味深いですね、ありがとうございます!

アップグレードには多くの可能性があることは理解しており、これらすべてにタイムラインを与えるのが非常に難しいことも認識していますが、トピックリストに関して何か進展はありますか?

はい、あります!@cvx が積極的に取り組んでおり、試せるように「experimental glimmer topic list groups」というサイト設定が既にあります。

ただし、まだカスタマイズ性の側面については検討を開始していないため、テーマやプラグインをこれに対して構築しようとしないでください。数週間以内に取り組む予定です。

素晴らしい進歩です!

はい、カスタマイズオプションを可能な限りオープンにしておいていただけると大変助かります。

トピックリストアイテムについて、通常のレイアウトとは全く異なる様々なレイアウトのリクエストが多く寄せられています。

新しい非推奨の通知に気づきました。たとえば、次のようになります。

「代わりに、値トランスフォーマー topic-list-columns およびその他の新しいトピックリストプラグイン API を使用してください。」

これに関するコミュニケーションはありますか(もしかしたら見逃したかもしれません :thinking: )?

はい、来週あたりにはドキュメントが公開される予定です!

まだ「正式な」非推奨メッセージではなく、console.warn の代わりに console.debug を使用してログに記録しているため、デフォルトの Chrome DevTools の設定では表示されません。(cvx さん、ご確認ください)

こちらです @merefield

おお。それは知りたいかもしれません。リンターは console.debug で問題を起こしませんか?

これが私の回答の一部だと思います。

はい!

警告の洪水門を開ける前に、すべてが準備ができていることを確認していたため、それらをdebugにしました。@merefield があまりにも観察眼が鋭く、それでも見つけてしまっただけです :wink:

トピックが公開されたので、すぐに通常の非推奨にアップグレードします :fire:

しかし、自分の開発作業では、console.log ではなく console.debug を使用したい場合があります。ルールとして、私がやっていることについては、自分だけが気にします。