こんにちは@ laco0416-あなたの英語は大丈夫です、心配しないでください！

私はこのアイデアがとても好きです、そしてそれは私たちが以前に議論したものです。 また、 https：//github.com/angular/angular/issues/4062 （ビューイベントの監視）およびhttps://github.com/angular/angular/issues/5467 （親からの監視可能な子イベント）ともよく一致します

誰もがObservablesを使いたがるわけではないことを覚えておくことが重要です（これらの人々は見逃しています！）。したがって、両方のユースケースにオプションを提供する必要があります。したがって、 @Input()直接Observableにすることはほとんどありません。 @ObserveInput()ようなものがあればうまくいくと思います。ベータ版を出荷した後、これらのより興味深い機能のいくつかについて話し合います。

それまでの間、このアイデアの基本的な（そして_非常に_実験的な!!!実際にはこれを行わないでください）実装を次に示します。 これは概念的にあなたが考えていたものですか？ http://plnkr.co/edit/Nvyd9IPBZp9OE2widOcW?p=preview

子コンポーネントの入力プロパティを変更するのは非常に悪い考えだと思います。 入力プロパティは「読み取り専用」である必要があります。 データは常に親から子に流れる必要があります（逆方向には流れないようにしてください）。

@alexpodsここでの考え方はまさにそれだと思います-入力プロパティの変更を_聞く__as_ Observableであり、アップストリームで値を出力しません。これは、私に関する限り、まったく問題ありません。

@robwormald

あなたの英語は大丈夫です、心配しないでください！

ありがとう！ ほっとしました。

あなたの@ObserveInputは私が欲しいものです！
また、 @Inputに重大な変更はありません。 とても良い解決策だと思います。

@alexpods私も全然。

入力プロパティの変更をObservableとしてリッスンし、アップストリームで値を出力しません。これは、私に関する限り、まったく問題ありません。

ロブと同じように思います。

@ laco0416ああ、誤解してすみません。 「子コンポーネントでInputプロパティが変更された場合」というフレーズは、私を混乱させました。

ここにコメントするべきか、それとも新しい問題を開くべきかわかりません。 間違った場所にリクエストを追加する場合はお知らせください。

私はそのようなデコレータを書き込もうとしていましたが（しかし今まで失敗しました）、 @ robwormaldのplunkrに出くわしました。これは、ほぼ完全に機能します（ただし、完全には機能しません）。

このアプローチに私が興奮したのは、それがngOnChangesライフサイクルフックを活用しているという事実でした。
私が見たいのは、_all_ライフサイクルフックをObservablesとして、つまりonChanges$: Observable<{[key: string]: SimpleChange}> 、 onInit$: Observable<{}>などとして公開する方法です。

すべてのライフサイクルフックをObservablesとして利用できるようにすると、すべてのものをRxするのに役立ちます;-)

これに関する更新はありますか？

AFAIK、いいえ。
@robwormald何かニュースはありますか？

私はこれが古いことを知っていますが、これは素晴らしいでしょう！ @robwormaldこれについて何か言葉はありますか？

@robwormaldの@ObserveInputデコレータと同じように、変更する@Inputプロパティ値をObservableとして提供したいと思います。 特に既存の（Angular 1）アプリケーションを移行する場合は、親コンポーネントにObservablesを渡すことが常に可能であるとは限りません。 ただし、単一のコンポーネント内にObservableを「含める」ことができないと、RxJSのパワーとエレガンスを活用することがはるかに困難になります。

残念ながら、ロブはこのバージョンの@ObserveInputを使用しないと言ったとき、冗談ではありません

@ObserveInputより良い実装を管理した人はいますか、それとも公式サポートに関するニュースはありますか？

@lephyrus公式の@ObserveInputデコレータは非常に便利ですが、 @Inputプロパティ値の変更のObservableを取得するために厳密に必要なわけではありません。 デコレータは、単に非常にエレガントな「砂糖」になります。

すでにライフサイクルイベントngOnChangesます。 ngOnChanges内で、rxjs Subjectを使用して、監視可能な変更を作成できます。

<strong i="13">@Input</strong> inputString: string;
private Subject<string> inputString$ = new Subject<string>;

ngOnChanges(changes: { [key: string]: SimpleChange }) {
    if (changes.hasOwnProperty('inputString')) {
        this.inputString$.next(changes['inputString'].currentValue);
    }
}

constructor() {
    inputString$.subscribe(x => {
        console.log('inputString is now', x);
    });
}

または、より再利用可能なものが必要な場合は、コンポーネントがextendsという基本クラスを作成できます。

import { SimpleChange } from '@angular/core';
import { Observable, ConnectableObservable, Observer } from 'rxjs';

export interface TypedSimpleChange<T> {
    previousValue: T;
    currentValue: T;
}

export class ReactiveComponent {
    private changesObserver: Observer<{ [key: string]: SimpleChange }>;
    private changes$: ConnectableObservable<{ [key: string]: SimpleChange }>;

    constructor() {
        this.changes$ = Observable.create((observer: Observer<{ [key: string]: SimpleChange }>) => this.changesObserver = observer).publishReplay(1);
        this.changes$.connect();
    }

    public observeProperty<T>(propertyName: string): Observable<TypedSimpleChange<T>> {
        return this.changes$
            .filter(changes => changes.hasOwnProperty(propertyName))
            .map(changes => changes[propertyName]);
    }

    public observePropertyCurrentValue<T>(propertyName: string): Observable<T> {
        return this.observeProperty<T>(propertyName)
            .map(change => change.currentValue);
    }

    ngOnChanges(changes: { [key: string]: SimpleChange }) {
        this.changesObserver.next(changes);
    }
}

...次のように使用できます：

@Component({
    ...
})
export class YourComponent extends ReactiveComponent {
    @Input() inputString: string;

    constructor() {
        super();
        this.observePropertyCurrentValue<string>('inputString')
            .subscribe(x => console.log('inputString is now', x));
    }
}

公式の@ObserveInputデコレータが利用可能になるまで、このアプローチを使用しています。

ありがとう、@ wmaurer。 あなたのReactiveComponentは大歓迎です、そして非の打ちどころのないコードと安全なタイピングを使って起動します-本当に素晴らしいです！ 重要なのは、テスト中の動作も良好であり、 OnPush変更検出戦略を使用できることです。 「オフィシャルシュガー」をお待ちしております。 （また、 Observable.create()ロジックを使用しなければならなかった理由を理解するときに何かを学ぶと確信しています-まだ調べる時間がありません。）繰り返しますが、mercigäll！ ：ウィンク：

@lephyrusどういたしまして、gärngescheh;-)

私が使用Observable.create()のホールドを取得するためにObserver行うことができるようにするためにnext() 。 ObservableとObserver両方であるSubjectを使用することもできましたが、 Subject （ Observer ）。

@ laco0416はhttps://github.com/angular/angular/issues/13248を支持して終了し

@DzmitryShylovichいいえ。この号で提案されている機能は、読み取り専用でイベント駆動型のデータ受け渡しです。

@ObserveInputはとてもクールになります！ ：+1：

良い例をありがとう@wmaurer 。 質問が1つあります。 文字列の代わりにオブジェクトをオブザーバブルとして使用できるようにしたいと思います。

例えば

@Input() chartConfig: ChartConfig;

constructor(private _reportService: ReportService) {
        super();
             this.observePropertyCurrentValue<string>('chartConfig')
            .subscribe(changedConfig => this.updateChart(changedConfig));
 }

export class ChartConfig {
    public id: string;
    public type: any;
    public data: any;
    public labels: any;
}

ただし、this.updateChartとngOnChangesは呼び出されません。 単純な文字列からサンプルを拡張して、代わりにオブジェクトを観察するにはどうすればよいですか？

@ChrisWorksは、オブジェクトでも

this.observePropertyCurrentValue<ChartConfig>('chartConfig')
            .subscribe(changedConfig => console.log(changedConfig));

私はこれを頻繁に行うので、これが機能しない場合は、コンポーネントへの入力に問題があると思います。

こんにちは@wmaurer 、返信ありがとう

@ChrisWorksは、実際にはそのままobservePropertyCurrentValueは、文字列入力とオブジェクトを区別しません。
これは私が作成した非常に古いng2ベータ0プロジェクトで、入力は文字列だけでなく、すべての異なるタイプです。
https://github.com/wmaurer/todomvc-ng2-reactive
例： https ：

+1このような基本的なユースケースは、まだ並べ替えられていないことを信じられません。

私はついに最良の解決策を手に入れました。それは繰り返しなしでAOTコンパイルで機能します:)秘密は@Input()を2番目のデコレータと組み合わせることです。

デコレータ：

import { ReplaySubject } from 'rxjs/ReplaySubject'                                                                                                 

const subjects = new WeakMap()                                                                                                                     

export function ObservableInput() {                                                                                                
  return (target, propertyKey) => {                                                                                                                
    delete target[propertyKey]                                                                                                                     

    Object.defineProperty(target, propertyKey, {                                                                                                   
      set(value) {                                                                                                                                 
        this[propertyKey].next(value)                                                                                                              
      },                                                                                                                                                                                                                            
      get() {                                                                                                                                      
        let subject = subjects.get(this)                                                                                                           
        if (! subject)  {                                                                                                                          
          subject = new ReplaySubject<any>(1)                                                                                                      
          subjects.set(this, subject)                                                                                                              
        }                                                                                                                                          
        return subject                                                                                                                             
      },                                                                                                                                           
    })                                                                                                                                             
  }                                                                                                                                                
}                                                                                                                                                  

使用法：

class SomeComponent {
  @Input() @ObservableInput()                                                                                                                    
  public index: Observable<number>
}                                                                                                               

編集：私は今これをライブラリにしました。 それを改善するためのアイデアを喜んで受け取ります。 既存の@Inputを次のObservableで補完する新しいメソッドを追加します。 https://github.com/ohjames/observable-inputを参照して

そのようなことをしなければならない場合は、ngOnChangesに類似した単一のサブジェクトを使用したいと思います： Subject<SimpleChanges>
必要に応じて、特定の1つの入力のみをフィルタリングしてマッピングすることもできます。

ゲッターとセッターを作成するためにクラスプロップを削除することについて話さずに、入力ごとに1件の件名が多いようです。入力のタイプが間違っており、 input = valueすると、実際にはオブザーバブルに値が出力されますが、そうではありません。あなたの主題を完了する。

私のアイデアの実装例はここにあります。デコレータアプローチは実験的なものですが、継承アプローチを使用するのはかなり安全だと思います（ここに示すために今行っただけで、使用されていないことに注意してください）。

@ghetolayサブジェクトが完了したかどうかは関係ありません。ビューを閉じると、ストリームへのサブスクリプションはなくなり、GCで

changes$は、 BehaviorSubjectインターフェイスをコンポーネントにリークします。理想的には、 Observable<...>として入力する必要があります。それ以外は、もう少し冗長であれば、合理的と思われます。

多くのサブジェクトの問題については... nサブジェクトを使用している場合でも1を使用している場合でも、 nサブスクリプションがあります。 サブジェクトが1つある場合、各サブスクリプションに1つのマップオペレーターと1つのフィルターオペレーターを追加することになります。これのパフォーマンスオーバーヘッドは、 nサブジェクトを使用する場合よりもはるかに少なくなることはなく、さらに悪化する可能性があります。

入力パラメーター自体の入力を無視して、デコレーターベースのバージョンは、 any基づくSimpleChangeタイプよりも、オブザーバブルのコンシューマーにタイプセーフなAPIを提供します。

@ohjames

ビューが閉じられると、ストリームへのサブスクリプションはなくなり、GCで破棄できます。

すべてのサブスクリプションがビューに関連付けられ、ビューと同じライフサイクルを取得すると想定しています。 Observableがどのように消費されるかについては何も想定していません。

基本的に、オブザーバブルに値を出力することがこのポイントです。 Angularコンパイラは現在、入力プロパティタイプをチェックしていません。うまくいけば、それが実行するまでに、より公式なものが利用可能になるでしょう;）

私はユーザーを対象としていましたが、ユーザーは引き続きプロパティにアクセスして設定できます。 したがって、Observableとして入力されていることを除いて、プロパティを数値であるかのように設定します。これにより、プロパティが設定されることはなく、出力されます。 これは私にとって非常に混乱しています。

多くのサブジェクトの問題については... n個のサブジェクトを使用しているか1個を使用しているかにかかわらず、まだn個のサブスクリプションがあります。 サブジェクトが1つある場合、各サブスクリプションに1つのマップ演算子と1つのフィルター演算子を追加することになります。これによるパフォーマンスのオーバーヘッドは、n個のサブジェクトを使用する場合よりもはるかに少なくなることはなく、さらに悪化する可能性があります。

私たちはすぐに主な目的についての焦点を失うので、ここではこの種の議論には立ち入りません。

Subjectを公​​開しないように更新し、変更に入力を追加するために何かを構築しました。
私はBehaviorSubjectを使用していませんが、単純なSubjectを使用しています。これは、これらのObservableを値の所有者としてではなく、時間の経過とともに変化するものと見なしているためです。
私はちょうど欠陥を見つけました：非同期パイプを使用するとき、非同期パイプは最初の放出の後にサブスクライブするので、最初の値は放出されません。 その場合を適切に処理するために、後でコードを更新します。

ここに再びリンクがあります： //stackblitz.com/edit/angular-observableinput？file = observablechanges％2Fimpl.ts

すべてのサブスクリプションがビューに関連付けられ、ビューと同じライフサイクルを取得すると想定しています。 Observableがどのように消費されるかについては何も想定していません。

わかりました。オブザーバブルを完了すると、すべてのサブスクリプションが強制的に閉じられますが、それは私が本当に心配していることではありません。 私たちのアプリでは、サブスクリプションの99％が非同期パイプを介して発生し、ReduxなどからcombineLatest / switchMapを介して供給される外部オブザーバブルをソースとすることが多いため、手動で閉じる必要がないものもあります。

私たちはすぐに主な目的についての焦点を失うので、ここではこの種の議論には立ち入りません。

さて、あなたは無効な批判を提起したので、それに対抗する必要がありました。

〜継承によるクラスの使用も機能しません。AOTコンパイラによって生成されたコードは、親クラスのライフサイクルメソッドを呼び出しません。https： //github.com/angular/angular/issues/12756#issuecomment-260804139を参照してngOnDestroy() { super.ngOnDestroy() }とngOnChanges別のものを追加する必要があります。〜 <-Angular 4.4以降、特定の制限付きで修正されているようです。

非同期パイプの使用に関する懸念事項を確認しましたが、まだ入力にアクセスできるため、使用法に意味がないと思います。 テンプレートの入力値をバインドするだけの場合は、入力に直接バインドするだけで、ここで監視可能で非同期を使用する必要はありません。 そこから新しいオブザーバブルを作成したい場合は、必要なものを簡単に正確に取得できるはずです（おそらく、どこかでstartWithを使用します）。

だから私は私の前のステートメントは大丈夫だと思います：

私はBehaviorSubjectを使用していませんが、プレーンなSubjectを使用しています。これは、これらのObservableを値の所有者としてではなく、時間の経過とともに変化するものと見なしているためです。 入力値にアクセスする必要がある場合でも、プロパティは引き続き存在し、同期的に参照できます。

このコードは非常に実験的なものであり、一種の概念実証であり、私はそのスタックブリッツでのみ遊んだことがあります。
ですから、申し訳ありませんが、かなり安全だと言うべきではありませんでした。あなたが述べたように、AOTでは機能しない可能性があります。
試してみたところ、どちらのアプローチも現在AOT（angular v4.3.6、cli v1.4.1）で機能します。

ここでの私の主なポイントは、すべての入力の変更を含むchangesオブザーバブルから移動すると、演算子を使用して必要なことをすべて実行できるようになることです。入力が変更されたとき、1つの入力だけが変更されたとき、任意の数の入力が変更されたときに反応します。特定の値から別の値に変更されたときなどに変更されました。
必要なオブザーバブルを作成できます。

また、実装のために管理するサブジェクトは1つだけであり、ユーザーに使用するプロパティは1つであるのに対し、入力ごとに1つです。

私が変更できるのは、 SimpleChangesオブジェクトではなく、新しい値を出力することです。ユーザーはおそらくpairとmapを使用して、 SimpleChangeと同じ種類の構造を取得できるからです。 SimpleChangesなので、後で似たようなものを再構成するためだけにそれを分解するのはばかげています。

PS：

さて、あなたは無効な批判を提起したので、それに対抗する必要がありました。

あなたには無効です。

パフォーマンスについて言及するとき、それは個人的な見解ではありません。これらは客観的な測定可能な事実です。 3つのサブジェクトは、6つの追加のオペレーターよりもオーバーヘッドが大きいと感じます。確かに正しいかもしれませんが、測定を行うまで、それを信じる合理的な根拠はありません。

多くの入力に反応することに関しては... switchMapまたはcombineLatest、あるいは複数のオブザーバブルを操作するために設計された他の演算子のいずれかを使用できることを確認してください。 あなたはこれについて非常に大胆で抜本的な発言をしています。本当にこの会話を続けたいのであれば、この問題追跡システムからそれを外しましょう。

さまざまな欠点と利点があるバージョンがありますが、基本クラスが必要です。

import { OnChanges, OnDestroy, SimpleChanges } from '@angular/core'
import { BehaviorSubject } from 'rxjs/BehaviorSubject'
import { Observable } from 'rxjs/Observable'
import 'rxjs/add/operator/map'
import 'rxjs/add/operator/distinctUntilChanged'

export class ChangeObserver implements OnChanges, OnDestroy {
  protected ngChanges = new BehaviorSubject<object>({})

  ngOnChanges(changes: SimpleChanges) {
    const props = { ...this.ngChanges.value }
    for (const propName in changes) {
      props[propName] = changes[propName].currentValue
    }
    this.ngChanges.next(props)
  }

  ngOnDestroy() {
    this.ngChanges.complete()
  }

  changes<K extends keyof this>(key: K): Observable<this[K]>
  changes<V>(key: string): Observable<V>
  changes(key: string) {
    return this.ngChanges.map(props => this.ngChanges.value[key]).distinctUntilChanged()
  }
}

および使用する：

class MyComponent extends ChangeObserver {
  @Input() public field: string
  // typescript knows this is Observable<string>
  field$ = this.changes('field')

  @Input() private privField: number
  // typescript can't access private stuff from outside the class so we need to help it out
  privField$ = this.changes<number>('privField')
}

問題を誤解したかどうかはわかりませんが、非同期パイプはこの問題を解決しませんか？
[inputVar]="observableValue | async" ..

@najibla誤解しましたが、入力は

@ohjamesは私の場合はうまくいきましたが、

@najiblaこのgithubの問題は、 @Inputプロパティをオブザーバブルに変換することに関するものです。これは、説明しているケースと密接に関連しています。

つまり、ビューで入力プロパティをオブザーバブルに変換する必要はありません。コンポーネントがオブザーバブルを使用して変化する入力プロパティに応答するかどうかは、コンポーネント自体で分離する必要があります。 それ以外の場合、Angularの通常の「オブザーバブルファースト」アプローチと対立するオブザーバブルとしてプロパティを使用することにした場合は、コンポーネントのインターフェイスを変更する必要があります。

@icepeng実際、あなたはそれを

<app-child [prop]="prop$ | async"></app-child>

...次に、 AppChildComponent prop内のAppChildComponentに、オブザーバブルではない場合でもオブザーバブルとしてアクセスする方法を提供します（または、オブザーバブルの場合は、オブザーバブルのオブザーバブルを取得します）。 もちろん、例のように最初にprop$があった場合、それは賢明ではないように思われるかもしれません（すでに、入力を使用してobservableを渡すことができます）。 ただし、渡された入力がまだ監視可能でない場合（たとえば、 indexからのngFor ）、多くの価値が提供されます。

入力でオブザーバブルを渡す際の問題（これは現在完全に可能です）は、 OnPushでは完全に機能しないことです。

@fxck確かに、オブザーバブルがngOnChangesは呼び出されません（入力が同じままであるため）が、非同期パイプを使用して@Input通過したオブザーバブルをサブスクライブする限りOnPushは、非同期パイプが子コンポーネントの変更検出器を手動でトリガーするため、正常に機能します。

はい、@ icepengに向けられました。

@ohjames @fxck情報が間違っていて申し訳ありませんが、現時点でobservableを渡すことが可能かどうかはわかりませんでした。

observableを直接渡すことが可能であるため、 @ObserveInputが役立つかどうかはわかりません。
変更できる値がObservableでなければ、すでに問題だと思います。
個人的な意見です。

@icepengこれを考慮してください：

<ng-container *ngFor="value in (values$ | async); let i = index">
  <child-component [value]="value" [index]="i"></child-component>
</ng-container>

フープを飛び越えずに、ここでオブザーバブルとしてindex消費可能にする方法は？

または、サードパーティのライブラリを作成していて、ライブラリのコンシューマーにオブザーバブルをコンポーネントに渡させたくない場合も考えてください（多くのユーザーはストリームに慣れておらず、rxjsを避けています）。

これが役立つ例は他にもたくさんあります。

@ohjames indexは、各child-component静的な値になるため、監視可能である必要はないと思います。 しかし、今では人々がこの機能を望んでいる理由がわかりました。 そして、あなたのソリューションはサードパーティのライブラリを書くのに適しているようです。

BehaviorSubjectアプローチの方が良いようですが、Angularコアがそのような@NgChanges()デコレータを提供するのであればいいでしょう。

{
  @NgChanges() ngChanges$: BehaviorSubject<{ prop: string }>
  @Input() prop: string;

  ngOnInit() {
    this.ngChanges$.subscribe(changes => console.log(changes.prop));
  }
}

これを実装することは可能ですか？

バッファ長が1のReplayObservableが望ましいです。プロパティにアクセスできる場合は、BehaviourSubjectの値セマンティクスは必要ありません。

実装が可能かどうかについては、さまざまな実装とオプションの問題履歴を確認してください。 素晴らしいものはなく、完全に壊れているものもあります。それを適切に行うには、リンクされたPRなどが必要です。

私の2セント：object.observeがプロキシを優先して減価償却されたため、私の解決策はプロキシを拡張し（はい、わかりません。コンストラクタから返された理由）、これに属するキーをリッスンすることでした。 $ get（keyName）メソッドを介したObservableとしてのオブジェクト。 角度クラス1だけでなく、任意のオブジェクトで使用できます。

import { Observable } from 'rxjs/Observable';
import { Subject } from 'rxjs/Subject';

/**
 * Extends this class to be able to observe any key affectation
 */
class ObservableProxy {
    private changes: Subject<[PropertyKey, any]> = new Subject<[PropertyKey, any]>();

    constructor() {
        return new Proxy(this, {
            set: (object, key, value) => {
                this.changes.next([key, value]);
                object[key] = value;
                return true;
            }
        });
    }

    public $get<K extends keyof this>(key: K): Observable<this[K]> {
        const value: this[K] = this[key];

        const startWith: Observable<this[K]> = Observable.of(value)
            .filter((initialValue) => // remove this filter if you dont mind receiving an undefined value on subscription
                initialValue !== undefined;
            );

        return this.changes
            .filter(([changedKey]) => {
                return changedKey === key;
            })
            .map(([changedKey, nextValue]) => nextValue)
            .merge(startWith);
    }
}

例：

class User extends ObservableProxy {
public name: string;
}

const user: User = new User();
user.$get("name").subscribe((value)=> {
console.log(value);
})

user.name = "toto"; // prints console.log("toto")

@robwormald 、この問題に何か牽引力はありますか？ それは確かに物事を使いやすくするのに大いに役立つでしょう。

@bryanridesharkこれがサポートされる可能性が最も高いのは、 https： //github.com/angular/angular/issues/10185です。PRがこの問題にリンクされていないことに驚いています。

これは、アイビーを出荷するまで発生しません
7:56ジェームズ・パイクの水、2018年2月21日に[email protected]書きました：

@bryanridesharkhttps ：//github.com/bryanridesharkの最高のチャンス
これは＃10185を介してサポートされています
https://github.com/angular/angular/issues/10185私は、驚いたと思います
PRはこの問題にリンクされていません。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/angular/angular/issues/5689#issuecomment-367372931 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAgpkvtGA4w8uHgiz0QsdYwBgqgM2EpAks5tXDyWgaJpZM4Gwr8f
。

あなたの英語は素晴らしく、あなたの角度はより大きくなっています。

@ pldin601お使いのメソッドはAOTコンパイル済みコードをサポートしていないため、ほとんどの人の本番コードで大量のメモリリークが発生します。 代わりに、AOTでうまく機能する私のobservable-inputパッケージをチェックしてください。

@ pldin601コードの問題は、 ngOnDestroyライフサイクルメソッドを動的に追加することです。 AOTでコンパイルされたコードは、コンパイラが静的にその存在を推測できる場合にのみngOnDestroy呼び出します。 したがって、このメソッドは、デコレータを使用するすべてのコンポーネントがngOnDestoryも定義している場合にのみ機能します（不要な場合は空にすることができます）。 他のすべての場合、サブスクリプションがリークし、コンポーネントがガベージコレクションされるのを防ぎます。

私はそれがセクション3.2が完了した後に起こると思います（そしてうまくいけばこの必要性が考慮されます）？
https://is-angular-ivy-ready.firebaseapp.com/#/status

Ivyは7.0.0の一部になりますか？

プロパティを監視可能なコンパニオンプロパティにバインドできるデコレータを実装しました。 角度入力プロパティだけでなく、他のプロパティにも使用できます。 これは@ohjamesの@ObservableInput()デコレータに触発されていますが、別のプロパティを使用してObservableを提供することにより、プロパティゲッターとセッターの間のタイプの不一致によって引き起こされる可能性のある問題を回避します。

https://github.com/PSanetra/bind-observable

例：

class MyClass {

  @BindObservable()
  public myProp: string = 'initialValue';
  public myProp$!: Observable<string>;

}

const myInstance = new MyClass();

myInstance.myProp$.subscribe(console.log);

myInstance.myProp = 'newValue'

このコードは、値'initialValue'と'newValue'をコンソールに出力します。

これまでのところ、これがいつリリースされるかについての更新は、 observable-inputパッケージは、何も壊さず、サブクラス化も行わずに、最もエレガントなように見えます。 @ohjamesこの時点で、これはどの程度安定しているか、十分にテストされていますか？

公式サポートはより成熟し、バージョン間での継続的なサポートとよりスムーズな開発エクスペリエンスを保証し、開発者が完全なrxjs *に移行し、プッシュ変更検出で最適化することを奨励すると思います（これは私の意見のコアとなる画期的な機能です）

*観察不可能な入力との互換性を損なうことなく、またはハイブリッド入力用の追加のボイラープレートを必要とせずに、すなわち：セッターが件名で次に呼び出す

aotの有無にかかわらず、角度4、5、および7で監視可能な入力を使用しました。 それはうまくいくようです。 私がそれを書いたとき、私は自分が何をしていたかを漠然と知っていたと確信しています。

彼らがそれをフレームワークに追加し、その使用を奨励することを願っています2週間のダウンロードnpmは、xDが提供する利点と比較して、十分ではありません。

ユーザー定義のobserverを使用した非同期入力用に次のAPIを提案します

decalre function AsyncInput(bindName?:string) : <T extends Observer>(target: Object, propertyKey: string, descriptor: TypedPropertyDescriptor<T>) => any

ユーザーはそれを次のように使用できます

@AsyncInput()
asynchronusProperty1 = new Subject();

@AsyncInput()
asynchronusProperty2 = new ReplySubject(1);

@AsyncInput()
asynchronusProperty3 = new UserObserver(); // where UserObserver implement `Observer` interface

Angular internalは、値が変更されるたびにobserver.next(newValue)呼び出すことができます。

@HostBindingサポートも忘れないでください！

これをコンストラクター@Inputインジェクションと組み合わせて、さらにすばらしいものにする必要があります。 このようにして、「strictPropertyInitialization」を非常にエレガントな方法で修正できます。

class MyComponent {
  inputData$: Observable<Data>;
  constant: string;

  constructor(
    @Input() inputData$: Observable<Data>,
    @Input() constantString: string
  ) {
    this.inputData$ = inputData$;
    this.constant = constantString;
  }

}

@benneqは、次のように小さい可能性があることに注意してください。

class MyComponent {
  constructor(
    @Input() private inputData$: Observable<Data>,
    @Input() private constantString: string,
  ) {}
}

@ maxime1992はい、ただし、オブザーバブルが1つのコンポーネントから別のコンポーネントに渡される場合を区別するために、オブザーバブルとしての入力用に別個のデコレーターが必要です。

@benneq @ maxime1992パラメータ名はデコレータメタデータの一部ではありませんが、どのようにマッピングしますか？

@trotylそれなら@Input('paramName') private myParam: Observable<Data>使うことができると思います

@ trotyl @ benneqはい私の悪い。 気にしないでください：zipper_mouth_face：

誰かがすでにこのソリューションを投稿したかどうかはわかりませんが、これはかなり良い回避策です

@ElianCordobaこれはHTML <input>に関するものではありません。 それは角度のある@Input()

それは別ですが、同様に苦痛な問題@ElianCordobaです。 https://github.com/angular/angular/issues/13248

これは疑似要件だと思います。 まず、入力デコレータはObservableタイプの値を受け入れることができます。次に、コンポーネントがObservableを入力として必要とする場合、Observableタイプの値に静かに変換するのではなく、観察不可能な値を受け取ったときに明示的にエラーをスローする必要があります。

これは、JavaScriptの暗黙的な型変換と非常によく似ており、バグを引き起こしたり見つけたりするのが難しい場合でも混乱する可能性があります。

それは間違った入力を黙らせることではありません。 これは、コンポーネント間で共通のインターフェースを公開することです（これは観察不可能な入力です）。 これにより、外の世界でインターフェイスを壊すことなく、rx機能を自由に導入できます。 もう1つの利点は、主に可変性と内部状態を持ち上げることです。これは、すべてが入力の変換であり、その時点以降のプッシュ変更の検出が簡単になるためです。

それどころか、オブザーバブルを必要とするインターフェースを公開すると、不格好に聞こえ、コンポーネントが私には奇妙に聞こえると言ったという理由だけで、人々にof（value）を提供するように強制します。

さらに、サイレント変換ではなく、rxjsを介して変更をサブスクライブするためのAPIです。 angle.httpとルーターがオブザーバブルを提供することを考えると、入力変更処理が提供しないのは非常に厄介であり、コールバックとRxJの世界を統合するにはボイラープレートが多すぎます。

上記の巧妙な解決策のいくつかが好きではないというわけではありませんが、「標準的な」方法を少し再編成するだけで、明確さや不器用さの欠如という本当の問題を解決するのに十分な場合があります。 さらに、私はまだこれをいつか行うための「公式の」アイビー後の方法を望んでいます。

@Input('isOuterPanel')
set isOuterPanel(value: CheckoutPanelHeaderSettings)
{
    this.inputs.outerPanel$.next(value);
}

@Input('config')
set config(value: CheckoutPanelHeaderSettings)
{
    this.inputs.config$.next(value);
}

// observables for <strong i="6">@Inputs</strong>
inputs = {
    config$: new BehaviorSubject<CheckoutPanelHeaderSettings>(1),
    outerPanel$: new BehaviorSubject<CheckoutPanelHeaderSettings>(1)
};

次に、 combineLatest(this.service.magicInput$, this.inputs, config$)......ようなものを配置して、入力をRxJSと組み合わせることができます。

BehaviorSubjectまたはReplaySubjectいずれかが機能します。 BehaviorSubjectは通常、より安全で予測可能です。

• BehaviorSubject-デフォルトがある場合に使用します
• ReplaySubject-入力値の設定を忘れた場合、observableは発行されません

これはコードの明確化に役立つだけでなく、すべての入力をグループ化しているため、 this.inputs.と入力してオートコンプリートを取得するだけで、「純粋な」監視可能な入力を簡単に確認できます。

これで型安全性をさらに進めることができます（ほとんどの場合、これは楽しみのためです）。

// define this globally to 'unwrap' a property 'inputs' with an object of ReplaySubject / BehaviorSubject
export type InputTypes<T extends { inputs: { [key: string]: ReplaySubject<any> | BehaviorSubject<any> } }> = {
    [P in keyof T['inputs']]: T['inputs'][P] extends Observable<infer X> ? X : unknown;
}

// define a local 'InputType' helper above each component
type InputType = InputTypes<CheckoutSmartHeaderComponent>;

その場合、 @ Inputプロパティのタイプを明示的に指定する必要はありません。

@Input('config')
set config(value: InputType['config$'])
{
    this.inputs.config$.next(value);
}

コンポーネントにObservableInputsインターフェイスを作成して、 inputsすることもできましたが、これを台無しにするとコンパイルされないため、作成しないことにしました。

@simeylaボイラープレートが多すぎます。

私は自分のデコレータをそこに置くことにしました。 これは私の最初のnpmパッケージなので、何か足りないものがあると確信していますが、ここにあります： https ：//www.npmjs.com/package/@ng-reactive/async -input

インストール

npm install @ng-reactive/async-input --save

使用法

import { Component, Input } from '@angular/core';
import { AsyncInput } from '@ng-reactive/async-input';
import { BehaviorSubject } from 'rxjs';

@Component({
  selector: 'app-hello',
  templateUrl: './hello.component.html',
  styleUrls: ['./hello.component.css']
})
export class HelloComponent {
  @Input() name: string;
  @AsyncInput() name$ = new BehaviorSubject('Default Name');

  constructor() {
    this.name$.subscribe(name => console.log('from async input', name));
  }
}

@ mfp22本当にいいです、このようなものが組み込まれてはいけない理由はわかりません。参考までに、パッケージのnpmのgithubリンクは古くなっています。ここに移動します。

https://github.com/mfp22/async-input/tree/master/projects/async-input

これはかなり古い問題だと思いますが、機能はかなり素晴らしく、Angularでそれを見るのは本当にうれしいです。

さらにクールなのは、監視可能な入力ではOnChangesフックが必要ないことです。 pairwise rxjs演算子を使用して、監視可能な入力の以前の値と現在の値を取得できます。

@Component({...})
class MyReactiveComponent {
  @ObservableInput() prop: Observable<string>; // Whatever syntax may be...

  // emits [prevValue, currValue] and no OnChanges hook yay!!
  propChanges$ = this.prop.pipe(pairwise());
}

https://github.com/rx-ts/ngrx/blob/master/src/utils/decorators.ts#L56 -L124

これは私の個人的な実装であり、完全に機能し、非常に優れています。組み込みが可能であれば、それは本当に素晴らしいことです。

プロジェクトで個人的に使用したソリューションをnpmパッケージとして公開しました。

https://github.com/futhark/ngx-observable-input

インストール

npm install ngx-observable-input

使用法

...
<image-item [url]="currentImageUrl"></image-item>

import { Component, Input } from "@angular/core";
import { ObservableInput } from "ngx-observable-input";
import { Observable } from "rxjs";

@Component({
    selector: "image-item",
    template: `<img [src]="url$ | async" />`
})
export class GalleryComponent {
    @ObservableInput() @Input("url") public url$: Observable<string>;

    ...
}

これはかなり古い問題だと思いますが、機能はかなり素晴らしく、Angularでそれを見るのは本当にうれしいです。

さらにクールなのは、監視可能な入力ではOnChangesフックが必要ないことです。 pairwise rxjs演算子を使用して、監視可能な入力の以前の値と現在の値を取得できます。

@Component({...})
class MyReactiveComponent {
  @ObservableInput() prop: Observable<string>; // Whatever syntax may be...

  // emits [prevValue, currValue] and no OnChanges hook yay!!
  propChanges$ = this.prop.pipe(pairwise());
}

これもしばらくの間私を悩ませてきた問題なので、私は少し調査して、あなたがここで言及しているのと同じ解決策を思いつきました（@gund）。

@Inputデコレータを内部的に拡張し、この種の構成を可能にする小さなデコレータヘルパー（ @ObservableInput ）を実装しました。 ここでチェックできnpmパッケージとしても）。 簡単な例でテストしてきましたが、拡張プロジェクトに使用する時間がありませんでした。 フィードバックは大歓迎です:)

ここに使用例があります：

@Component({
  selector: 'app-test',
  template: `<span>{{ message$ | async }}</span>`
})
class TestComponent {
  @ObservableInput<number>('price') price$: Observable<number>;
  @ObservableInput<string>('name') name$: Observable<string>;

  message$ = combineLatest(this.price$, this.name$).pipe(
    map(([price, name]) => `${name} costs {price}`)
  );
}

そして、このコンポーネントは次のように使用できます。

<app-test [price]="price"
          [name]="name">
</app-test>

@aleicsこれがAOTコンパイラで機能することを確認しますか？

@aleicsこれがAOTコンパイラで機能することを確認しますか？

いいえ、もちろん、 @Inputプロパティは明示的に定義されていないため、すぐに使用できるわけではありません。 ただし、Webコンポーネントを使用する場合のように、モジュールをCUSTOM_ELEMENTS_SCHEMAで定義すると、コンパイルする必要があります。

この号は5年間公開されています🤦‍♂。 リアクティブプログラミングアプローチを容易にするためにこれが必要だと思います

アイビーがついに登場したので、誰かがこれに取り組む時間があると思いますか？ お願いします-お願いします-お願いします！

Omg私はこれが非常に必要であることを購読します。 入力データはリアクティブソースとして出力される必要があり、ngOnChangesで機能させるには回避策を使用する必要があります

本当に楽しみにしています

Angularはオープンソースだと思いますが、Googleが運営するプロジェクトが、5年以内にスターの多い、要求された問題を解決できるはずだと考えるのは間違っているのでしょうか。 GoogleがAngularで作業するためにより多くの開発者を雇うことを妨げている、私が気付いていないいくつかの経済的な問題がありますか？

@ etay2000わかりません

優先順位の連鎖はこのようになっているような気がします

内部のグーグルユーザーの要件->コンパイラーの高速化と関係がある->アプリのサイズが小さいことと関係がある->新規参入者を混乱させないもの->開発者が実際に望んでいること

技術リーダーはそれが重要であることに同意すると言うでしょうが、実際には、IgorとMiskoは、テンプレートのコンパイル、ビューバインディング、およびレンダリングの観点からほとんどの問題について考える傾向があります。 Angularのコンシューマーが何を言っていても、解決策は常にテンプレートシステムを変更するか、新しいレンダラーを作成するか、コンパイラーを改善することです。

ソース：https：//medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9）

最も賛成されている問題のいくつかを見てください。

提案：オブザーバブルとして入力＃5689

5年前に作成され、関連するチームメンバーからの最後の返信-5年前、現在のステータスは不明です。

テンプレート＃13248でコールドイベントストリームをサポートする

4年前に作成され、関連するチームメンバーからの最後の返信-1年前、現在のステータス-アイビーが着陸するのを待っています。

提案：コンポーネントのライフサイクルフックをオブザーバブルとして提供する＃10185

4年前に作成され、関連するチームメンバーからの最後の返信-3年前、現在のステータスは不明です。

提案：コンポーネント宣言でホスト要素にディレクティブを追加する機能が必要です。 ＃8785

4年前に作成され、関連するチームメンバーからの最後の返信-2年前、現在のステータスは不明です。

as local-val * ngIfなし＃15280

4年前に作成され、関連するチームメンバーからの最後の返信-2年前、現在のステータスは不明です。

動的コンテンツプロジェクションのサポート＃8563

4年前に作成され、関連するチームメンバーからの最後の返信-3年前、現在のステータスは不明です。

ng-contentデフォルトコンテンツ＃12530

4年前に作成され、関連するチームメンバーからの最後の返信-決して、現在のステータスは不明です。

次に、コンポーネント機能のように、より高次のコンポーネントを許可するものがあります。もちろん、より多くの賛成の問題がありますが、これらは対処されることを望んでいました（つまり、対処され、必ずしもIvyの直後に実装されることを期待しているわけではありません） ）、フレームワークと反応性の日常的な使用に関係しているため、ほとんどの人が使用しているものです（ngrxが最も人気のある状態管理ライブラリです）。

私のアプリは半分焼き上がったものでいっぱいです（単に技術的な制限のため、コアでしか適切に実行できないものもあります）「ポリフィル」とこれらの問題のほとんどをハックして、いつか角度のあるネイティブにドロップできるようになることを願っています置換。 しかし、どういうわけかそれは来ていないようです。

そうですね、最大の反応性/開発者の経験に関連する問題のいくつかの状態を扱ったブログ投稿が本当にありがたいとしましょう。

この機能の最初のバージョンを自分でコーディングしてみてはどうでしょうか。 私
誰が私に加わりたいのか？

複数の人がすでにしました、例えば。 https://github.com/insidewhy/observable-input

これらのほとんどの問題は、それらを効率的に行うために、コンパイラーまたはAngularの他の内部部分を変更する必要があることです。

それはカウントされません。 つまり、角に適切な貢献をしましょう
芯。 結局のところ、利用可能なソースコードはあります。 実際、この場合、コンパイラーに触れる必要すらないと思います。

@ganqqwertyライブラリを作成する前に、Angular内に実装しようとしました。 ただし、Angularは非常に複雑です。 公平を期すために、コードはReactやそのクレイジーな500行の長さの関数よりもはるかに読みやすく理解しやすいですが、「洗練された」ものです。 そして、それが価値があると思ったなら、私はまだその実装をするための努力をして喜んでいたでしょう。 しかし、 @ fxckが上記で繰り返した理由から、私はそれが価値があるとは思いません。 Angularチームはコミュニティに耳を傾けません。彼らは、一般的なAngularの使いやすさを気にせずに、常に最適化とパフォーマンスにこだわっています。 5年前に実証された単純な問題に対して定型文を実装することを余儀なくされたときに、うまく機能するフレームワークは気にしません。 そこで、Angularのことを気にするのをやめ、すでに取り組んでいるプロジェクトをサポートするために必要な最小限の労力を実装し、将来のすべてのプロジェクトで可能な限りそれを回避することにしました。

これはAngularの問題だけでなく、Googleが提供する多くの問題でもあります。 この問題と上記の@fxckの他の問題は、Googleの固有の問題の単なる例です。 DartまたはGoLangを見ると、開発者が非常によく知られている一般的な問題を提起し、その問題が5年以上続くこともわかります。

これを追加する必要があることに同意しますが、このスレッドに対する嫌悪感は少し大きいです。つまり、数行のコードを節約するものを追加することについて話しているのです。 @Inputで装飾されたセッターと、値をプッシュする独自のサブジェクトを使用して、オブザーバブル入力を使用できるようになりました。

https://github.com/angular/angular/issues/5689#issuecomment -507001686

それが定型的すぎる場合は、すでにいくつかの簡単なサードパーティオプションがあります。

https://github.com/Futhark/ngx-observable-input

私はAngularの開発に満足しており、そのようなささいな（望ましいとはいえ）機能のために、驚くほどフル機能で信頼性の高いフレームワークを放棄することはありません。

一般的な問題は、主に人々がそれをどのように見るかという観点からです。 誰かにとって、それは数行のコードであり、何かを変更/追加するのは非常に簡単に見えますが、実際には、より大きな範囲と多くの副作用がたくさんあります。 それらすべてを考慮に入れる必要があり、いつものように、トピックのラインは長く、すべてにいくらかのコスト、付加価値、および優先順位があります。

私は個人的に、これらの問題のすべてがすぐに解決されるとは限らないことを指摘したいと思います。

しかし、今、アイビーが邪魔にならず、しばらくの間野生に出ていることを願っています。たとえば、上位25の賛成問題に関するある種の公式アップデートが公開されることを願っています。

つまり、このサイズのプロジェクトでは、プロジェクト管理で優先順位を考慮せず、上位25（またはその他）の賛成の問題すべてに対して何らかの計画を立てることはできません。 これらのほとんどには、 effortタグさえあります。 ブログに投稿して、これらについて知っていて、何らかの計画があることをコミュニティに知らせてください。

私は確かにAngularも放棄しません。その欠点はすべて、他のすべての選択肢よりもはるかに優れているからです。 しかし、「コミュニティ関係管理」（具体的にはgithub）が不足していると言っても過言ではありません。

// 編集

良い人はこの世論調査に記入していただけませんか。 あなたの現在の状況と考慮されるすべてのことを考えると、これらの問題のどれがあなたに最も影響を与えます/あなたの開発者の経験を最も改善するでしょうhttps://forms.gle/cprhx239kuqwWd5M8

@fxckそれを書いてくれてありがとう。 Angularチームが好きなときに好きなことをするという事実を誰もが受け入れたのではないかと思い始めていました。 それは確かに彼らの権利ですが、開発者の声を絶えず無視するときは、人々が彼らに声をかける必要があると思います。 誰もが問題の即時解決を期待しているとは思わないことに同意しますが、4〜5年間それらを無視するか、問題が自動的にロックされるまで待つだけでは、Googleが実行するプロジェクトはもちろん、どのプロジェクトでも本当に専門的ではないようです。 彼らは、未解決の問題の束に「Fixed by Ivy」タグを追加することで時間を購入し、その後何もしませんでした。

私は確かにAngularも放棄しません。その欠点はすべて、他のすべての選択肢よりもはるかに優れているからです。 しかし、「コミュニティ関係管理」（具体的にはgithub）が不足していると言っても過言ではありません。

その文章は私の考えを完全に要約していると思います。

@chriszrc私はこのスレッドの何も「憎しみ」として実際には解釈しませんでした。 人々が最終的にAngularでフラストレーションを発散し、一度に何年もの間定期的に問題を無視しているようです。 特にこの問題についてではなく、何らかの形のコミュニティの相互作用を維持するという原則についてです。 Angularチームは、他の誰よりもはるかに優れていると考えられているので、誰にとっても何が最善かを知っているため、開発者の要求を無視できると感じていますか？

@chriszrcこのスレッドには憎しみは見られず、理解できる欲求不満がたくさんあります。 この要求とそれに関連する失望を「数行のコードを節約する」と同一視することは誇張だと思います。 コミュニティを苛立たせているのはこの問題だけではなく、 @ fxckが上で提起した人気のある問題の重要なコレクションが無視されています。

みなさん、こんにちは。このスレッドの沈黙をお許しください。 しばらくの間、2つの直交するリクエストがあります。

1. フレームワークでのファーストクラスのRxJSサポートの向上
2. AngularのRxJSが少なくなり、オプションになる可能性があります

どちらの要求も私たちのレーダーにあり、どちらにも長所と短所があります。 たとえば、最初の方向に進むと、RxJSの表現力豊かで意味的に豊富なAPIを初めて使用するエンジニアが、フレームワークにアクセスしにくくなります。 多くの人々は、Angularアプリのあらゆる場所でRxJSを使用することに懸念を抱いており、さまざまな経験レベルのチームメンバー間でソースコードを読みにくくしています。

同時に、すでに多くのリアクティブAPIがありますが、Angularが提供するプリミティブの一部は完全に必須であり、物事はうまく連携していません。 とはいえ、リアクティブサポートを改善することは理にかなっていますが、これをAngularのコアの一部にするか、緊密に協力しているコミュニティプロジェクト（ngrx-Angularのリアクティブ拡張など）に委任する必要がありますか？

この問題を解決する方法はたくさんありますが、次のことを考慮する必要があります。

• 下位互換性-ソースコードだけでなくトレーニングリソースにも
• 学習曲線
• 現在のAPIとの整合性
• プロジェクト間の一貫性
• パフォーマンス-実行時と初期ロード時間の両方

現在、GitHubの主要な問題のいくつかに優先順位を付け、対処できる最も要求され、影響力のある改善を検討しています。 これは難しいものの1つだと思いますので、デートをするのは難しいです。

@mgechevご返信いただきありがとうございます。 rxjsとリアクティブAPIが（私の個人的な投票ではなく）別の拡張機能に分割される場合、特定の状態ストア/ redux実装と組み合わせない方が理にかなっていますか？ 私はすぐにngrxからngxs（ボイラープレートがはるかに少なく、デコレータでより「角度のある」ように感じました）に移り、最後に秋田に移りました。これは私の現在のお気に入りであり、私が最も開発しているものです。 または、ngrxにまとめられた場合でも、少なくとも必要なパーツを追加するだけで簡単にできるので、ngrxの使用やそれらの依存関係の組み込みに縛られることはありません-

rxjsとリアクティブAPIが別の拡張機能に分割される場合（私の個人的な投票ではありません）

それが起こると言っているのではありません。 私のコメントでは、プロジェクトの範囲と私たちが持っているさまざまな考慮事項を示すことができるように、選択肢の不完全なリストを共有しています。

@mgechev確かに、返信ありがとう

ただし、Angularのリアクティブな部分が何らかの形でコミュニティプロジェクトに「降格」された場合、それはリアクティブがAngularの二級市民になることを意味するのではないでしょうか。

@mgechevあなたの痛みが一度に2つの方向に引き裂かれているのを感じます。 私たちのチームは、実際には命令型/反応型の部分を分割することに反対していません。

このような分割の要件は次のとおりです。

• 命令型と反応型の両方を使用することは、ネイティブであると感じる必要があり、どちらもボルトで固定されていると感じるべきではありません
• 事後対応を可能にする特定の状態管理ソリューションとの連携はありません（完全な開示により、50以上のプロジェクトすべてを秋田を使用するように移行しました）
• 両方のオプションを同時に単一のバージョンでリリースする必要があります（ラグ/遅延なし）
• 「お気に入り」はあり得ません。Angularが行うことは、ネイティブでありながら両方の世界で機能する必要があります。
• Angularチームが支援する両方のアプローチの完全な公式サポート（私たちの経験に基づくと、これは顧客のハードストップ顧客の要件です）

上記に基づく：

• 2つの主なオプションがあります：
  
  
  
  • コア命令+アドオンリアクティブ
  
  
  • コアリアクティブ+アドオン命令
  
  
• 命令型のように見えるようにリアクティブにラップすることは非常に簡単ですが、その逆はそうではありません。
• したがって、コアでリアクティブを使用し、アドオンに命令型APIを含めることに投票します
• 遅延がゼロで、お気に入りの要件がなく、公式のサポートが必要なため、アドオンがコミュニティプロジェクトになる方法がわかりません

上記が私たちの世界観であり、他にもたくさんあることを理解しています。 私がこれを書いている理由は：

• リアクティブをコミュニティプロジェクトに抽出することに着手した場合、50以上のソリューションを別のフレームワークに移行する必要があります（これも顧客主導であり、私たちの選択ではありません）
• ですから、私たち（コミュニティ）にあなたがこれに着陸する場所をできるだけ早く知らせてもらいたいので、私たちは別のフレームワークで開発者を再訓練し、それらのプロジェクトを移行する時間があります

機能を追加してください

@mgechev私はあなたの心配をしません。 この提案は、2つの世界を統一された、初心者向けの簡単なインターフェースと組み合わせることに関するものです。 どちらかを選択するのではなく、組み合わせを可能にすることです。 たとえば、開発者xは、すばらしいリアクティブコンポーネントを構築することにしました。 そして、開発者yは、それほど反応性の低いプロジェクトでそれを使用することにしました。 なぜだめですか？ なぜ彼はngrx接着剤に依存する必要があるのですか？
2つの世界の違いは、最終的なスマートコンポーネントと中央の状態ストアで状態を保存/管理するかどうかです。これがngrxの目的ですが、コンポーネントの場合、フレームワーク自体がイネーブラーである必要があると思います。

しばらくの間、2つの直交するリクエストがあります。

1. フレームワークでのファーストクラスのRxJSサポートの向上
2. AngularのRxJSが少なくなり、オプションになる可能性があります

どちらの方法でも問題ありませんが、これにより、Angularにバラバラな感じがすることがあります。これは、バッテリーを含むフレームワークを除いて、最後に行うことです。

個人的には、すべてのAngularパッケージ（HTTP、ルーター、フォーム）にRxJS以外のバージョンを使用する方法を知りたいと思います。 これらのRxJS以外のバージョンは適切ではないのではないかと思います。そのため、そもそもRxJSがあります。

つまり、何かが足りない場合を除いて、（2）は実行可能ではありません。

PS私はそれらの要求を「直交」とは言いません。 「反対」のようなものです。

AngularのRxJSが少なくなり、オプションになる可能性があります

好奇心から@mgechev 、そのためのGithubの問題はありますか？ （私は何も見ていません。）それともこれはもっとグーグルのものですか？

@pauldraper githubで少なくとも1つの問題が発生しました。誰かが、rxjsがどれほど複雑で、完全にオプションであることを望んでいるのかについて不満を言っています。 個人的にはrxjsが大好きですが、今では2つのチームと協力して、ジュニア開発者とシニア開発者の両方に恐怖と嫌悪感をもたらしました。 また、直交は反対よりも優れた用語です。両方のリクエストを同時に実装できるためです（各ソリューションは、複数のAPIオプションを提供して事後対応的かつ強制的に消費することで、一方が他方を損なうことなく機能できる場合）。

githubのrxjsについて不平を言うコメントごとに、おそらく何千人もの開発者が問題なくそれを使用して楽しんでいます。

これは、Angularの不和について話し合っていたときに、上記で投稿したフォームの結果です（約200人が回答しました）。

当然のことながら、フォームはお尻の最大の痛みですが、どうやら@brandonrobertsと@MikeRyanDevがついに何かを料理しているようです。

githubのrxjsについて不平を言うコメントごとに、おそらく何千人もの開発者が問題なくそれを使用して楽しんでいます。

私はrxjsが大好きですが、私はこれほど楽観的ではありません。 急な学習曲線で何かを学ぶために時間を費やさなければならないという考えが燃え尽きてしまった多くの開発者と一緒に仕事をしたのは悪夢です。 そして、コーディングよりもお金を稼ぐことをはるかに重視する人はたくさんいます：Dまたは、1日の間に学べないことは、ゴミだと思っている攻撃的なジュニア開発者。

急な学習曲線で何かを学ぶために時間を費やさなければならないという考えが燃え尽きてしまった多くの開発者と一緒に仕事をしたのは悪夢です。 そして、コーディングよりもお金を稼ぐことをはるかに重視する多くの人

それらは、Angularがそれに応えようとしている開発者であり、燃え尽きて、学びたくありませんか？ :)そして、とにかくこの時点で誰が気にするか。 Angularはしばらく前から存在しており、どこにも行きません。観察可能なライフサイクル、観察可能な入力、観察可能なイベントを追加しても、トラクションが失われることは絶対にありません。 これらの3つの小さなものを追加するだけで、しばらくの間人々は満足するでしょう（そしてhttps://indepth.dev/component-features-with-angular-ivy/でそれに従って基本パッケージを完成させてください）。

これはすべてを言います。 IMHO Angularは一貫性を保ち、より多くのRxJSを使用する必要があります。RxJSがまったくない場合、Angularにはなりません。

それらは、Angularがその時に対応しようとしている開発者ですか？ :)

はい、rxjsを使用してコードを記述したい開発者のみに対応するのは大げさです。 私はrxjsを使用することを好みますが、Angularが両方の開発者セットに対応できるようにしたいと思います。 なぜAngularは私たちだけに対応し、考え方が違う人には対応しないのですか？ 特に私たちが多数派ではなく少数派にいると私が信じるとき。

繰り返しになりますが、観察可能なライフサイクル、入力、イベントを追加する場合のように「完全に反応」することは、あなたが話しているものにまったく影響を与えませんが、他のグループを非常に幸せにします。

また、コンポーネント機能は、リアクティブプログラミングが好きかどうかに関係なく便利です。

@fxck私は

角度がコアを開発することをどのように決定するかにかかわらず（反応的かどうかにかかわらず）、理想的な世界では、反対のニーズに応えるために反対のパッケージが上に構築されます（たとえば、 @angular/reactiveまたは@angular/imperative -より良い名前でうまくいけば）。

コミュニティに行くこれらの2つのどちらも、私にとっては一部の人々にとっては格下げであり、私にとっては、優れたリアクティブフレームワークであるという見通しを持つ角度がそもそもそれを採用する理由でした。

ちなみに、コアと拡張パッケージの両方の単純さのために言えば、これは命令型からリアクティブ型へのブリッジングよりもブリッジングがはるかに簡単であるため、角度リアクティブを維持し、命令型エクステンションを使用する方が簡単だと思います。

免責事項：私が仮定に基づいて定式化した最後のポイント-コア命令を書く方がはるかに簡単であっても驚くことはありません-拡張リアクティブはより複雑になります。

好奇心から@mgechev 、そのためのGithubの問題はありますか？ （私は何も見ていません。）それともこれはもっとグーグルのものですか？

Googleの内部的なものではありません。 （私がチームに参加したときと同じように）外部要件と内部要件の共通部分がどれほど大きいかに驚かれることでしょう。 主な違いは、ビルドシステムと依存関係の管理にありますが、Google社員にはGoogle社員以外の人とほぼ同じ要件があります。

私たちは何千もの開発者と連絡を取り合っています-多くの外部企業、内部チーム、そして個人の貢献者。 どちらの場合も、RxJSに完全に参加したいと思っている人もいれば、それが自分にとって正しい選択だとは思わない人もいます。 どちらの陣営にも優れた議論があります。

特に、十分に確立された回避策/コミュニティソリューションがあることを考えると、これは急いで決定したい決定ではありません。コミュニティで行われる作業は、追加のデータポイントを収集し、現在の変数セットの最適なソリューションを確立するのに役立ちます。

Angularアプリを開発するときに、1つの統一されたアプローチを反応的または必須（プロジェクトごとの選択）にすることは非常に有益だと思います。 組み合わせて組み合わせる機能は、開発エクスペリエンスを支援したり、非DRYコード（非リアクティブ入力など）を作成したりするのに役立ちません。

単独では何も起こらないので、大量の開発者をリアクティブプログラミングに再トレーニングするのに苦労している企業環境を完全に理解できます。 したがって、命令型を削除すると、実際には企業のスイートスポットからAngularが移動します。これは、Angularのようなフレームワークの大きな主要ユーザーベースを構成するため、現実的には起こりません。

とはいえ、私が現実的であるとは思わないのは、命令型のインターフェースの上にリアクティブなインターフェースを構築することです。 他の方向は、オブザーバブルの出力を変数にいつでも書き込むことができ、それを必須に使用できるため、非常に簡単です。 実際、これは、Angularがカバーの下の多くの場所ですでに行っていることです。

したがって、私はAngularをそのコアで完全にリアクティブにすることに投票し、次にその上に命令型の「ラッパー」を作成します。

このアプローチの主な問題は、命令型ユーザーの移行手順が大きくなる可能性が非常に高いことです。 これは企業環境ではノノであり、Angularチームが防止しようとしていることとまったく同じである可能性があります。したがって、提案はコアで不可欠です。

@mgechevこれは数回提起されているので、リアクティブコア/命令型拡張についてのあなたの考えを聞いて、それが立つための足があるかどうかを聞くのは興味深いでしょう？

どちらの場合も、RxJSに完全に参加したいと思っている人もいれば、それが自分にとって正しい選択だとは思わない人もいます。 どちらの陣営にも優れた議論があります。

素晴らしい、知っておくと良い。 RxJSでフルインすることを定義しますか？ 観察可能なライフサイクル、観察可能な入力、および観察可能なイベントを追加することは、それにどのように適合しますか？ いいえ、これらのいずれにも「十分に確立された回避策/コミュニティソリューション」はありません。

@fxckこれらのどれも実際には「十分に確立された回避策/コミュニティソリューション」を持っていません。

それは本当です。 私はこれらのソリューションの1つを作成しましたが、テンプレートのタイプチェックが不十分であることに依存する1つの大きなハックが原因でのみ機能します。 このスレッドに投稿されている他の解決策もいくつかチェックしましたが、それぞれに次の問題の少なくとも1つがあります。

• サブスクリプションリーク
• ユーザーの定型要件
• 私がライブラリで使用したものと同じくらい悪いハッキングです。

私に関する限り、これをうまく行うことは不可能です。

観察可能なイベントはさらに悪化し、コミュニティソリューションはそれほど多くありません。通常、追加のビルドステップが必要であり（場合によっては、monorepoセットアップでSSRが破損します）、さらにハックします（たとえば、クラス拡張を使用している場合）。ライフサイクルで観察可能なイベントを取得します。Angularはそれをネイティブにサポートしていないためです） https://github.com/typebytes/ngx-template-streams/issues/8

ライフサイクルイベントは間違いなく「最も簡単」ですが、それでもクラス拡張またはカスタムデコレータに依存する必要があり、どちらも理想的ではありません。

@fxck私が知る限り、親クラス（eugh）またはユーザーが自分のdestroyライフサイクルイベントから呼び出さなければならないメソッド（さらに悪い）を使用せずにライフサイクルイベントサブスクリプションをクリーンアップすることはできません。

ライフサイクルイベントは間違いなく「最も簡単」ですが、それでもクラス拡張またはカスタムデコレータに依存する必要があり、どちらも理想的ではありません。

カスタムデコレータを使用してライフサイクルイベントを（リアクティブにするために）実装しようとしましたが、それは苦痛です。 〜クラス拡張なしで、100回のハックなしでそれが可能かどうかはわかりません〜。 角度を拡張するユーザーの可能性はこれまでのところ非常に貧弱であり、それを行うにはハックまたは多くの定型文に依存しています。

@ tonivj5コンポーネント機能がパブリックAPIである場合、これは継承なしでライフサイクルを実装するための潜在的な方法だと思いますか？

@ntziolisはおかしいですが、機能について言及する必要があります。私は実際にngx-sub-formのライフサイクル部分に取り組んでおり、機能はまさに役立つと思います。 それまでの間、コンポーネントファクトリにツタをパッチすることは非常に実行可能です。 これはngx-sub-formの外では非常に便利だと思うので、このロジックを別のライブラリに分割すると思います

@ntziolisこの時点で、Ivyの約束が実際に実行されるのを見ることができるかどうかは

角度効果を確認しましたか？ （ngrx / Effectsではありません） https://dev.to/stupidawesome/reactive-adventures-in-angular-introducing-angular-effects-1epfこのツールを使用すると、完全にリアクティブなアプリケーションを作成できます。
親コンポーネントと子コンポーネント間の双方向の観察可能な状態が含まれています
https://dev.to/stupidawesome/exploring-the-angular-effects-api-2gol
バージョン9.1.0では、Vue3のCompositionAPIに基づくcomposition / hooksモデルが導入されます。
Angularが反応性を処理するための本当に次のステップだと思います。

@mgechev

これは、特に確立された回避策/コミュニティソリューションがあることを考えると、急いでやりたい決定ではありません。

好奇心が強いのですが、私たちと何人のGoogle社員がAngularの意思決定プロセスに積極的に貢献していますか？

あなたはこれが急がれるべき決定ではないことを示します、しかし私はあなたの急いでいないというあなたの定義は何であるか疑問に思いますか？ これは、「Fixed by Ivy」タグを叩き、より多くの開発者が再びノイズを出し始めるまで無視しますか？ リアクティブな作業の対象となるバージョンを念頭に置いていますか、それとも他の新しいコンパイラバージョンを最初にリリースする必要がありますか？

常に2500の未解決の問題があるという事実は、内部の議論でこれまでに出てきますか？

@ ntziolis 、 @ zakhenryが言ったように、 featuresが役立つと思います

@ntziolisライフサイクルで他の試みをしましたが、POCが機能しています（クラス拡張なしで、ライフサイクルインターフェイスを実装していません）。 プライベートAPIに依存しています（：exclamation :)

@ tonivj5 hah私はあなたのソリューションを読む機会がありませんでしたが、私のソリューションもほぼリリースされました:) https://github.com/cloudnc/ngx-observable-lifecycle

私が取り組んでいるlibのアイデアは、他のlibが独自のライフサイクル対応機能を作成するためにフックできる共通ベースを持つことです。 同じフックへのアクセスを必要とする複数の関数がある場合、コンポーネントdefに装飾されたフックが1つだけになるように機能する必要があります。

私はそれをすべて機能させました。CIと単体テストをソートする必要があります。

常に2500の未解決の問題があるという事実は、内部の議論でこれまでに出てきますか？

笑、2019年半ば以降、2500件の未解決の問題はありません。

$ github_issue_stats history -i2m -n20 -sangular/angular

+-------------------------+--------------------+
|         period          |       issues       |
+-------------------------+--------------------+
| This month (2020-05)    | 2855 (+137, -112)  |
| Last month (2020-03)    | 2830 (+495, -550)  |
| 2 months ago (2020-01)  | 2885 (+601, -575)  |
| 3 months ago (2019-11)  | 2859 (+437, -352)  |
| 4 months ago (2019-09)  | 2774 (+411, -305)  |
| 5 months ago (2019-07)  | 2668 (+441, -369)  |
| 6 months ago (2019-05)  | 2596 (+488, -349)  |
| 7 months ago (2019-03)  | 2457 (+425, -373)  |
| 8 months ago (2019-01)  | 2405 (+428, -330)  |
| 9 months ago (2018-11)  | 2307 (+425, -391)  |
| 10 months ago (2018-09) | 2273 (+515, -466)  |
| 11 months ago (2018-07) | 2224 (+641, -541)  |
| 12 months ago (2018-05) | 2124 (+690, -624)  |
| 13 months ago (2018-03) | 2058 (+605, -444)  |
| 14 months ago (2018-01) | 1897 (+773, -679)  |
| 15 months ago (2017-11) | 1803 (+815, -979)  |
| 16 months ago (2017-09) | 1967 (+671, -431)  |
| 17 months ago (2017-07) | 1727 (+664, -518)  |
| 18 months ago (2017-05) | 1581 (+854, -548)  |
| 19 months ago (2017-03) | 1275 (+987, -796)  |
| 20 months ago (2017-01) | 1084 (+671, -505)  |
+-------------------------+--------------------+

私の好みでは、議論なしで開かれた各問題を閉じるプロジェクトよりも、明確なコミュニティの議論/コンセンサスが得られるまで問題を議論に開いたままにするオープンソースプロジェクトを好みます。 また、メンテナが提案を受け入れる可能性を遮断する前に、コミュニティに懸念事項を説明するためのステップでもあります。

@agalazisこの問題は4年半の間開かれており、過去3年間はほとんど無視されています。

@agalazisこの問題は4年半の間開かれており、過去3年間はほとんど無視されています。

Angularチームのメンバーが、なぜこれが5日前にまだ開いているのかを説明して

@ etay2000プロジェクト全体の進化に影響を与えるため、いくつかの決定は難しい場合があり、それは許容できます。開発者は、時間が経つにつれてこの機能に頼ることができないことに気付くことができますが、可能性がある場合は、なぜ時期尚早にそれを殺すのですか？ 提案を却下して問題を解決するのが最も簡単なことだと思いますが、それは理由がありませんでした。

@beeman

Angularチームのメンバーが、なぜこれが5日前にまだ開いているのかを説明していたので、あなたは単に正しくありません。

あなたは本当にそれらの親指を下に向けた絵文字が好きですか？ それは本当に説明でしたか？ 4年以上後、彼は彼らが決定を急がせたくないと言いました。

@agalazis
いくつかの決定が難しいことに同意しますが、それらの難しい決定を延期するための許容可能な時間枠と見なされるべきものは何ですか？ 2855の未解決の問題のすべてがこれらの難しい決定に関係しているわけではありませんが、それらの多くもかなり前から存在しています。

@ etay2000それを受け入れるかどうかは別として、これはオープンソースの人々であり、問​​題を解決するのはメンテナよりもはるかに多いのです。 たとえば、Typescriptプロジェクトでは、2倍近くの問題が未解決であり、そこで行った別の提案にも長い時間がかかりました。 そこでの議論は、機能を持っているほど派手ではないが、他の多くの視点を見ることができた多くの選択肢をもたらしたので、私は気にしません

@agalazisそうですね、私は（誤って）Googleが管理しているオープンソースプロジェクトに、小さなプロジェクトよりも多くのことを期待していたと思います。

@beemanここに親指を下に向けて絵文字を挿入します：-------->

@ etay2000このような重要な決定はそれぞれ、何十万ものもの、プロジェクト、および人々に影響を与えることを常に覚えておく必要があります。 さらに重要なのは、完全ではない決定とパブリックAPIの導入であり、その後すぐにいくつかの重大な変更につながる可能性がありますが、これは単なる悪夢です。 ほぼ各PRで、各ステップがどのようにレビューされているかを確認できます。完全ではない場合は、数週間、数か月、さらには数年待つだけです。

@agalazisそうですね、私は（誤って）Googleが管理しているオープンソースプロジェクトに、小さなプロジェクトよりも多くのことを期待していたと思います。

わかりません。Goとdartも見てください。 グーグルは実際に半年間非常に人気のあるコミュニティの要求を無視することでかなり有名です：D一般的に言語/フレームワークなどへの彼らのアプローチ。 非常に保守的です。 地域に革命をもたらす新しい言語やアイデアが出現し、グーグルはまだ何年もそれらを採用していないのを見ることができます。 この種のアプローチには長所と短所があると思いますが、少なくとも私にとっては、Googleが開発したものは私の精神にあまり合わないため、可能な限り避ける傾向があります。

（申し訳ありませんが、皆さん、私はそれをしなければなりません。）

@beemanここに親指を下に向けて絵文字を挿入します：-------->

@ etay2000ここでの行動違反ではないにしても、この種のコメントがどのように役立つのかはまったくわかりません。 誰もが親指を下ろす方法を知っていると確信しているので、皮肉のポイントは何ですか？

念のために言っておきますが、Angularの使用を強制されることはありません。人々があなたをもっと喜ばせる、別のフレームワークを見つけることを試みることができます。

@brunojcmコメント警察が来たので、パーティーは終わったと思います。 重要なのは、彼が私の他のすべてのコメントを否定したことでしたが、皮肉が行動違反であることに気づきませんでした。

念のために言っておきますが、Angularの使用を強制されることはありません。人々があなたをもっと喜ばせる、別のフレームワークを見つけることを試みることができます。

私が本当にそれに応えたいと思う方法は、間違いなくここの行動規範に違反するでしょう。

完了しました。誰もが定期的にスケジュールされている番組に戻ることができます。 あと4〜5年後にもう一度チェックして、状況がどうなったかを確認します。

@ tonivj5 @ zakhenryこれが道かもしれないと聞いてうれしいです。

@mgechevこれは予備的な議論ではないことを理解していますが、あなたの考えを聞いて

• リアクティブコア+非リアクティブエクステンションとその逆。
• この問題に固有なのは、何らかの方法で機能APIを公開する現実的な可能性があることです。
  
  
  
  • 一般的な機能にアクセスできる限り、将来的に変更を壊すという警告があったとしても。
  
  
  • @zakhenryがライフサイクルイベントに対して行ったように、これらのAPIに直接アクセスする代わりに、他のユーザーが使用できるAPIを構築しているプロジェクトの数が1つまたは非常に限られていることがわかります。
  
  
  • 次に、これらのラッパーチームと協力して、今後の重大な変更について早い段階で通知することができます（リアクティブ拡張に関する提案と非常によく似ています）。
  
  

Vue 3.0のリアクティブモジュール（refまたはreactive）を直接適用して、この問題を解決できると思います。

@AnonymousArthurパッケージ@vue/reactivityについて話している場合、プロパティへの反応性を提供し、相対ストリーム（RxJとは）とは関係がないため、ここで説明している内容とはまったく関係ありません。

@gundはい、同意します。 ただし、この会話にはかなり長い時間（4。5年）がかかり、まだ終了していません。そのため、サブスクライブ/アンサブスクライブまたはngOnChangeハンドラーを作成したくないアイデアをすぐにポップアップします（そうでない場合もあります）。 RxJSは反応性機能を提供し、この会話（すべてを読んでいませんでした）は、入力値を構文糖衣としてObservableでラップして、それを監視できるようにすることについて話しているので、素晴らしいアイデアだと思います。

このアイデアは本当に便利で、最初の@robwormaldのプロトタイプは素晴らしく見えますが、潜在的なメリットと影響がどれほど少ないかを過小評価していると思います。

いくつかの欠点を修正するために、そのソリューションを少し調整することを提案しますが、基本的に同じアプローチです。

定義する角度デコレータ@OInput()とタイプEventReceiver<T>延びるObservable<T>も追加.valueゲッター（などBehaviorSubject<T> ）。

親コンポーネント側では、 @ robwormaldの例のように、何も変更されません。 そこにObservable値を渡したい場合でも、 | asyncが必要です。 または、（いつものように）それでも問題ない、観察不可能なタイプを渡すことができます。

子コンポーネント側では、次のように提案します（その提案からのわずかな逸脱）：

@Component({ selector: "child" })
class Child {
  // Notice, this parallels the patterns of `@Output()`.
  @OInput() foo = new EventReceiver<MyType>();

  constructor() {
    // The reactive way to listen to input changes in the class.
    this.foo.subscribe((v) => {
      console.log('foo changed', v);
    });
    // Or you can bind to `foo | async` in the template.
  }

  // But this would also support less reactive patterns in parallel,
  // both for ease of migration and for cases where developers don't
  // want to migrate fully. 
  ngOnChanges(changes: SimpleChanges) {
    if (changes['foo']) {
      console.log('foo changed', changes['foo'].currentValue); // Unchanged
      console.log('foo changed', this.foo.value);  // Previously this would have been just `this.foo`
    }
  }
}

ここに、このアプローチの利点があります。これは、少し売られていなかったように感じます。

• これにより、必要に応じて、親コンポーネントと子コンポーネントの両方で効果的に完全にリアクティブな設計が可能になります。
• 親コンポーネントで、Angularの既存の入力デザインパターンを維持します。これにより、コンポーネントがこれに強制されたり、その周りをデザインしたりする必要がなくなります。
• 親と子のコンテキストは完全に独立しています。親は、子がInputとOInputどちらを使用しているかを知る必要がないため、この変更によるコンポーネント間のバグのリスクが排除されます。
• Angularはこれらすべてを以前と同様に既存のライフサイクルイベントに接続したままにするため、必要に応じて、単一の子コンポーネントを部分的に移行するのは比較的簡単です。
• Angularはこの機能を実装しているため、すべてのEventReceiverは、 takeUntil(ngOnDestroyEvent)を通るパイプを内部的に含めることができます。したがって、これらのオブザーバブルは自動的に完了するため、ほとんどの場合、コンポーネントが破棄されたときに登録を解除することを覚えておく必要はありません。 。 （メモリリークが減りました！）
• この子コンポーネントでは、これは今日の@Output()のパターンと非常によく似た外観と機能を備えているため、いくつかの優れた並列処理と、それらを適切に接続する潜在的な機能を提供します。
  
  
  
  • 補足：フォローアップとして、 ReplaySubject<T>(1)を使用して双方向バインディングの動作をよりシームレスかつ一貫して接続する@InputOutput()を提案するのはクールだと思います。 しかし、それには独自の課題と議論があるので、ここではそれを提案していません。
  
  
• これを機能させるための新しいタイプの定型文はありません。これは@Output()と同じくらい簡単です。
• Angularは、親によって入力されたObservableへの変更に対してシームレスにswitch()になるため、同じObservableインスタンスに固執しないような弱い反応パターンは特別な場合（ switch()必要はありません。

私が選んだOInputという名前についての補足：明らかに、それは議論の余地があります。 しかし、私は個人的にその名前が好きです。なぜなら、それは「Observable Input」の略であり、これが反映している「Output」のように見えるからです。

親愛なるAngularチーム。 2020年に楽しみにしていることを教えてください:-)

また、 @ jcomputerソリューションはまさに私が望んでいるものです。 別のデコレータ名の大ファンではありませんが、 @ViewChildに{ read }と同様のパラメータを追加することは可能かもしれません。 例えば：

@Input({ observable: true }) 
@Input({ asObservable: true }) 
@Input({ asSubject: true })

2020年に楽しみにしていることがたくさんあります。：Dもちろん、これ（および上記の他の問題）がバグとしてカウントされ、新機能としてカウントされない限り。 :)

https://twitter.com/ThomasBurleson/status/1283902827467886592

@fxck私はここで不評な意見を持っているかもしれませんが、正直なところ、2020年がAngularチームがフォーム、ルーターなどの多くのバグを潰すことを決定した場合、私は0の機能でまったく怒っていません：肩をすくめる：。

そうは言っても、それは最近のイベントに関連する問題である可能性があり、Angularチームでは現在複雑なことが起こっていると思います。 これまでAngularを積極的に構築してきた素晴らしい人々を維持してくれることを願っています： heart:。 しかし、それは別の話です。

オフトピックでごめんなさい。 飛び去ります

@ maxime1992それは私にとっても大丈夫でしょう。

私はここで不評な意見を持っているかもしれませんが、正直なところ、2020年がAngularチームがフォーム、ルーターなどの多くのバグを潰すことを決定した年である場合、私は0の機能でまったく怒っていません

しかし、私を緊張させているのは、Angularチーム内に、私たちがいなくても、私たちに影響を与える長期的な不健康なHRプロセスがあるという事実です。 特にこの分野への大規模な投資の観点から。

私のPOVから、彼らは主にBOTを介してそれらを閉じることによって問題を修正しています-応答なしで残し、ボットによって閉じます。、..：-/

@ montella1507いいえ、これは正確には

Angularチームを非難し、機能や変更がすぐに得られないことに不満を持っている人のために：
私はあなたの痛みを理解しています。 また、この機能をAngularで見たいと思っています。また、個人的に嫌いなものもたくさん変更したいと思います。

しかし、Angularは、すべての光沢のある新しいおもちゃを備え、リリースごとに大量の機能を備えたフレームワークを意図したものではないかもしれません。 そして、それは私にとっては問題ありません。 よりエンタープライズレベルを目指し、安定性と信頼性を提供するフレームワークが必要です。 そして、Angularは、少なくとも私の経験からは、それをうまくやっています。

私はVueがもっと好きです。 私はそれを個人的なプロジェクトに使用しています。 しかし、私のプロジェクトはすぐに時代遅れになり始め、新しいコンポーネントスタイルにアップグレードしたいという衝動を感じます。 また、私がアップグレードを行うとき、物事は常に最も奇妙な方法で壊れます。 エコシステムはまた、互換性を維持するのに苦労しているようです。

対照的に、Angularは成熟していて安定しています。 頻繁に変更されることはありませんが、依存関係を最新の状態に保つため、コードのリファクタリングの作業が少なくなることも意味します。これは、商用製品にとって価値があります。 あなたの知識はまた、より長く関連性を保ち、追いつくことを試みる代わりに、あなたは深く行くことができます。

@manfreedの人々は、光沢のある新しいおもちゃを求めているのではなく、フレームワークの設計における見落としの修正を求めています。 現在、主要な機能のために、オブザーバブルを使用せざるを得ない場合もあれば、オブザーバブルを使用できない場合もあります。 観測量が嫌いな人は欲求不満です。 オブザーバブルを愛する人は欲求不満です。 そして、私たちの多くは、私たちが諦めて他のフレームワークに移った状況にとても失望しました。 少し方向性のあるAngularを使い続けたいと思っていたので、本当に素晴らしいフレームワークであった可能性があります。 しかし、管理ミス、実用主義の欠如、見落としについてのブログ投稿は、すべて客観的に失望しています。

@insidewhy辛抱強く、道路には常に山と谷がいくつかありますが、それは他の人にもそれらがないことや、いくつかの主要な間違いがあることを意味するものではありません。 それは、物事が実際よりも速く効果的に前進できることを意味するだけです。

ロードマップには前述の特定

私は彼らに疑いの利益を与え、その中程度のロードマップの記事のコメントで、ミンコの応答を尋ねました：

彼は数ヶ月前にここで彼が言ったことをかなり繰り返しました、これらのrxjs関連の問題のどれもすぐに修正されていないので、そうです。

私は自分の主張を理解しようとしましたが、最後にもう一度試してみましょう

• 観察可能なライフサイクル
• 観察可能な入力
• 観察可能なテンプレートイベント

これらの下位互換性を壊し、学習曲線を増やし、他のAPIと一貫性がなく、パフォーマンスに

@fxck ：+1：確かに。

• 観察可能なライフサイクル
• 観察可能な入力
• 観察可能なテンプレートイベント

@insidewhy辛抱強く

レースで多くの競技者が注目を集めている場合、5年以上の忍耐を人々に求めることはそれほど現実的ではありません。

@ insidewhyそれは、より一般的に意味しました。

@fxck Googleには（私の最後の数では）4000個のアプリが組み込まれており、本質的に非常に似ています。これらのプロジェクトとピアレビューの切り替えは（私が想像する限り）非常にシームレスです。 私の会社でさえ、Angularの大きな利点の1つは、他のチームのコードをレビューしなくても、ピアレビューが調査全体を開始しない状態にあることを知っていることです。

ここで、これらの便利なRxJSショートカットのそれぞれをコアに実装するとします。それではどうなりますか？ 特定のケースでどちらのバイアスが正しいかを明確に示すことなく、手続き型バイアスと反応型バイアスが発生する可能性があります。 これまでの議論を読んだ後、Angularチームからの答えは「これは優先度が低い」ではなく（あなたの流れが示唆しているように）、実際には「私たちは味方になりたくない」に近いようです。

ここでのAngularコミュニティの上級RxJSユーザーは、声の少数派です。Typescript、DI、テンプレート、およびAngularのさまざまなライブラリを取得した後、フレームワークを毎日使用してほぼ1年が経過し、準備が整いました。 RxJSを完全に理解する。 ピアレビューで上級レベルの人々に反応性の偏見を持たせることは、人々をさらに遠ざけます。それは文字通り、Angularが必要とする最後のことです。

Angularの目標は（私が見ているように）、「X techを使用する方が良いので、ここに短い小説があります」から離れて会話を減らし、調整し、実装されているビジネスロジックに関するピアレビューで会話を続けることです。 コンポーネントを「Advanced」Angularと「Beginner」Angularの間で、すでに持っている以上に階層化する必要がありますか？

これは、状態管理で見たのとほぼ同じ議論ですが、Angularは、考えられる多くのパターンからどれが正しいかを判断する必要があるのはなぜですか？

角度のあるチームメンバーの1人を引用させてください。

ちなみに、これらのいずれについてもまったく進んでいません（観察可能なライフサイクル、観察可能な入力、観察可能なテンプレートイベント）。

これは、状態管理で見たのとほぼ同じ議論ですが、Angularは、考えられる多くのパターンからどれが正しいかを判断する必要があるのはなぜですか？

状態管理とこれの違いは、状態管理はコミュニティによって実行できることであり、角度のあるコアの内部にはそれを妨げるものは何もありません。 残念ながら、Angularは、私が言及した3つのうちどちらも適切に実装する方法を提供していません。 （編集：コメントへのリンクを修正）

フォーム、ルーター、フレックスレイアウト、ユニバーサルなどのパッケージを含む、可能な限りコミュニティに任せることに心から感謝しています。Angularチームがコア、CLI、コンポーネントに集中できるようにします。 ただし、そのためには、たとえば高次コンポーネントを許可するなど、コミュニティに十分なエントリポイントを提供する必要があり

これまでの議論を読んだ後、Angularチームからの答えは「これは優先度が低い」ではなく（あなたの流れが示唆しているように）、実際には「私たちは味方になりたくない」に近いようです。

はい、怖いです。

@fxck私たちはこれについて同じページにいると思います。 フォーラムで、あるいは同僚のエンジニアと一緒にRxJSを紹介するたびに、引用できる引用のほとんどは「まだ理解できていません。どうすればもっと学ぶことができますか？」と言えます。 または「オペレーターの数が圧倒的だと思います。」 または「このPRでこのパイプラインを読み取るのに問題があります」。 精通したRxJSエンジニア1人ごとに、眉をひそめた15人の精通したAngularエンジニアがいるようです。

はい、怖いです。

これは少し双曲的です。これらのパターンを持つために@angular/coreを「必要」とはしません。実際、この問題には、今日どのプロジェクトでも使用できる多くのバリアントとライブラリがあります。 前述のオプションを使用する際の唯一の躊躇は、将来、Angularが標準の@angular/core代替品として提供するものに移行しなければならない可能性があることです。 npm uninstall 、すべてのtypescriptエラーを修正するのは本当に難しいですか？

すべての角度のあるプロジェクトに影響を及ぼし、それらが機能しない場合は文書化して移行するのに数え切れないほどの時間を必要とする主要なアーキテクチャ上の決定は、さらに恐ろしいように思えます。

• https://angular.io/guide/migration-renderer
• https://medium.com/@amcdnl/the -new-http-client-in-angular-4-3-754bd3ff83a8

これは少し双曲的です。これらのパターンを持つために@angular / coreを「必要」とはしません。実際、この問題には、今日どのプロジェクトでも使用できる多くのバリアントとライブラリがあります。

いいえ、実際にはそうではありません。各ソリューションにはハックが必要であるか、変更される可能性のある内部APIに依存しています。 それが全体のポイントです。 @ insidewhyがhttps://github.com/angular/angular/issues/5689#issuecomment -630661006と言ったことと、テンプレートイベントストリームについてその下で言ったことを読んで

//修正されたリンクを編集してコメントします

いいえ、実際にはそうではありません。各ソリューションにはハックが必要であるか、変更される可能性のある内部APIに依存しています。

コミュニティがこれに対処できるようにするには、どの内部APIまたはタイプをパブリック/ジェネリックにする必要があると思いますか？ 明確な前進の道がないためにこのデザインが待機パターンにある場合は、この同じドラムを絶えず叩くのではなく、独自のデザインを許可するように依頼するのが適切だと思われます。

@insidewhyがコア内でそれを実行しようとした他のコメントを読んでください。

@fxckこれをコアに実装する試みの歴史や、この問題が5年間どのように開かれてきたかについては説明しませんが、コミュニティが自分でデザインを開発できるようにするために内部を開放することを

Yo @insidewhy 、これはあなたの

プロパティ 'serviceStackId $'は、初期化の前に使用されます。ts（2729）

Yo @insidewhy 、これはあなたの

いいえ、それはテンプレートコンパイラにありました。 これは別のことです。 くそ。 まぁ。 修正してみたい場合は、メンテナリストに追加できます。

@fxck実際には、デコレータベースのプロパティはコンストラクタが実行されるまで注入されないため、ngOnInitでそのパイプ演算子を割り当てる必要があります。これは、実際にはコードの正当な問題です。

@insidewhy私は間違いなくTS4の前に仕事をしました。 そしてこれをチェックし

function ObservableInput() {
  return (target: any, propertyKey: any) => {
    Object.defineProperty(target, propertyKey, {
      set(value: any) {
        console.log(target, propertyKey, value);
      },
      get() {
        return 'ObservableInput modified value';
      },
    })
  }
}

class Foo {
    @ObservableInput()
    bar = 'original bar value';

    baz = this.bar;

    constructor() {
        console.log('loggging this.baz', this.baz);
    }
}

new Foo();

ログに記録します

this.bazObservableInputの変更された値をログに記録します

したがって、TS4でのみ、そのデコレータ内に値を持つgetがあることに気付かないため、コンパイラが文句を言うだけで、それはまだ機能するはずだと思います。

デコレータを使用して入力プロップの変更を検知し、入力プロップの観察可能なバージョンを作成しています。 このcodesandboxデモを参照してください。

仕組みは次のとおりです。

// subjectize.ts
export function Subjectize(keyToWatch: string): PropertyDecorator {
  return (proto: any, propKey: string) => {
    const internalKey = Symbol(keyToWatch);
    Object.defineProperties(proto, {
      [keyToWatch]: {
        get() {
          return this[internalKey];
        },
        set(value) {
          this[internalKey] = value;
          this[propKey].next(value);
        }
      }
    });
  };
}

// counter.component.ts
import { Component, Input } from "@angular/core";
import { ReplaySubject } from "rxjs";
import { Subjectize } from "./subjectize";

@Component({
  selector: "app-counter",
  templateUrl: "./counter.component.html",
  styleUrls: []
})
export class CounterComponent {
  @Input()
  count: number;

  @Subjectize("count")
  count$ = new ReplaySubject(1);
}

@wmaurerが指摘したように、 @Subjectizeは、物事を成し遂げるための「砂糖」として扱うことができます。

Angularの公式ガイドInterceptinputプロパティの変更をセッターで読む価値があります。これは、 getter/setterを使用して入力の変更を検出できることを説明しています。

@hankchiutwそのソリューションは私の@BindObservableデコレータに似ています： //github.com/PSanetra/bind-observable#usage

ありがとう@hankchiutw

ReplaySubjectを1で初期化しているので、代わりにBehaviorSubjectを使用することにしました。
また、Subjectizeで値を直接初期化しました。

export function Subjectize<T>(keyToWatch: string): PropertyDecorator {
  return (target: Object, propKey: string) => {
    const internalKey = Symbol(keyToWatch);
    Object.defineProperties(target, {
      [keyToWatch]: {
        get(): T {
          return this[internalKey];
        },
        set(value: T) {
          this[internalKey] = value;

          if (this[propKey]) {
            this[propKey].next(value);
          } else {
            this[propKey] = new BehaviorSubject(value);
          }
        }
      }
    });
  };
}

@Component({
    changeDetection: ChangeDetectionStrategy.OnPush,
    selector: 'rol-bla',
    templateUrl: 'bla.html',
    styleUrls: [ 'bla.scss' ]
})
export class BlaComponent implements OnInit {
    @Input() world: World;
    @Subjectize<World>('world') world$: BehaviorSubject<World>;

    // ...
}

関連するプロパティからタイプを推測できるはずなので、「Subjectized」プロパティにタイプを記述しないようにしたいと思います:(それを行う方法はありますか？

夢はそれを実行し、関連するサブジェクトプロップ（私の場合はworld $）をBehaviorSubjectとして自動的に作成できるようにすることです。正しく初期化されます。

export class BlaComponent implements OnInit {
    @Input() @Subjectize() world: World;

    // ...
}

@mparpaillon提案された設計は、 https：//github.com/PSanetra/bind-observableで行われている方法とほぼ同じです
唯一の違いは、 @BindObservable()デコレータが内部でReplaySubjectを使用することです。 したがって、そのサブジェクトに初期値を含める場合は、バインドされたプロパティを明示的に初期化する必要もあります（プロパティタイプで未定義またはnull値が許可されていない可能性があるため、未定義の場合も同様です）。

Stackblitzの例

@Component({
  selector: 'app-my-component',
  templateUrl: './my-component.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class MyComponentComponent {
  @Input()
  @BindObservable()
  counter: number;
  counter$: ReplaySubject<number>;
}

@PSanetraに感謝し

@mparpaillon別のデモであなたの夢（ha）のために何かを試しました。

使用法は次のようになります

export class CounterComponent {
  @Input()
  @Subjectize()
  count: number;

  @Input()
  @Subjectize("myCount$")
  anotherCount: number;
}

ここで、サブジェクトされたプロップ名を指定することを選択できます。

技術的には実現可能ですが、開発者にとってはあいまいになる可能性があります（新しいクラスメンバーが内部で作成されるため）。

ありがとう@hankchiutw ！ Typescriptではcount $やmyCount $を使用できないようです。

また、あなたは曖昧さについて正しいかもしれません...ありがとう

Typescriptではcount $やmyCount $を使用できないようです。

クラスメンバーを「count」および「anotherCount」として宣言したため、「myCount $」および「count $」にアクセスできません。 あなたがどこにも宣言しなかったので、それらは単に存在しません。

私は知っています...それがポイントです。 デコレータからそれらを宣言する方法を探していました。 @hankchiutwは解決策を提供しました、そして私はそれがそのままでは機能していないと言っているだけです

@mparpaillonは私の解決策を見てください： //github.com/Futhark/ngx-observable-input

@Futharkああ、暑い！ どうも