Hai @laco0416 - bahasa Inggris Anda baik-baik saja, jangan khawatir!

Saya sangat menyukai ide ini, dan ini adalah sesuatu yang telah kita diskusikan sebelumnya. Itu juga cocok dengan https://github.com/angular/angular/issues/4062 (Mengamati acara tampilan) dan https://github.com/angular/angular/issues/5467 (Acara anak yang dapat diamati dari orang tua)

Penting untuk diingat bahwa tidak semua orang ingin menggunakan Observables (orang-orang ini tidak ada!), jadi kami harus menyediakan opsi untuk kedua kasus penggunaan, jadi kecil kemungkinan kami akan membuat @Input() langsung menjadi Observable. Saya pikir memiliki sesuatu seperti @ObserveInput() mungkin berhasil, dan kami akan berdiskusi _setelah_ kami mengirimkan versi beta tentang beberapa fitur yang lebih menarik ini menurut saya.

Sementara itu, inilah implementasi dasar (dan _sangat_ eksperimental!!! JANGAN lakukan ini secara nyata) dari ide ini. Apakah ini yang Anda pikirkan secara konseptual? http://plnkr.co/edit/Nvyd9IPBZp9OE2widOcW?p=preview

Saya pikir itu ide yang sangat buruk untuk mengubah properti input dalam komponen anak. Properti input harus "hanya-baca". Data Anda harus selalu mengalir dari orang tua ke anak (dan tidak pernah ke arah sebaliknya).

@alexpods saya percaya ide di sini persis seperti itu - _mendengarkan_ perubahan pada properti input _as_ yang Dapat Diamati, tidak memancarkan nilai ke hulu, yang sejauh yang saya ketahui baik-baik saja.

@robwormald

Bahasa Inggris Anda baik-baik saja, jangan khawatir!

Terima kasih! Aku sangat lega.

@ObserveInput adalah apa yang saya inginkan!
Juga, @Input tidak memiliki perubahan yang melanggar. Saya pikir itu adalah solusi yang sangat bagus.

@alexpods Saya juga sama sekali.

itu mendengarkan perubahan dalam properti input sebagai Observable, tidak memancarkan nilai di hulu, yang sejauh yang saya ketahui baik-baik saja.

Saya berpikir dengan cara yang sama seperti Rob.

@laco0416 Ooh, maaf atas kesalahpahaman. Ungkapan "jika properti Input diubah di komponen anak" membuat saya bingung.

Saya tidak tahu apakah saya harus berkomentar di sini atau apakah saya harus membuka edisi baru. Tolong beri tahu saya jika saya menambahkan permintaan ke tempat yang salah.

Saya sudah mencoba (tetapi, sampai sekarang, gagal) untuk menulis dekorator seperti itu, dan kemudian saya menemukan @robwormald plunkr , yang berfungsi _hampir_ dengan sempurna (tetapi tidak cukup).

Apa yang membuat saya bersemangat dengan pendekatan ini adalah fakta bahwa pendekatan ini memanfaatkan kait siklus hidup ngOnChanges .
Apa yang ingin saya lihat adalah beberapa cara agar _all_ lifecycle hooks diekspos sebagai Observables, yaitu sebagai onChanges$: Observable<{[key: string]: SimpleChange}> , onInit$: Observable<{}> , dll.

Memiliki semua kait siklus hidup tersedia sebagai Observables akan membantu saya Rx semua hal ;-)

Ada pembaruan tentang ini?

AFAIK, No.
@robwormald apakah Anda punya berita?

Saya tahu ini sudah tua, tetapi ini akan sangat bagus! @robwormald Ada kabar tentang ini?

Saya ingin memberikan perubahan nilai properti @Input sebagai Observable, seperti yang dilakukan dekorator @ObserveInput @robwormald. Tidak selalu layak untuk memiliki komponen induk yang melewati Observables, terutama saat Anda memigrasikan aplikasi (Angular 1) yang sudah ada. Tidak dapat "mengandung" Observables dalam satu komponen membuat peningkatan kekuatan dan keanggunan RxJS jauh lebih sulit.

Sayangnya, Rob tidak bercanda ketika dia mengatakan untuk tidak menggunakan versi @ObserveInput . Masalah yang saya hadapi adalah bahwa Observables dibuat pada "tingkat kelas" (jika terminologi itu masuk akal) dan karenanya dibagikan di semua instance komponen. Ini tidak baik, jelas. Membuat Observables pada waktu instantiasi juga tidak berhasil untuk saya. Tampaknya Angular tidak memasang deteksi perubahan dengan benar pada kasus itu.

Adakah yang mengelola implementasi @ObserveInput atau adakah berita tentang dukungan resmi?

@lephyrus Sementara @ObserveInput resmi akan menjadi sangat bagus, itu tidak sepenuhnya diperlukan untuk mendapatkan Observable untuk mengubah nilai properti @Input . Dekorator hanya akan menjadi "gula" yang sangat elegan.

Sudah ada acara siklus hidup ngOnChanges . Di dalam ngOnChanges kita dapat menggunakan rxjs Subject , untuk membuat perubahan yang dapat diamati, yaitu:

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

Atau, jika Anda menginginkan sesuatu yang lebih dapat digunakan kembali, Anda dapat membuat kelas dasar yang komponen Anda 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);
    }
}

... yang dapat digunakan sebagai berikut:

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

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

Saya menggunakan pendekatan ini sampai dekorator @ObserveInput resmi tersedia.

Terima kasih, @wmaurer. ReactiveComponent sangat diterima, dan menggunakan kode sempurna dan pengetikan aman untuk boot - sangat bagus! Yang penting, ia juga berperilaku baik dalam pengujian dan masih memungkinkan penggunaan strategi deteksi perubahan OnPush . Saya sekarang senang menunggu "gula resmi". (Juga saya yakin saya akan belajar sesuatu ketika saya mengetahui mengapa Anda harus menggunakan logika Observable.create() - saya belum menemukan waktu untuk menyelidikinya.) Sekali lagi: merci gäll! :mengedip:

@lephyrus sama- sama, gern gescheh ;-)

Saya menggunakan Observable.create() untuk mendapatkan Observer agar dapat melakukan next() . Saya bisa menggunakan Subject yang merupakan Observable dan Observer , tapi saya yakin ini adalah praktik yang buruk untuk 'mengekspos' Subject ( Observer ).

@laco0416 tutup mendukung https://github.com/angular/angular/issues/13248 ?

@DzmitryShylovich Tidak. Fitur yang diusulkan dalam masalah ini hanya-baca dan data yang digerakkan oleh peristiwa.

@ObserveInput akan sangat keren! :+1:

Terima kasih @wmaurer untuk contoh yang baik. Aku punya satu pertanyaan. Saya ingin dapat menggunakan objek alih-alih string sebagai yang dapat diamati.

Misalnya

@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;
}

Namun this.updateChart dan ngOnChanges tidak dipanggil. Bagaimana cara memperluas sampel Anda dari string sederhana untuk mengamati objek?

@ChrisWorks itu juga harus bekerja dengan objek:

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

Saya sangat sering melakukan ini, jadi jika ini tidak berhasil, saya kira ada masalah dengan input ke komponen Anda di suatu tempat.

Hai @wmaurer , terima kasih atas jawabannya. Apakah Anda dapat memperluas sampel Anda dengan versi yang berfungsi di mana Anda menggunakan objek "config"? Saya tidak bisa membuat milik saya bekerja. Contoh repo Git? :)

@ChrisWorks itu benar-benar harus bekerja seperti itu. observePropertyCurrentValue tidak membedakan antara input string dan objek.
Ini adalah proyek ng2 beta 0 yang sangat lama yang saya buat di mana input dari semua jenis berbeda, bukan hanya string:
https://github.com/wmaurer/todomvc-ng2-reactive
misalnya https://github.com/wmaurer/todomvc-ng2-reactive/blob/master/src/app/todo-item/todo-item.component.ts

+1 Kasus penggunaan yang begitu mendasar, tidak percaya ini belum diurutkan!

Saya akhirnya mendapatkan solusi terbaik dan bekerja tanpa pengulangan dan dengan kompilasi AOT :) Rahasianya adalah menggabungkan @Input() dengan dekorator kedua.

dekorator:

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                                                                                                                             
      },                                                                                                                                           
    })                                                                                                                                             
  }                                                                                                                                                
}                                                                                                                                                  

Penggunaan:

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

EDIT: Sekarang saya telah menjadikan ini perpustakaan. Senang menerima ide untuk memperbaikinya. Menambahkan metode baru yang melengkapi @Input dengan Observable berikutnya. Lihat https://github.com/ohjames/observable-input

Jika saya harus melakukan sesuatu seperti itu, saya lebih suka menggunakan analog Subjek tunggal ke ngOnChanges: Subject<SimpleChanges>
Anda masih dapat memfilter & memetakan hanya ke satu input tertentu jika Anda mau.

1 Subjek per input tampaknya banyak tanpa berbicara tentang menghapus prop kelas untuk membuat pengambil & penyetel dan bahwa jenis input Anda salah dan melakukan input = value sebenarnya akan memancarkan nilai pada yang dapat diamati dan Anda tidak menyelesaikan mata pelajaran Anda.

Anda dapat menemukan contoh implementasi ide saya di sini , pendekatan dekorator bersifat eksperimental tetapi saya pikir seharusnya cukup aman untuk menggunakan pendekatan pewarisan (perlu diingat saya baru saja melakukannya sekarang untuk menunjukkan di sini, itu tidak digunakan).

@ghetolay tidak masalah jika subjek selesai, ketika tampilan ditutup tidak ada lagi langganan aliran dan dapat dibuang oleh GC. Memancarkan nilai pada yang dapat diamati pada dasarnya adalah intinya. Kompiler sudut saat ini tidak memeriksa tipe properti input, semoga pada saat itu sesuatu yang lebih resmi akan tersedia ;)

changes$ membocorkan antarmuka BehaviorSubject ke komponen, idealnya harus diketik sebagai Observable<...> , selain itu tampaknya masuk akal, jika sedikit lebih bertele-tele.

Adapun masalah banyak mata pelajaran... apakah Anda menggunakan n mata pelajaran atau 1 Anda masih memiliki n langganan. Ketika Anda memiliki 1 subjek, Anda akhirnya menambahkan satu operator peta dan satu operator filter ke setiap langganan, overhead kinerja ini tidak akan jauh lebih sedikit daripada hanya menggunakan subjek n , bahkan bisa lebih buruk.

Mengabaikan pengetikan parameter input itu sendiri, versi berbasis dekorator menyediakan API yang lebih aman untuk konsumen dari yang dapat diamati daripada tipe SimpleChange berdasarkan any .

@ohjames

ketika tampilan ditutup, tidak ada lagi langganan ke aliran dan itu dapat dibuang oleh GC

Anda mengasumsikan semua langganan akan terikat ke tampilan dan mendapatkan siklus hidup yang sama dengan tampilan. Saya tidak membuat asumsi tentang bagaimana Observable akan dikonsumsi.

Memancarkan nilai pada yang dapat diamati pada dasarnya adalah intinya. Kompiler sudut saat ini tidak memeriksa tipe properti input, semoga pada saat itu sesuatu yang lebih resmi akan tersedia ;)

Maksud saya untuk pengguna, pengguna masih dapat mengakses dan mengatur properti. Jadi itu akan mengatur properti seolah-olah itu adalah angka kecuali diketik sebagai Observable dan ini tidak akan pernah mengatur properti tetapi membuatnya memancarkan. Ini sangat membingungkan bagi saya.

Adapun masalah banyak mata pelajaran... apakah Anda menggunakan n mata pelajaran atau 1 Anda masih memiliki n langganan. Ketika Anda memiliki 1 subjek, Anda akhirnya menambahkan satu operator peta dan satu operator filter untuk setiap langganan, overhead kinerja ini tidak akan jauh lebih sedikit daripada hanya menggunakan n subjek, bahkan bisa lebih buruk.

Tidak akan masuk ke perdebatan semacam ini di sini karena kita akan segera kehilangan fokus tentang tujuan utama.

Saya telah memperbarui untuk tidak mengekspos Subject dan membangun sesuatu untuk menambahkan pengetikan ke perubahan.
Saya tidak menggunakan BehaviorSubject tetapi Subject karena saya tidak melihat Observable sebagai pemegang nilai tetapi sebagai perubahan dari waktu ke waktu.
Saya baru saja menemukan cacat: saat menggunakan pipa async, nilai pertama tidak keluar karena pipa async akan berlangganan setelah emisi pertama. Saya akan memperbarui kode saya nanti untuk menangani kasus itu dengan benar.

Ini tautannya lagi: https://stackblitz.com/edit/angular-observableinput?file=observablechanges%2Fimpl.ts

Anda mengasumsikan semua langganan akan terikat ke tampilan dan mendapatkan siklus hidup yang sama dengan tampilan. Saya tidak membuat asumsi tentang bagaimana Observable akan dikonsumsi.

Oke saya mengerti maksud Anda, menyelesaikan yang dapat diamati akan memaksa menutup semua langganan, tetapi itu bukan sesuatu yang benar-benar mengkhawatirkan saya. Di aplikasi kami, 99% langganan terjadi melalui pipa async dan dalam beberapa yang tidak harus ditutup secara manual karena mereka sering bersumber dari observable eksternal yang bersumber dari Redux/etc melalui combineLatest/switchMap.

Tidak akan masuk ke perdebatan semacam ini di sini karena kita akan segera kehilangan fokus tentang tujuan utama.

Nah Anda mengajukan kritik yang tidak valid sehingga perlu untuk melawan yang itu.

~Juga menggunakan kelas Anda melalui pewarisan tidak akan berfungsi, kode yang dihasilkan oleh kompiler AOT tidak memanggil metode siklus hidup di kelas induk, lihat https://github.com/angular/angular/issues/12756#issuecomment -260804139, Anda 'll perlu menambahkan ngOnDestroy() { super.ngOnDestroy() } dan satu lagi untuk ngOnChanges untuk semua konsumen kelas.~ <-- tampaknya telah diperbaiki pada Angular 4.4 dengan batasan tertentu.

Saya telah meninjau kekhawatiran saya tentang penggunaan pipa async dan karena Anda masih memiliki akses ke input, saya rasa penggunaannya tidak masuk akal. Jika Anda hanya ingin mengikat nilai input pada template, Anda bisa langsung mengikat input tidak perlu menggunakan observable dan async di sini. Dan jika Anda ingin membuat observable baru darinya maka Anda harus bisa mendapatkan apa yang Anda inginkan dengan mudah (mungkin menggunakan startWith suatu tempat).

Jadi saya pikir pernyataan saya sebelumnya ok:

Saya tidak menggunakan BehaviorSubject tetapi Subjek biasa karena saya tidak melihat Observable sebagai pemegang nilai tetapi sebagai perubahan dari waktu ke waktu. Jika Anda memerlukan akses ke nilai input, properti tetap ada dan Anda dapat merujuknya secara sinkron.

Kode ini sangat eksperimental, ini hanya semacam poc dan saya hanya memainkannya di stackblitz itu.
Jadi saya seharusnya tidak mengatakan bahwa itu cukup aman maaf dan mungkin tidak bekerja dengan AOT seperti yang Anda nyatakan.
Baru saja mencobanya dan kedua pendekatan saat ini berfungsi dengan AOT (sudut v4.3.6, cli v1.4.1).

Poin utama saya di sini adalah bahwa beralih dari changes dapat diamati yang berisi semua perubahan input memberi Anda kemungkinan untuk melakukan apa pun yang Anda perlukan menggunakan operator: bereaksi ketika ada input yang diubah, ketika hanya 1 input yang diubah, ketika sejumlah input yang berubah-ubah berubah, ketika berubah dari nilai tertentu ke nilai lain dll ...
Anda dapat membuat observable yang Anda inginkan.

Juga hanya ada 1 Subjek untuk dikelola untuk implementasi dan 1 properti yang digunakan untuk pengguna vs 1 per Input.

Hal yang dapat saya ubah adalah hanya memancarkan nilai baru dan bukan objek SimpleChanges karena pengguna mungkin dapat menggunakan pair dan map untuk mendapatkan jenis struktur yang sama dengan SimpleChange . Tetapi saat ini yang kami dapatkan adalah SimpleChanges jadi akan konyol untuk menguraikannya hanya untuk menyusun ulang sesuatu yang serupa nanti.

PS:

Nah Anda mengajukan kritik yang tidak valid sehingga perlu untuk melawan yang itu.

tidak sah bagi Anda .

Ini bukan sudut pandang pribadi ketika kita mengacu pada kinerja, ini adalah fakta terukur yang objektif. Anda merasa 3 subjek sama dengan lebih banyak overhead daripada 6 operator tambahan, tentu saja mungkin Anda benar, tetapi tidak ada dasar rasional untuk mempercayainya sampai Anda melakukan beberapa pengukuran.

Adapun untuk bereaksi terhadap banyak input... tentu saja Anda dapat menggunakan switchMap atau combineLatest atau operator lain yang dirancang untuk bekerja dengan banyak objek yang dapat diamati. Anda membuat pernyataan yang sangat berani dan menyeluruh tentang ini, jika Anda benar-benar ingin melanjutkan percakapan ini, lepaskan dari pelacak masalah ini.

Berikut adalah versi dengan kekurangan dan kelebihan yang berbeda tetapi membutuhkan kelas dasar:

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()
  }
}

dan untuk menggunakan:

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')
}

Tidak yakin apakah saya salah memahami masalah ini, tetapi apakah pipa async tidak menyelesaikan masalah ini?
[inputVar]="observableValue | async" ..

@najibla Anda salah paham, input tidak dapat diamati sehingga pipa async tidak membantu.

@ohjames baik dalam kasus saya, itu berhasil menggunakan pipa async untuk yang dapat diamati. Dan ketika saya memperbarui nilai yang dapat diamati dari induknya, nilainya tercermin dalam komponen anak.

@najibla masalah github ini adalah tentang mengubah properti @Input menjadi yang dapat diamati, ini terkait erat dengan kasus yang Anda gambarkan.

yaitu Anda tidak perlu mengubah properti input menjadi yang dapat diamati dalam tampilan, apakah komponen merespons perubahan properti input menggunakan yang dapat diamati atau tidak harus diisolasi dalam komponen itu sendiri. Kalau tidak, Anda harus mengubah antarmuka komponen Anda jika Anda memutuskan untuk menggunakan properti sebagai yang dapat diamati yang bertentangan dengan pendekatan "dapat diamati pertama" sudut yang biasa.

@icepeng Sebenarnya Anda kurang tepat, ini tentang mengubah input standar menjadi yang dapat diamati. Jadi pola baru sebenarnya adalah:

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

... maka itu menyediakan cara untuk mengakses prop di dalam AppChildComponent sebagai Observable meskipun itu bukan observable (atau jika itu observable, Anda akan mendapatkan observable of observables ). Sekarang tentu saja jika Anda memiliki prop$ di tempat pertama seperti pada contoh Anda, maka itu mungkin tampak tidak masuk akal (Anda sudah dapat melewati input yang dapat diamati dengan input sekarang). Namun itu memberikan banyak nilai ketika input yang diteruskan belum dapat diamati (misalnya index dari ngFor ).

Masalah dengan mewariskan yang dapat diamati dengan input (yang sangat mungkin saat ini) adalah bahwa itu tidak akan berfungsi dengan OnPush .

@fxck Anda benar bahwa ngOnChanges tidak akan dipanggil ketika observable dipancarkan (karena inputnya tetap sama), tetapi selama Anda menggunakan pipa async untuk berlangganan observable melewati @Input lalu OnPush akan berfungsi dengan baik karena pipa async secara manual memicu pendeteksi perubahan komponen anak.

Ya, itu diarahkan ke @icepeng.

@ohjames @fxck Saya tidak tahu menurunkan yang dapat diamati mungkin saat ini, maaf untuk informasi yang salah.

Karena melewatkan yang dapat diamati secara langsung dimungkinkan, saya tidak yakin tentang @ObserveInput akan berguna.
Saya pikir jika nilai yang dapat diubah tidak dapat diamati, itu sudah menjadi masalah.
Hanya pendapat pribadi.

@icepeng Pertimbangkan ini:

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

Bagaimana cara membuat index dikonsumsi sebagai yang dapat diamati di sini tanpa melompati rintangan?

Atau pertimbangkan juga Anda sedang menulis perpustakaan pihak ketiga dan tidak ingin memaksa konsumen perpustakaan Anda untuk meneruskan yang dapat diamati ke komponen Anda (banyak pengguna tidak nyaman dengan aliran dan menghindari rxjs).

Ada banyak contoh lain di mana ini berguna.

@ohjames index akan menjadi nilai statis untuk setiap child-component , jadi saya tidak berpikir itu harus dapat diamati. Namun, sekarang saya mengerti mengapa orang menginginkan fitur ini. Dan solusi Anda tampaknya bagus untuk menulis perpustakaan pihak ketiga.

Pendekatan BehaviorSubject tampaknya lebih baik, alangkah baiknya jika inti Angular menyediakan dekorator @NgChanges() seperti itu.

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

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

Apakah ini mungkin untuk diterapkan?

ReplayObservable dengan panjang buffer 1 akan lebih disukai, tidak perlu semantik nilai BehaviorSubject ketika Anda juga memiliki akses ke properti.

Mengenai apakah mungkin untuk diterapkan, periksa riwayat masalah untuk banyak implementasi dan opsi yang berbeda. Tidak ada yang bagus dan ada yang langsung rusak, untuk melakukannya dengan benar kita memerlukan PR terkait atau yang serupa.

2 sen saya: karena object.observe telah disusutkan demi proksi, solusi saya adalah memperpanjang proksi (ya Anda tidak bisa, saya tahu, alasan mengapa saya mengembalikannya dari konstruktor) dan kemudian mendengarkan kunci apa pun milik ini objek sebagai Observable melalui metode $get(keyName). Anda dapat menggunakannya dengan objek apa pun, tidak hanya kelas sudut.

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

Contoh:

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 , apakah ada daya tarik untuk masalah ini? Itu pasti akan membuat segalanya lebih mudah digunakan.

@bryanrideshark Peluang terbaik untuk mendukung ini adalah melalui https://github.com/angular/angular/issues/10185 Saya pikir, terkejut bahwa PR tidak terkait dengan masalah ini.

Ini tidak akan terjadi sampai setelah kami mengirimkan Ivy
Pada Rabu, 21 Februari 2018 pukul 07:56 James Pike [email protected] menulis:

@bryanrideshark https://github.com/bryanrideshark Kesempatan terbaik untuk
ini didukung melalui #10185
https://github.com/angular/angular/issues/10185 Saya pikir, terkejut itu
PR tidak terkait dengan masalah ini.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/angular/angular/issues/5689#issuecomment-367372931 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AAgpkvtGA4w8uHgiz0QsdYwBgqgM2EpAks5tXDyWgaJpZM4Gwr8f
.

Bahasa Inggris Anda bagus dan sudut Anda lebih besar.

@ pldin601 Metode Anda tidak mendukung kode yang dikompilasi AOT, sehingga akan menyebabkan kebocoran memori yang besar untuk kode produksi kebanyakan orang. Lihat paket observable-input yang berfungsi baik dengan AOT.

@pldin601 masalah dengan kode Anda adalah bahwa ia secara dinamis menambahkan metode siklus hidup ngOnDestroy . Kode yang dikompilasi AOT hanya memanggil ngOnDestroy jika kompiler dapat menyimpulkan keberadaannya secara statis. Jadi metode Anda hanya akan berfungsi jika setiap komponen yang menggunakan dekorator juga mendefinisikan ngOnDestory (bisa kosong jika tidak diperlukan). Dalam semua kasus lain itu akan membocorkan langganan, mencegah komponen dari pengumpulan sampah.

Saya kira itu akan terjadi setelah bagian 3.2 selesai (dan mudah-mudahan kebutuhan ini dipertimbangkan)?
https://is-angular-ivy-ready.firebaseapp.com/#/status

Akankah Ivy menjadi bagian dari 7.0.0?

Saya telah menerapkan dekorator yang dapat mengikat properti ke properti pendamping yang dapat diamati. Ini dapat digunakan pada properti input sudut, tetapi juga pada properti lainnya. Ini terinspirasi oleh @ObservableInput() dekorator dari @ohjames , tetapi menghindari kemungkinan masalah yang disebabkan oleh ketidakcocokan tipe antara pengambil dan penyetel properti dengan menggunakan properti yang berbeda untuk menyediakan Observable.

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

Contoh:

class MyClass {

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

}

const myInstance = new MyClass();

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

myInstance.myProp = 'newValue'

Kode ini mencetak nilai 'initialValue' dan 'newValue' ke konsol.

Pembaruan apa pun tentang kapan ini akan dirilis sejauh ini paket observable-input tampaknya paling elegan tanpa merusak apa pun + tanpa subkelas. @ohjames Seberapa stabil/teruji dengan baik saat ini?

Saya pikir dukungan resmi akan lebih matang, akan menjamin dukungan berkelanjutan di seluruh versi dan pengalaman dev yang lebih lancar/akan mendorong pengembang untuk melakukan rxjs* penuh dan mengoptimalkan dengan deteksi perubahan push (ini harus menjadi fitur terobosan inti menurut pendapat saya)

*tanpa mengurangi kompatibilitas dengan input yang tidak dapat diamati atau memerlukan boilerplate tambahan untuk input hybrid yaitu: panggilan penyetel berikutnya pada subjek

Digunakan input yang dapat diamati dalam sudut 4, 5 dan 7 dengan dan tanpa aot. Sepertinya ini bekerja dengan baik. Saya cukup yakin saya samar-samar tahu apa yang saya lakukan ketika saya menulisnya.

berharap mereka akan menambahkannya dalam kerangka kerja dan mendorong penggunaannya 2 unduhan mingguan npm tidak cukup dibandingkan dengan keuntungan yang ditawarkan xD jika mereka menambahkannya Saya yakin orang akan melihat bahwa mudah untuk mengikuti pendekatan itu

Saya mengusulkan API berikut untuk input async dengan observer ditentukan pengguna

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

pengguna hanya bisa menggunakannya sebagai

@AsyncInput()
asynchronusProperty1 = new Subject();

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

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

Internal sudut hanya dapat memanggil observer.next(newValue) setiap kali nilainya berubah.

Jangan lupa dukungan @HostBinding juga!

Ini harus dikombinasikan dengan injeksi konstruktor @Input untuk membuatnya lebih mengagumkan. Dengan cara ini kami dapat memperbaiki "strictPropertyInitialization" dengan cara yang sangat elegan:

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

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

}

@benneq hanya perlu dicatat itu bisa sekecil:

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

@ maxime1992 ya, meskipun Anda memerlukan dekorator terpisah untuk input sebagai yang dapat diamati untuk membedakan antara kasus yang dapat diamati yang diteruskan dari satu komponen ke komponen lainnya.

@benneq @maxime1992 Nama parameter bukan bagian dari metadata dekorator, bagaimana Anda memetakannya?

@trotyl Saya kira Anda bisa menggunakan @Input('paramName') private myParam: Observable<Data>

@trotyl @benneq ya saya buruk. Sudahlah :zipper_mouth_face:

Saya tidak tahu apakah seseorang sudah memposting solusi ini tetapi

@ElianCordoba Ini bukan tentang HTML <input> . Ini tentang sudut @Input()

Itu masalah yang berbeda, tetapi juga menyakitkan @ElianCordoba. https://github.com/angular/angular/issues/13248

Saya pikir ini adalah persyaratan semu. Pertama, dekorator input dapat menerima nilai tipe yang dapat diamati, kedua, jika komponen memerlukan input yang dapat diamati, komponen tersebut harus secara eksplisit membuang kesalahan saat menerima nilai yang tidak dapat diamati alih-alih secara diam-diam mengubahnya menjadi nilai tipe yang dapat diamati.

Ini sangat mirip dengan konversi tipe implisit dalam javascript, mungkin membingungkan bahkan menyebabkan bug dan sulit ditemukan.

Itu bukan tentang membungkam input yang salah. Ini tentang mengekspos antarmuka umum di seluruh komponen (yang merupakan input yang tidak dapat diamati). Ini memberi Anda kebebasan untuk memperkenalkan fungsionalitas rx tanpa merusak antarmukanya di dunia luar. Manfaat lain terutama mengangkat mutabilitas dan keadaan internal karena semuanya akan menjadi transformasi input yang membuat deteksi perubahan push sejak saat itu dan seterusnya menjadi tidak perlu dipikirkan lagi.

Sebaliknya, mengekspos, antarmuka yang membutuhkan yang dapat diamati terdengar kikuk dan memaksa orang untuk memberikan (nilai) hanya karena komponen Anda mengatakan itu terdengar aneh bagi saya.

Plus ini bukan tentang konversi senyap, ini adalah API untuk berlangganan perubahan melalui rxjs. Mengingat angular.http dan router menyediakan observables, sangat canggung bahwa penanganan perubahan input tidak, menyatukan dunia panggilan balik dan RxJ membutuhkan terlalu banyak pelat boiler.

Bukannya saya tidak menyukai beberapa solusi cerdas di atas, tetapi terkadang hanya sedikit reorganisasi cara 'standar' untuk melakukannya sudah cukup untuk menyelesaikan masalah sebenarnya di sini yaitu kurangnya kejelasan / kecanggungan. Ditambah lagi saya masih berharap cara 'resmi' pasca-ivy untuk melakukan ini suatu hari nanti.

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

Kemudian Anda bisa memasukkan sesuatu seperti combineLatest(this.service.magicInput$, this.inputs, config$)...... untuk menggabungkan input dengan RxJS.

Baik BehaviorSubject atau ReplaySubject berfungsi. BehaviorSubject biasanya lebih aman dan lebih dapat diprediksi.

• BehaviorSubject - gunakan jika Anda memiliki default
• ReplaySubject - yang dapat diamati tidak akan dipancarkan jika Anda lupa mengatur nilai input

Ini tidak hanya membantu dengan kejelasan kode tetapi karena saya mengelompokkan semua input bersama-sama, saya dapat dengan mudah melihat apa yang 'murni' input yang dapat diamati hanya dengan mengetik this.inputs. dan mendapatkan pelengkapan otomatis.

Anda dapat melangkah lebih jauh dengan keamanan tipe dengan ini (kebanyakan ini hanya untuk bersenang-senang).

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

Maka Anda tidak perlu secara eksplisit menentukan jenis properti @Input .

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

Saya bisa saja membuat antarmuka ObservableInputs untuk komponen untuk menerapkan inputs tetapi memutuskan untuk tidak melakukannya karena tetap tidak akan dikompilasi jika Anda mengacaukannya.

@simeyla Terlalu banyak boilerplate.

Saya memutuskan untuk menempatkan dekorator saya sendiri di luar sana. Ini adalah paket npm pertama saya jadi saya yakin ada sesuatu yang saya lewatkan, tapi ini dia: https://www.npmjs.com/package/@ng-reactive/async -input

Instalasi

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

Penggunaan

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 sangat bagus, saya tidak melihat alasan mengapa sesuatu seperti ini tidak boleh dibangun. FYI, tautan github di npm untuk paket sudah usang, pergi ke sini:

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

Saya melihat ini adalah masalah yang cukup lama tetapi fiturnya sangat luar biasa dan saya sangat senang melihatnya di Angular.

Apa yang lebih keren adalah bahwa dengan input yang dapat diamati Anda tidak memerlukan kait OnChanges - Anda dapat menggunakan operator pairwise rxjs untuk mendapatkan nilai input yang dapat diamati sebelumnya dan saat ini:

@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

Ini adalah implementasi pribadi saya, ini bekerja dengan sempurna dan sangat mengagumkan, jika kita dapat memilikinya, itu sangat keren.

Saya telah menerbitkan solusi yang saya gunakan secara pribadi dalam proyek saya sebagai paket npm:

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

Instalasi

npm install ngx-observable-input

Penggunaan

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

    ...
}

Saya melihat ini adalah masalah yang cukup lama tetapi fiturnya sangat luar biasa dan saya sangat senang melihatnya di Angular.

Apa yang lebih keren adalah bahwa dengan input yang dapat diamati Anda tidak memerlukan kait OnChanges - Anda dapat menggunakan operator pairwise rxjs untuk mendapatkan nilai input yang dapat diamati sebelumnya dan saat ini:

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

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

Ini adalah masalah yang juga mengganggu saya untuk sementara waktu, jadi saya telah menyelidiki sedikit dan menemukan solusi yang sama yang Anda sebutkan di sini (@gund).

Saya telah menerapkan pembantu dekorator kecil ( @ObservableInput ) yang memperluas secara internal dekorator @Input dan memungkinkan komposisi semacam ini. Anda dapat memeriksanya di sini (juga sebagai npm package ). Saya telah mengujinya dengan contoh-contoh sederhana, tetapi saya tidak punya waktu untuk menggunakannya untuk proyek-proyek yang diperpanjang. Setiap umpan balik diterima :)

Berikut contoh penggunaan:

@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}`)
  );
}

Dan komponen ini dapat digunakan seperti ini:

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

@aleics Apakah Anda yakin ini akan berfungsi dengan kompiler AOT?

@aleics Apakah Anda yakin ini akan berfungsi dengan kompiler AOT?

Tidak, tentu saja tidak out of the box, karena properti @Input tidak didefinisikan secara eksplisit. Tetapi Anda dapat mendefinisikan modul Anda dengan CUSTOM_ELEMENTS_SCHEMA , seperti saat menggunakan Komponen Web, dan kemudian harus dikompilasi.

Masalah ini telah terbuka selama 5 tahun . Saya pikir ini perlu untuk memfasilitasi pendekatan pemrograman reaktif

Ivy akhirnya ada di sini, jadi saya kira seseorang punya waktu untuk mengerjakan yang satu ini? Mohon mohon mohon!

Omg saya berlangganan ini sangat dibutuhkan. Data input harus dipancarkan sebagai sumber reaktif, dan Anda harus menggunakan solusi agar berfungsi di ngOnChanges

Sangat menantikan ini

Saya menyadari bahwa Angular adalah open source, tetapi apakah saya salah atau naif untuk berpikir bahwa proyek yang dijalankan oleh Google harus dapat menyelesaikan masalah yang sangat berbintang dan diminta dalam waktu kurang dari 5 tahun? Apakah ada beberapa masalah keuangan yang tidak saya ketahui yang mencegah Google mempekerjakan lebih banyak pengembang untuk bekerja di Angular?

@ etay2000 Saya tidak tahu, saya pikir agak lucu bagaimana Anda dapat melakukan 75% hal di Angular dengan rxjs dan kemudian untuk sesuatu yang mendasar dan biasa digunakan sebagai input komponen, tiba-tiba Anda dipaksa ke prosedural dunia. Anda selalu mendapatkan bagian penting dari proyek Anda yang tidak dapat bekerja dengan dunia yang dapat diamati, jadi Anda selalu terpaksa menggunakan boilerplate untuk merekatkannya kembali. Anda tidak akan pernah bisa mencapai pendekatan yang berfungsi penuh untuk proyek Anda. Jadi masalah ini terbuka selama 4 tahun mengingatkan saya pada kurangnya pragmatisme yang membuat saya menjauh dari Angular dan ke kerangka kerja lain, untuk itu cukup berguna. Jika Anda ingin menggunakan rxjs untuk semuanya, mungkin cycle.js adalah solusi yang lebih baik, dan jika Anda tidak ingin dipaksa untuk menggunakan rxjs sama sekali, mungkin Vue. Harus menggunakan yang dapat diamati separuh waktu dan tidak dapat menggunakannya separuh lainnya tidak masuk akal. Untuk mengintegrasikan abstraksi yang sangat kuat dengan kurva belajar yang tinggi dan kemudian gagal untuk mengintegrasikan sepenuhnya, itu hanya membingungkan.

Saya merasa seperti rantai prioritas berjalan seperti ini

persyaratan pengguna google internal -> apa pun yang berkaitan dengan kompiler yang lebih cepat -> apa pun yang berkaitan dengan ukuran aplikasi yang lebih kecil -> apa pun yang tidak mengganggu pendatang baru -> apa yang sebenarnya diinginkan pengembang

Dan sementara pemimpin teknologi akan mengatakan bahwa mereka setuju bahwa itu penting, kenyataannya adalah bahwa Igor dan Misko cenderung memikirkan sebagian besar masalah dalam hal kompilasi template, view binding, dan rendering. Tidak peduli apa yang dikatakan konsumen Angular penting bagi mereka, solusinya selalu mengubah sistem templating, atau menulis penyaji baru, atau membuat kompiler lebih baik.

sumber: https://medium.com/@jeffbcross/jeffs-letter-to-the-angular-team-and-community-5367934a16c9)

Lihat saja beberapa masalah yang paling banyak dipilih.

Proposal: Masukan sebagai Observable #5689

Dibuat 5 tahun yang lalu, balasan terakhir dari anggota tim yang relevan - 5 tahun yang lalu, status saat ini tidak diketahui.

Dukung aliran acara dingin di templat #13248

Dibuat 4 tahun yang lalu, balasan terakhir dari anggota tim yang relevan - 1 tahun yang lalu, status saat ini - menunggu Ivy mendarat.

Proposal: Berikan Kait Siklus Hidup Komponen sebagai Observable #10185

Dibuat 4 tahun yang lalu, balasan terakhir dari anggota tim yang relevan - 3 tahun yang lalu, status saat ini tidak diketahui.

Proposal: Perlu kemampuan untuk menambahkan arahan ke elemen host dalam deklarasi komponen. #8785

Dibuat 4 tahun lalu, balasan terakhir dari anggota tim yang relevan - 2 tahun lalu, status saat ini tidak diketahui.

as local-val tanpa *ngIf #15280

Dibuat 4 tahun lalu, balasan terakhir dari anggota tim yang relevan - 2 tahun lalu, status saat ini tidak diketahui.

Dukungan untuk Proyeksi Konten Dinamis #8563

Dibuat 4 tahun yang lalu, balasan terakhir dari anggota tim yang relevan - 3 tahun yang lalu, status saat ini tidak diketahui.

konten default ng-konten #12530

Dibuat 4 tahun yang lalu, balasan terakhir dari anggota tim yang relevan - tidak pernah, status saat ini tidak diketahui.

Lalu ada hal-hal seperti fitur komponen, yang memungkinkan komponen dengan urutan lebih tinggi, lalu tentu saja ada lebih banyak lagi masalah yang paling banyak dipilih, tetapi ini saya harap akan diatasi (yaitu, ditangani, tidak harus mengharapkannya segera diimplementasikan setelah Ivy ), karena mereka ada hubungannya dengan penggunaan kerangka kerja DAN reaktivitas sehari-hari, yang, saya pikir tidak ada yang akan membantah, adalah apa yang digunakan kebanyakan orang (mengingat ngrx adalah lib manajemen negara paling populer).

Aplikasi saya penuh dengan setengah matang (hanya karena keterbatasan teknis, beberapa hanya dapat dilakukan dengan benar di inti) "polyfills" dan meretas sebagian besar masalah ini, dengan harapan suatu hari nanti saya dapat memasukkan asli sudut penggantian. Tapi entah kenapa sepertinya tidak datang.

Jadi ya, katakanlah posting blog yang membahas status beberapa reaktivitas / pengalaman pengembang terbesar terkait masalah akan sangat dihargai.

Bagaimana kalau kita mencoba membuat kode versi pertama dari fitur ini sendiri? Aku
sekarat kebosanan selama hal covid, siapa yang mau bergabung dengan saya?

Beberapa orang sudah melakukannya, mis. https://github.com/insidewhy/observable-input

Masalah dengan sebagian besar dari ini adalah untuk melakukannya secara efisien, Anda perlu memodifikasi kompiler atau bagian internal lain dari angular.

Itu tidak masuk hitungan. Maksud saya mari kita lakukan kontribusi yang tepat untuk sudut
inti. Lagi pula, kami memiliki kode sumber yang tersedia. Sebenarnya, saya tidak berpikir bahwa kita bahkan perlu menyentuh kompiler dalam kasus ini.

@ganqqwerty Saya mencoba mengimplementasikannya di dalam Angular sebelum saya menulis perpustakaan itu. Angular sangat rumit sekalipun. Agar adil, kodenya jauh lebih mudah dibaca dan dimengerti daripada React dan fungsi-fungsinya yang panjang lima ratus baris, tetapi "canggih". Dan saya tetap akan dengan senang hati melakukan upaya untuk membuat implementasi itu jika saya pikir itu bermanfaat. Tapi saya tidak melihatnya berharga karena alasan @fxck yang diulang di atas. Tim Angular tidak mendengarkan komunitas, mereka terus-menerus terobsesi dengan pengoptimalan dan kinerja tanpa mempedulikan kegunaan Angular secara umum. Saya tidak peduli tentang kerangka kerja yang berkinerja baik ketika memaksa saya untuk menerapkan boilerplate untuk masalah sederhana yang ditunjukkan lima tahun lalu. Jadi saya memutuskan untuk berhenti peduli tentang Angular, menerapkan upaya minimal yang saya butuhkan untuk mendukung proyek yang sudah saya kerjakan dan menghindarinya di mana pun dan kapan pun memungkinkan untuk semua proyek di masa depan.

Ini bukan hanya masalah dengan Angular, saya pikir, tetapi dengan banyak penawaran dari Google. Masalah ini dan masalah lain yang @fxck tercantum di atas hanyalah lebih banyak contoh masalah endemik di Google. Jika Anda melihat Dart atau GoLang, Anda juga akan melihat pengembang mengajukan masalah umum yang sangat terkenal dan masalah tersebut dibiarkan terbuka selama 5+ tahun.

Saya setuju ini harus ditambahkan, tapi wow, kebencian di utas ini agak berlebihan, maksud saya kita berbicara tentang menambahkan sesuatu yang menghemat beberapa baris kode. Anda dapat memiliki input yang dapat diamati sekarang dengan setter yang didekorasi dengan @Input dan subjek Anda sendiri yang Anda masukkan nilai ke:

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

Jika itu terlalu banyak, kami sudah memiliki beberapa opsi pihak ketiga yang sederhana:

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

Saya senang dengan pengembangan Angular, dan tentu saja tidak akan meninggalkan kerangka kerja berfitur lengkap dan andal yang luar biasa karena fitur yang kecil (walaupun diinginkan)

Masalah umum terutama dari perspektif bagaimana orang melihatnya. Bagi seseorang, ini adalah beberapa baris kode dan kelihatannya cukup sederhana untuk mengubah/menambahkan apa pun, tetapi pada kenyataannya, ada banyak ruang lingkup yang lebih besar dan banyak efek samping. Semuanya harus diperhitungkan dan seperti biasa, garis topiknya panjang dan semuanya memiliki harga biaya, nilai tambah, dan prioritas.

Saya ingin menunjukkan bahwa saya pribadi tidak selalu mengharapkan semua masalah ini segera diselesaikan.

Tapi saya berharap, bahwa sekarang, bahwa Ivy keluar dari jalan dan berada di alam liar untuk sementara waktu, semacam pembaruan resmi tentang, katakanlah, 25 masalah teratas yang dipilih, akan diterbitkan.

Maksud saya, saya tidak merasa mungkin untuk proyek sebesar ini untuk tidak dianggap prioritas dalam manajemen proyek dan semacam rencana untuk semua 25 masalah teratas (atau apa pun). Sebagian besar bahkan memiliki tag effort . Buat saja posting blog, beri tahu komunitas bahwa Anda tahu tentang ini dan Anda punya semacam rencana untuk mereka.

Saya tentu tidak akan meninggalkan Angular juga, untuk semua kekurangannya saya masih menyukainya jauh lebih baik daripada semua alternatif lainnya. Tapi saya pikir adil untuk mengatakan itu kurang dalam "manajemen hubungan masyarakat" (khususnya di github).

// edit

Apakah Anda orang baik keberatan mengisi jajak pendapat ini? Mengingat situasi Anda saat ini dan semua hal yang dipertimbangkan, masalah mana yang paling memengaruhi Anda / akan meningkatkan pengalaman pengembang Anda paling banyak https://forms.gle/cprhx239kuqwWd5M8

@fxck Terima kasih telah menulis itu. Saya mulai bertanya-tanya apakah semua orang baru saja menerima kenyataan bahwa tim Angular akan melakukan apa yang mereka inginkan, kapan pun mereka mau. Meskipun itu adalah hak mereka, saya juga berpikir perlu bagi orang-orang untuk memanggil mereka ketika mereka terus-menerus mengabaikan suara pengembang. Saya setuju bahwa saya tidak berpikir ada orang yang mengharapkan penyelesaian masalah segera, tetapi mengabaikannya selama 4-5 tahun atau hanya menunggu sampai masalah terkunci secara otomatis tampaknya sangat tidak profesional untuk proyek apa pun, apalagi proyek yang dijalankan Google. Mereka mengulur waktu dengan menambahkan tag 'Diperbaiki oleh Ivy' ke banyak masalah terbuka, lalu menindaklanjutinya dengan tidak melakukan apa-apa.

Saya tentu tidak akan meninggalkan Angular juga, untuk semua kekurangannya saya masih menyukainya jauh lebih baik daripada semua alternatif lainnya. Tapi saya pikir adil untuk mengatakan itu kurang dalam "manajemen hubungan masyarakat" (khususnya di github).

Saya pikir kalimat itu merangkum pikiran saya dengan sempurna.

@chriszrc Saya tidak benar-benar menafsirkan apa pun di utas ini sebagai 'benci'. Lebih seperti orang akhirnya melampiaskan frustrasi mereka dengan Angular secara teratur mengabaikan masalah selama bertahun-tahun pada suatu waktu. Ini bahkan bukan tentang masalah ini secara khusus, ini lebih tentang prinsip memelihara beberapa bentuk interaksi masyarakat. Apakah tim Angular dianggap jauh lebih unggul daripada orang lain sehingga mereka merasa dapat mengabaikan permintaan pengembang karena mereka tahu apa yang terbaik untuk semua orang?

@chriszrc Saya tidak melihat kebencian di utas ini, hanya sekelompok frustrasi yang bisa dimengerti. Saya pikir menyamakan permintaan ini dan kekecewaan terkait dengan "menghemat beberapa baris kode" adalah berlebihan. Bukan hanya masalah ini yang membuat komunitas frustrasi, tetapi kumpulan signifikan dari masalah populer yang diangkat oleh @fxck di atas telah diabaikan.

Hai semuanya, maafkan kami atas keheningan di utas ini. Ada dua permintaan ortogonal yang telah kami dapatkan untuk sementara waktu:

1. Dukungan RxJS kelas satu yang lebih baik dalam kerangka kerja
2. Lebih sedikit RxJS di Angular, berpotensi menjadikannya opsional

Kedua permintaan ada di radar kami, dan keduanya memiliki pro dan kontra. Misalnya, jika kita pergi ke arah pertama, kita akan membuat kerangka kerja kurang dapat diakses oleh para insinyur yang baru mengenal API RxJS yang ekspresif dan kaya secara semantik. Banyak orang memiliki kekhawatiran dalam menggunakan RxJS di mana saja di aplikasi Angular mereka, membuat kode sumber sulit dibaca di seluruh anggota tim dengan tingkat pengalaman yang berbeda.

Pada saat yang sama, kami sudah memiliki banyak API reaktif, tetapi beberapa primitif yang ditawarkan oleh Angular sepenuhnya penting, dan banyak hal yang tidak terhubung dengan baik. Yang mengatakan, masuk akal untuk meningkatkan dukungan reaktivitas, tetapi haruskah ini menjadi bagian dari inti Angular atau didelegasikan ke proyek komunitas (ngrx - ekstensi reaktif Angular, misalnya) yang berkolaborasi erat dengan kami?

Ada banyak cara untuk mengatasi masalah ini, tetapi kita perlu mempertimbangkan:

• Kompatibilitas mundur - tidak hanya untuk kode sumber tetapi juga sumber daya pelatihan
• kurva belajar
• Konsistensi dengan API saat ini
• Konsistensi di seluruh proyek
• Performa - waktu proses dan waktu muat awal

Kami sedang dalam proses memprioritaskan beberapa masalah GitHub teratas, melihat peningkatan yang paling banyak diminta dan berdampak yang dapat kami atasi. Saya akan mengatakan bahwa ini adalah salah satu yang lebih menantang, jadi sulit untuk berkomitmen untuk berkencan.

@mgechev Terima kasih telah menanggapi. Jika rxjs dan api reaktif akan dipecah menjadi ekstensi lain (bukan suara pribadi saya), apakah mungkin lebih masuk akal untuk tidak digabungkan dengan implementasi state-store/redux tertentu? Saya dengan cepat beralih dari ngrx ke ngxs (yang terasa seperti lebih sedikit boilerplate, dan jauh lebih "sudut" dengan dekorator) dan akhirnya ke Akita, yang merupakan favorit saya saat ini dan yang paling banyak saya kembangkan. Atau jika disamakan dengan ngrx, paling tidak buat sangat mudah dengan menambahkan bagian yang kita butuhkan, jadi kita tidak terkunci untuk menggunakan ngrx atau menyertakan dependensi itu-

Jika rxjs dan api reaktif akan dipecah menjadi ekstensi lain (bukan suara pribadi saya)

Saya tidak mengatakan itu yang akan terjadi. Dalam komentar saya, saya hanya membagikan daftar alternatif yang tidak lengkap sehingga saya dapat menunjukkan ruang lingkup proyek dan pertimbangan berbeda yang kami miliki.

@mgechev memang, terima kasih atas jawabannya.

Namun saya bertanya-tanya, jika bagian reaktif dari Angular entah bagaimana "diturunkan" ke dalam proyek komunitas, bukankah itu berarti reaktif akan menjadi warga negara kelas dua Angular?

@mgechev Saya merasakan sakit Anda terkoyak ke dua arah sekaligus. Tim kami sebenarnya tidak menentang pemisahan bagian imperatif/reaktif.

Inilah persyaratan kami untuk pemisahan seperti itu:

• Menggunakan kebutuhan imperatif dan reaktif untuk merasa asli dan tidak ada yang harus merasa terikat
• Tidak ada ikatan dengan solusi manajemen negara bagian tertentu untuk mengaktifkan reaktif (pengungkapan penuh kami telah memigrasikan semua 50+ proyek untuk menggunakan akita sekarang)
• Kedua opsi tersebut perlu dirilis dalam satu versi secara bersamaan (tidak ada lag/delay)
• Tidak boleh ada "favorit", apa pun yang sudut perlu bekerja di kedua dunia sambil merasa asli
• Dukungan resmi penuh untuk kedua pendekatan yang didukung oleh tim sudut (Berdasarkan pengalaman kami, ini adalah persyaratan pelanggan hard stop pelanggan)

Berdasarkan hal di atas:

• Ada 2 opsi utama:
  
  
  
  • inti imperatif + addon reaktif
  
  
  • inti reaktif + addon imperatif
  
  
• Membungkus reaktif untuk membuatnya tampak penting cukup mudah, tidak begitu untuk sebaliknya
• Oleh karena itu kami akan memilih untuk menggunakan reaktif di inti dan membuat addon berisi API imperatif
• Karena penundaan nol + tidak ada persyaratan favorit serta dukungan resmi yang diperlukan, saya tidak melihat bagaimana addon dapat menjadi proyek komunitas

Saya mengerti di atas adalah pandangan kita tentang dunia dan masih banyak pandangan lain. Alasan saya menulis ini adalah:

• Jika Anda berhasil mengekstrak reaktif ke dalam proyek komunitas, kami harus memigrasikan 50+ solusi ke kerangka kerja lain (sekali lagi ini akan didorong oleh pelanggan, bukan pilihan kami)
• Jadi saya akan meminta untuk memberi tahu kami (komunitas) secepatnya di mana Anda mendarat di sini sehingga kami punya waktu untuk melatih ulang para pengembang kami di kerangka kerja lain dan memigrasikan proyek-proyek itu

tolong tambahkan fiturnya

@mgechev Saya tidak mengerti kekhawatiran Anda. Proposal ini adalah tentang menggabungkan dua dunia dengan antarmuka pengembang pemula yang seragam dan langsung. Ini bukan tentang memilih satu atau yang lain melainkan mengaktifkan kombinasi. Misalnya pengembang x memutuskan untuk membangun komponen reaktif yang mengagumkan. Dan pengembang y memutuskan untuk menggunakannya dalam proyeknya yang tidak terlalu reaktif. Kenapa tidak? Mengapa dia harus bergantung pada lem ngrx?
Perbedaan antara dua dunia adalah apakah Anda menyimpan/mengelola status di komponen cerdas utama Anda vs penyimpanan status pusat dan itulah yang seharusnya menjadi ngrx, tetapi untuk komponen saya merasa bahwa kerangka kerja itu sendiri harus menjadi enabler.

Ada dua permintaan ortogonal yang telah kami dapatkan untuk sementara waktu:

1. Dukungan RxJS kelas satu yang lebih baik dalam kerangka kerja
2. Lebih sedikit RxJS di Angular, berpotensi menjadikannya opsional

Saya akan baik-baik saja, tetapi kadang-kadang ini kadang-kadang yang memberikan perasaan terputus-putus pada Angular, yang merupakan hal terakhir yang Anda lakukan kecuali dari kerangka kerja yang termasuk baterai.

Secara pribadi, saya ingin tahu bagaimana Anda bahkan memiliki versi non-RxJS untuk semua paket Angular (HTTP, Router, Formulir). Saya menduga tidak ada versi non-RxJS yang bagus dari ini, itulah sebabnya mereka memiliki RxJS di tempat pertama.

Artinya .... kecuali saya kehilangan sesuatu, (2) tidak layak.

PS Saya tidak akan menggambarkan permintaan tersebut sebagai "ortogonal"; lebih seperti "berlawanan."

Lebih sedikit RxJS di Angular, berpotensi menjadikannya opsional

Karena penasaran @mgechev , apakah ada masalah Github untuk itu? (Saya belum pernah melihatnya.) Atau apakah ini lebih seperti Googler?

@pauldraper Saya telah melihat setidaknya satu masalah di github di mana seseorang mengeluh tentang betapa rumitnya rxjs dan menginginkannya sepenuhnya opsional. Secara pribadi saya suka rxjs, tetapi saya telah bekerja dengan dua tim sekarang di mana itu membawa ketakutan dan kebencian kepada pengembang junior dan senior. Juga, ortogonal adalah istilah yang lebih baik daripada yang berlawanan, karena dimungkinkan untuk mengimplementasikan kedua permintaan pada saat yang sama (mengingat setiap solusi dapat bekerja tanpa satu mengurangi yang lain dengan menyediakan beberapa opsi API untuk mengkonsumsi hal-hal secara reaktif dan imperatif).

Untuk setiap satu komentar yang mengeluh tentang rxjs di github mungkin ada ribuan pengembang yang menggunakan dan menikmatinya tanpa masalah.

Berikut adalah hasil dari formulir yang saya posting di atas (hampir 200 orang merespons), saat saya mendiskusikannya di Angular discord.

Tidak mengherankan bentuk adalah rasa sakit terbesar di pantat, tetapi tampaknya @brandonroberts dan @MikeRyanDev mungkin memasak sesuatu, akhirnya.

Untuk setiap satu komentar yang mengeluh tentang rxjs di github mungkin ada ribuan pengembang yang menggunakan dan menikmatinya tanpa masalah.

Meskipun saya suka rxjs, saya tidak seoptimis ini. Saya bekerja dengan banyak pengembang yang begitu lelah memikirkan harus meluangkan waktu untuk mempelajari sesuatu dengan kurva belajar yang curam adalah mimpi buruk. Dan banyak yang lebih peduli tentang menghasilkan uang daripada coding :D Atau pengembang junior agresif yang berpikir bahwa apa pun yang tidak dapat mereka pelajari dalam waktu sehari pasti sampah.

Saya bekerja dengan banyak pengembang yang begitu lelah memikirkan harus meluangkan waktu untuk mempelajari sesuatu dengan kurva belajar yang curam adalah mimpi buruk. Dan banyak yang lebih peduli tentang menghasilkan uang daripada coding

Itukah yang coba dipenuhi oleh para pengembang Angular, terbakar habis dan tanpa mau belajar? :) Dan siapa yang peduli pada saat ini. Angular sudah ada untuk sementara waktu, tidak akan kemana-mana dan sama sekali tidak akan kehilangan daya tarik jika Anda menambahkan siklus hidup yang dapat diamati, masukan yang dapat diamati, peristiwa yang dapat diamati. Cukup tambahkan tiga hal kecil itu dan orang-orang akan senang untuk sementara waktu, itu saja (dan ikuti itu dengan https://indepth.dev/component-features-with-angular-ivy/ untuk menyelesaikan paket dasar).

Yang satu ini mengatakan itu semua. IMHO Angular harus tetap konsisten dan menggunakan lebih banyak RxJS: tanpa RxJS sama sekali itu tidak akan menjadi Angular.

Itukah yang coba dipenuhi oleh para pengembang Angular? :)

Ya, alangkah megahnya jika hanya melayani pengembang yang ingin menulis kode menggunakan rxjs. Meskipun saya lebih suka menggunakan rxjs, saya ingin Angular melayani kedua set pengembang. Mengapa Angular hanya melayani kita dan bukan mereka yang berpikir berbeda? Terutama ketika saya percaya bahwa kita adalah minoritas, bukan mayoritas.

Sekali lagi, menjadi "sepenuhnya reaktif", seperti menambahkan siklus hidup yang dapat diamati, input, acara tidak akan memengaruhi apa pun yang Anda bicarakan, tetapi akan membuat grup lain sangat senang.

Dan fitur komponen berguna apakah Anda menyukai pemrograman reaktif atau tidak.

@fxck saya tidak pernah setuju dengan itu untuk kedua. Saya baru saja menanggapi komentar Anda sebelumnya untuk menunjukkan bahwa ada banyak orang yang tidak ingin menggunakan rxjs dan banyak dari mereka telah membuka masalah github untuk mengeluh tentang hal itu.

Terlepas dari bagaimana angular memutuskan untuk mengembangkan inti - secara reaktif atau tidak, di dunia ideal akan ada paket berlawanan yang dibangun di atas untuk memenuhi kebutuhan yang berlawanan (misalnya @angular/reactive atau @angular/imperative - dengan nama yang lebih baik semoga).

Salah satu dari dua komunitas ini bagi saya adalah penurunan peringkat bagi sebagian orang dan bagi saya sudut pandang memiliki pandangan menjadi kerangka kerja reaktif yang hebat adalah alasan untuk melakukannya sejak awal.

Di samping catatan, saya pikir akan lebih mudah menjaga reaktif sudut dan memiliki ekstensi imperatif, karena ini jauh lebih mudah untuk menjembatani, daripada menjembatani imperatif ke reaktif - berbicara untuk kesederhanaan inti dan paket ekstensi.

Penafian: poin terakhir yang saya rumuskan berdasarkan asumsi - tidak akan terkejut jika lebih mudah untuk menulis inti imperatif - ekstensi reaktif akan lebih kompleks.

Karena penasaran @mgechev , apakah ada masalah Github untuk itu? (Saya belum pernah melihatnya.) Atau apakah ini lebih seperti Googler?

Bukan masalah internal Google. Anda akan terkejut (sama seperti saya, ketika saya bergabung dengan tim), seberapa besar persimpangan antara persyaratan eksternal dan internal. Perbedaan utama terletak pada sistem build dan manajemen ketergantungan, selain itu Googler memiliki persyaratan yang hampir sama dengan non-Googler.

Kami berhubungan dengan ribuan pengembang - banyak perusahaan eksternal, tim internal, dan kontributor individu. Dalam kedua kasus, ada orang yang ingin sepenuhnya menggunakan RxJS dan orang lain yang tidak menganggapnya sebagai pilihan yang tepat untuk mereka. Kedua kubu memiliki argumen yang sangat baik.

Ini bukan keputusan yang ingin kami buru-buru, terutama karena ada solusi/solusi komunitas yang sudah mapan. Pekerjaan yang dilakukan di komunitas membantu kami mengumpulkan poin data tambahan dan menetapkan solusi optimal untuk kumpulan variabel saat ini.

Saya pikir memiliki satu pendekatan terpadu yang reaktif atau imperatif (ini menjadi pilihan per proyek) ketika mengembangkan aplikasi sudut akan sangat bermanfaat. Kemampuan untuk mencampur dan mencocokkan tidak membantu pengalaman pengembangan dan membuat kode non DRY (mis. input non reaktif).

Tidak ada yang terjadi dalam isolasi, jadi saya benar-benar dapat memahami lingkungan perusahaan yang mengalami kesulitan untuk melatih kembali sejumlah besar pengembang ke pemrograman reaktif. Jadi menjatuhkan imperatif benar-benar akan memindahkan sudut keluar dari sweet-spot perusahaan, yang memungkinkan realistis tidak akan terjadi karena itu merupakan basis pengguna utama yang besar untuk kerangka kerja seperti sudut.

Yang mengatakan apa yang saya tidak lihat realistis adalah membangun antarmuka reaktif di atas antarmuka yang imperatif. Arah lainnya cukup lurus ke depan karena Anda selalu dapat menulis output dari yang dapat diamati ke dalam variabel yang kemudian dapat digunakan secara imperatif. Sebenarnya itulah yang sudah dilakukan angular di banyak tempat di bawah penutup.

Karenanya saya memilih untuk membuat sudut sepenuhnya reaktif pada intinya dan kemudian membuat "pembungkus" imperatif di atasnya.

Masalah utama dengan pendekatan ini kemungkinan besar adalah langkah migrasi yang lebih besar untuk pengguna penting. Yang merupakan nono di lingkungan perusahaan yang mungkin persis seperti yang coba dicegah oleh tim sudut, oleh karena itu saran untuk melakukan keharusan pada intinya.

@mgechev Karena ini telah diangkat beberapa kali, akan menarik untuk mendengar pendapat Anda tentang inti reaktif/ekstensi imperatif dan apakah ia memiliki kaki untuk berdiri?

Dalam kedua kasus, ada orang yang ingin sepenuhnya menggunakan RxJS dan orang lain yang tidak menganggapnya sebagai pilihan yang tepat untuk mereka. Kedua kubu memiliki argumen yang sangat baik.

Bagus, bagus untuk diketahui. Tetapkan menjadi penuh dengan RxJS? Bagaimana menambahkan siklus hidup yang dapat diamati, input yang dapat diamati, dan peristiwa yang dapat diamati cocok dengan itu? Dan tidak, tidak satu pun dari ini yang benar-benar memiliki "solusi/solusi komunitas yang mapan".

@fxck tidak satu pun dari ini yang benar-benar memiliki "solusi/solusi komunitas yang mapan".

Itu benar. Saya menulis salah satu solusi ini dan itu hanya berfungsi karena satu peretasan besar yang bergantung pada pengecekan tipe yang buruk di templat. Saya telah memeriksa beberapa solusi lain yang diposting di utas ini juga dan masing-masing memiliki setidaknya satu dari masalah berikut:

• kebocoran langganan
• persyaratan boilerplate pada pengguna
• peretasan seburuk, jika tidak lebih buruk, daripada yang saya gunakan di perpustakaan saya.

Sejauh yang saya ketahui, tidak mungkin melakukan ini dengan baik.

Peristiwa yang dapat diamati bahkan lebih buruk, tidak ada banyak solusi komunitas sama sekali, mereka biasanya memerlukan langkah build tambahan (yang dalam beberapa kasus merusak SSR dalam pengaturan monorepo) dan bahkan meretasnya (jika Anda menggunakan ekstensi kelas misalnya untuk dapatkan acara siklus hidup yang dapat diamati, karena hei, angular tidak mendukungnya secara asli) https://github.com/typebytes/ngx-template-streams/issues/8

Peristiwa siklus hidup bisa dibilang yang "termudah", tetapi masih harus bergantung pada ekstensi kelas atau dekorator khusus, tidak ada yang ideal.

@fxck Sejauh yang saya ketahui, tidak mungkin untuk membersihkan langganan acara siklus hidup tanpa harus menggunakan kelas induk (eugh) atau metode yang harus dipanggil pengguna dari acara siklus hidup penghancuran mereka sendiri (bahkan lebih buruk).

Peristiwa siklus hidup bisa dibilang yang "termudah", tetapi masih harus bergantung pada ekstensi kelas atau dekorator khusus, tidak ada yang ideal.

Saya telah mencoba mengimplementasikan peristiwa siklus hidup (untuk membuatnya reaktif) dengan dekorator khusus juga dan itu menyebalkan. ~Tanpa ekstensi kelas, saya tidak tahu apakah itu mungkin tanpa 100 peretasan~. Kemungkinan pengguna untuk memperluas sudut sejauh ini sangat buruk dan bergantung pada peretasan atau banyak boilerplate untuk melakukannya.

@tonivj5 Jika fitur komponen akan menjadi api publik, apakah Anda melihat ini sebagai cara potensial untuk mengimplementasikan siklus hidup tanpa pewarisan?

@ntziolis hah lucu Anda harus menyebutkan fitur, saya sebenarnya sedang mengerjakan bagian siklus hidup dari sub-bentuk ngx dan fitur adalah sesuatu yang menurut saya akan membantu. Sementara itu, sangat mungkin untuk menambal pabrik komponen dengan ivy. Saya melihat ini sangat berguna di luar ngx-sub-form, jadi saya pikir saya akan membagi logika ini menjadi lib terpisah

@ntziolis pada titik ini saya tidak yakin apakah kita akan pernah melihat janji Ivy benar-benar disampaikan.

Sudahkah Anda memeriksa efek sudut? (bukan ngrx/effects) https://dev.to/stupidawesome/reactive-adventures-in-angular-introducing-angular-effects-1epf Dengan alat ini Anda dapat menulis aplikasi yang sepenuhnya reaktif.
Status dua arah yang dapat diamati antara komponen induk dan anak-anak disertakan
https://dev.to/stupidawesome/exploring-the-angular-effects-api-2gol
Versi 9.1.0 akan memperkenalkan model komposisi/kait berdasarkan Composition API Vue 3.
Saya pikir ini adalah langkah selanjutnya untuk angular untuk bekerja dengan reaktivitas.

@mgechev

Ini bukan keputusan yang ingin kami buru-buru, terutama mengingat ada solusi/solusi komunitas yang sudah mapan

Hanya ingin tahu, siapa kita dan berapa banyak Googler yang secara aktif berkontribusi pada proses pengambilan keputusan Angular?

Anda menunjukkan ini bukan keputusan yang harus terburu-buru, tapi saya bertanya-tanya apa definisi Anda tentang tidak terburu-buru? Apakah ini salah satu yang menampar tag 'Diperbaiki oleh Ivy' dan mengabaikannya sampai lebih banyak pengembang mulai membuat kebisingan lagi mengetik situasi? Apakah ada versi yang ditargetkan untuk pekerjaan reaktif atau apakah ada versi kompiler baru lainnya yang harus dirilis terlebih dahulu?

Apakah fakta bahwa biasanya ada 2.500 isu terbuka pada waktu tertentu pernah muncul dalam diskusi internal?

@ntziolis , seperti yang dikatakan @zakhenry , saya pikir features akan membantu

@ntziolis Saya telah mencoba lagi dengan siklus hidup dan saya memiliki POC yang berfungsi (tanpa ekstensi kelas atau mengimplementasikan antarmuka siklus hidup). Itu bergantung pada API pribadi (: seru :)

@tonivj5 hah saya belum sempat membaca milik Anda, tetapi solusi saya hampir dirilis juga :) https://github.com/cloudnc/ngx-observable-lifecycle

Gagasan dengan lib yang sedang saya kerjakan adalah untuk memiliki basis umum yang dapat digunakan oleh lib lain untuk membuat fungsionalitas sadar siklus hidup mereka sendiri. Itu harus dapat bekerja sedemikian rupa sehingga jika ada beberapa fungsi yang menginginkan akses ke kait yang sama, hanya ada satu kait yang didekorasi ke komponen def.

Saya sudah menjalankan semuanya, hanya perlu mengurutkan CI dan unit test.

Apakah fakta bahwa biasanya ada 2.500 isu terbuka pada waktu tertentu pernah muncul dalam diskusi internal?

Lol, belum ada 2.500 masalah terbuka sejak pertengahan 2019.

$ 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)  |
+-------------------------+--------------------+

Menurut selera saya, saya lebih suka proyek sumber terbuka yang membuat masalah tetap terbuka untuk didiskusikan sampai ada diskusi/konsensus komunitas yang jelas daripada proyek yang menutup setiap masalah yang dibuka tanpa diskusi. Ini juga merupakan langkah bagi pengelola untuk menjelaskan kekhawatiran mereka dari waktu ke waktu kepada komunitas sebelum mereka menutup kemungkinan untuk menerima proposal.

@agalazis Masalah ini telah terbuka selama 4 1/2 tahun dan cukup banyak diabaikan selama 3 tahun terakhir.

@agalazis Masalah ini telah terbuka selama 4 1/2 tahun dan cukup banyak diabaikan selama 3 tahun terakhir.

Ada anggota tim Angular yang menjelaskan mengapa ini masih buka hanya 5 hari yang lalu jadi Anda tidak benar.

@etay2000 Beberapa keputusan terkadang sulit karena mempengaruhi evolusi seluruh proyek dan itu dapat diterima Pengembang dapat menyadari bahwa mereka tidak dapat mengandalkan fitur dalam waktu dekat seiring berjalannya waktu, tetapi jika ada kemungkinan mengapa membunuhnya sebelum waktunya? Saya percaya bahwa hal termudah adalah menolak proposal dan menutup masalah tetapi itu tidak terjadi karena suatu alasan.

@beeman

Ada anggota tim Angular yang menjelaskan mengapa ini masih buka hanya 5 hari yang lalu jadi Anda tidak benar.

Anda benar-benar menyukai emoji jempol ke bawah itu ya? Apakah itu benar-benar penjelasan? Setelah 4+ tahun dia mengatakan mereka tidak ingin terburu-buru mengambil keputusan.

@agagalazis
Saya setuju beberapa keputusan sulit, tetapi apa yang harus dianggap sebagai kerangka waktu yang dapat diterima untuk menunda membuat keputusan sulit itu? Tidak semua 2855 isu terbuka melibatkan keputusan sulit ini, namun banyak dari mereka juga telah ada selama beberapa waktu juga.

@etay2000 Terima atau tidak ini adalah open source orang yang membuka masalah lebih dari pengelola. Proyek TypeScript misalnya memiliki hampir dua kali lebih banyak masalah terbuka dan proposal lain yang saya lakukan di sana juga memakan waktu lama. Saya tidak keberatan karena diskusi di sana membawa banyak alternatif yang tidak semewah memiliki fitur tetapi berhasil melihat banyak perspektif lain

@agalazis Anda benar, saya kira saya (salah) mengharapkan lebih banyak dari proyek sumber terbuka yang dikelola oleh Google daripada yang saya harapkan dari proyek yang lebih kecil.

@beeman Masukkan emoji jempol ke bawah di sini: -------->

@etay2000 Anda harus selalu ingat bahwa setiap keputusan penting tersebut memengaruhi ratusan ribu hal, proyek, dan orang. Dan yang lebih penting, keputusan yang tidak sempurna dan pengenalan API publik, yang akan menyebabkan beberapa perubahan besar dalam waktu singkat setelah itu, hanyalah mimpi buruk. Anda dapat melihat hampir pada setiap PR, bagaimana setiap langkah ditinjau, dan jika tidak sempurna, itu hanya menunggu, berminggu-minggu, berbulan-bulan atau bahkan bertahun-tahun.

@agalazis Anda benar, saya kira saya (salah) mengharapkan lebih banyak dari proyek sumber terbuka yang dikelola oleh Google daripada yang saya harapkan dari proyek yang lebih kecil.

Saya tidak tahu, lihat Go dan dart juga. Google sebenarnya cukup terkenal karena mengabaikan permintaan komunitas yang sangat populer selama setengah dekade :D Secara umum pendekatan mereka terhadap bahasa/kerangka/dll. sangat konservatif . Anda dapat melihat bahasa dan ide baru bermunculan yang merevolusi area dan google masih belum mengadopsinya selama bertahun-tahun, misalnya keamanan nol menghantam Kotlin, TypeScript, dan Scala jauh sebelum Dart. Saya kira ada manfaat dan kekurangan dari pendekatan semacam ini, tetapi bagi saya setidaknya saya cenderung menghindari hal-hal yang dikembangkan Google jika memungkinkan karena itu tidak benar-benar sesuai dengan etos saya.

(Maaf untuk ini, semuanya, tapi aku harus melakukannya.)

@beeman Masukkan emoji jempol ke bawah di sini: -------->

@etay2000 Saya tidak tahu bagaimana komentar semacam ini membantu sama sekali, jika bukan pelanggaran perilaku di sini. Saya cukup yakin semua orang tahu cara mengacungkan jempol, jadi apa gunanya sarkasme?

Sebagai pengingat, tidak ada yang dipaksa untuk menggunakan Angular, Anda dapat mencoba menemukan kerangka kerja lain di mana orang lebih menyenangkan Anda.

@brunojcm Saya kira pestanya sudah berakhir sekarang karena komentar polisi ada di sini. Intinya adalah dia mengabaikan semua komentar saya yang lain, tetapi saya tidak menyadari bahwa sarkasme adalah pelanggaran perilaku.

Sebagai pengingat, tidak ada yang dipaksa untuk menggunakan Angular, Anda dapat mencoba menemukan kerangka kerja lain di mana orang lebih menyenangkan Anda.

Cara saya benar-benar ingin menanggapi itu pasti akan melanggar kode etik di sini.

Saya sudah selesai, semua orang dapat kembali ke program yang dijadwalkan secara rutin. Saya akan memeriksa kembali dalam 4-5 tahun lagi untuk melihat bagaimana hasilnya.

@tonivj5 @zakhenry Senang mendengar bahwa ini mungkin jalan.

@mgechev Saya mengerti ini bahkan bukan diskusi awal, tetapi akan senang mendengar pendapat Anda tentang:

• inti reaktif + ekstensi non reaktif vs sebaliknya.
• dan lebih spesifik untuk masalah ini apakah ada peluang realistis untuk mengekspos fitur api dengan cara apa pun.
  
  
  
  • bahkan jika itu hanya dengan peringatan melanggar perubahan di masa depan selama fungsi umum masih dapat diakses.
  
  
  • Seperti yang telah dilakukan @zakhenry untuk peristiwa siklus hidup, saya melihat satu atau sangat terbatas proyek yang membangun API di atas yang dapat digunakan oleh orang lain alih-alih mengakses api ini secara langsung
  
  
  • Anda kemudian dapat bekerja dengan tim pembungkus ini untuk memberi tahu mereka tentang perubahan yang akan datang lebih awal (sangat mirip seperti saran Anda tentang ekstensi reaktif)
  
  

Saya pikir kalian dapat langsung menerapkan modul reaktif Vue 3.0 (ref atau reaktif) dan menyelesaikan masalah ini.

@AnonymousArthur jika Anda berbicara tentang paket @vue/reactivity maka itu sama sekali tidak terkait dengan apa yang kita diskusikan di sini karena memberikan reaktivitas ke properti dan tidak ada hubungannya dengan aliran reative (yang merupakan RxJs).

@gund Ya, saya setuju. Namun percakapan ini memakan waktu cukup lama (4,5 tahun) dan belum selesai, jadi saya hanya muncul ide (mungkin tidak) sangat cepat untuk siapa yang tidak ingin menulis berlangganan/berhenti berlangganan atau ngOnChange Handler. RxJS memang menyediakan fitur reaktivitas dan percakapan ini (tidak membaca semuanya) berbicara tentang membungkus nilai Input dengan Observable sebagai gula sintaksis untuk membuatnya dapat ditonton dan saya pikir itu adalah ide yang luar biasa.

Saya pikir ide ini sangat berguna dan prototipe @robwormald di awal tampak hebat, tetapi saya pikir itu telah mengurangi potensi manfaat dan seberapa kecil dampaknya.

Izinkan saya mengusulkan sedikit perubahan pada solusi itu untuk memperbaiki beberapa kekurangan, tetapi pada dasarnya pendekatan yang sama:

Angular akan mendefinisikan dekorator @OInput() dan tipe EventReceiver<T> yang meluas Observable<T> tetapi juga menambahkan .value getter (seperti BehaviorSubject<T> ).

Di sisi komponen induk , seperti pada contoh @robwormald , tidak ada yang berubah. Jika Anda ingin memberikan nilai Observable di sana, Anda masih memerlukan | async . Atau Anda dapat memberikannya tipe yang tidak dapat diamati, tidak apa-apa (seperti biasa), juga.

Di sisi komponen anak , inilah yang saya usulkan (sedikit penyimpangan dari proposal itu):

@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`
    }
  }
}

Sekarang inilah manfaat dari pendekatan ini, yang menurut saya agak kurang laku:

• Ini memungkinkan desain yang sepenuhnya reaktif secara efektif pada komponen induk dan anak, jika diinginkan.
• Dalam komponen induk, mempertahankan pola desain input Angular yang ada, sehingga tidak ada komponen yang dipaksa ke dalam ini atau harus mendesain di sekitarnya.
• Konteks induk dan anak sepenuhnya independen, induk tidak perlu tahu apakah anak menggunakan Input atau OInput , menghilangkan risiko bug lintas komponen dari perubahan ini.
• Ini relatif mudah untuk memigrasikan sebagian komponen anak tunggal, jika diinginkan, karena Angular membuat semua ini tetap terhubung ke peristiwa siklus hidup yang ada seperti sebelumnya.
• Karena Angular mengimplementasikan fitur ini, semua EventReceiver s secara internal dapat menyertakan pipa melalui takeUntil(ngOnDestroyEvent) , jadi sebagian besar kasus tidak perlu mengingat untuk berhenti berlangganan ketika komponennya dihancurkan, karena yang dapat diamati ini akan selesai secara otomatis . (Yay mengurangi kebocoran memori!)
• Dalam komponen anak ini, ini terlihat dan berfungsi sangat mirip dengan pola @Output() hari ini, jadi memberikan beberapa paralelisme yang bagus dan kemampuan potensial untuk menghubungkannya dengan baik.
  
  
  
  • Catatan tambahan: sebagai tindak lanjut, saya pikir akan keren untuk mengusulkan @InputOutput() yang menggunakan ReplaySubject<T>(1) untuk menghubungkan perilaku untuk pengikatan dua arah dengan lebih mulus dan konsisten. Tetapi itu memiliki tantangan dan argumennya sendiri, jadi saya TIDAK mengusulkannya di sini.
  
  
• Tidak ada tipe boilerplate baru untuk membuat ini berfungsi, ini sesederhana @Output() .
• Angular akan dengan mulus switch() atas perubahan pada Observable yang dimasukkan oleh induknya, jadi pola reaktif yang lebih lemah seperti itu tidak menempel dengan instance Observable yang sama tidak perlu case khusus ( switch() ed) di komponen anak.

Catatan tambahan tentang nama OInput yang saya pilih: Jelas itu terbuka untuk diperdebatkan. Namun, saya pribadi menyukai nama itu karena kependekan dari "Input yang Dapat Diobservasi" DAN karena terlihat seperti "Keluaran" yang dicerminkan.

Tim Angular yang terhormat. Tolong beri kami sesuatu untuk dinantikan di tahun 2020 :-)

Juga solusi @jcomputer persis seperti yang saya inginkan. Bukan penggemar berat nama dekorator yang berbeda, tetapi mungkin layak untuk menambahkan parameter yang mirip dengan bagaimana @ViewChild memiliki { read } . misalnya:

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

Begitu banyak untuk memiliki sesuatu yang dinanti-nantikan pada tahun 2020. :D Kecuali tentu saja ini (dan masalah lain yang tercantum di atas) dianggap sebagai bug dan bukan fitur baru. :)

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

@fxck Saya mungkin memiliki pendapat yang tidak populer di sini, tetapi jujur ​​​​jika 2020 adalah tahun di mana tim Angular memutuskan untuk menghancurkan banyak bug pada formulir, router, dll. Saya tidak akan marah sama sekali dengan 0 fitur : mengangkat bahu:.

Yang mengatakan, mungkin ini lebih merupakan masalah yang terkait dengan peristiwa baru-baru ini dan saya berasumsi ada hal-hal rumit yang terjadi saat ini di tim Angular. Saya harap mereka berhasil mempertahankan orang-orang hebat yang telah aktif membangun Angular sejauh ini : hati:. Tapi itu cerita lain.

Maaf untuk di luar topik. Terbang pergi

@ maxime1992 Akan baik-baik saja juga untuk saya.

Saya mungkin memiliki pendapat yang tidak populer di sini, tetapi sejujurnya jika tahun 2020 adalah waktunya tim Angular memutuskan untuk menghapus banyak bug pada formulir, router, dll. Saya tidak akan marah sama sekali dengan 0 fitur

Tetapi yang membuat saya gugup adalah kenyataan bahwa ada proses SDM jangka panjang yang tidak sehat di dalam tim Angular yang memengaruhi kami, tanpa kami. Terutama dari sudut pandang investasi besar-besaran ke daerah ini.

Dari POV saya, mereka memperbaiki masalah terutama dengan menutupnya melalui BOT - pergi tanpa tanggapan dan ditutup oleh bot.,.. :-/

@montella1507 Tidak, ini tidak sepenuhnya benar. Bot hanya mengunci masalah yang sudah ditutup. Dan memang benar bahwa anggota tim Angular memiliki banyak upaya dalam banyak kasus ketika mereka mencoba menjelaskan apa yang diperlukan untuk menggambarkan dan mereproduksi ketika masalah baru dimasukkan. Ini adalah proses yang sangat memakan waktu dan membutuhkan banyak kesabaran.

Bagi mereka, yang menyalahkan tim Angular dan mengeluh tentang tidak mendapatkan fitur dan perubahan dengan cepat:
Aku mengerti rasa sakitmu. Saya juga ingin melihat fitur ini di Angular, saya juga akan mengubah banyak hal yang saya tidak suka secara pribadi.

Tapi mungkin Angular tidak dimaksudkan untuk menjadi kerangka kerja yang memiliki semua mainan baru yang mengkilap dan mendapatkan banyak fitur setiap rilis. Dan itu baik-baik saja dengan saya. Harus ada kerangka kerja yang bertujuan untuk tingkat perusahaan yang lebih tinggi dan memberikan stabilitas dan keandalan. Dan Angular melakukannya dengan baik, setidaknya dari pengalaman saya.

Saya lebih suka Vue. Saya menggunakannya untuk proyek pribadi saya. Tetapi proyek saya dapat dengan cepat mulai terasa usang dan saya merasakan dorongan untuk meningkatkan ke gaya komponen baru. Juga, ketika saya melakukan peningkatan, semuanya selalu rusak dengan cara yang paling aneh. Ekosistem juga tampaknya lebih sulit mempertahankan kompatibilitas.

Sudut sebaliknya matang dan stabil. Itu tidak sering berubah, tetapi itu juga berarti Anda memiliki lebih sedikit pekerjaan dalam memfaktorkan ulang kode Anda karena Anda terus memperbarui dependensi Anda, dan itu berharga untuk produk komersial. Pengetahuan Anda juga tetap relevan lebih lama, dan alih-alih mencoba mengikutinya, Anda bisa masuk lebih dalam.

@manfreed orang tidak meminta mainan baru yang mengkilap, mereka meminta koreksi atas kekeliruan dalam desain kerangka kerja. Saat ini kami terkadang terpaksa menggunakan yang dapat diamati, dan terkadang tidak dapat menggunakan yang dapat diamati, untuk fungsionalitas utama. Mereka yang membenci yang dapat diamati merasa frustrasi. Mereka yang menyukai hal-hal yang dapat diamati merasa frustrasi. Dan banyak dari kita yang sangat kecewa dengan situasi yang membuat kita menyerah dan beralih ke kerangka kerja lain. Saya akan senang untuk terus menggunakan Angular, sedikit arahan dan itu bisa menjadi kerangka kerja yang benar-benar hebat. Tapi posting blog tentang salah urus, kurangnya pragmatisme, kelalaian, semuanya mengecewakan secara objektif.

@insidewhy Bersabarlah, selalu ada beberapa puncak dan lembah di jalan, tetapi itu tidak berarti bahwa orang lain juga tidak memilikinya atau ada beberapa kesalahan prinsip. Ini hanya berarti bahwa segala sesuatunya dapat bergerak maju lebih cepat dan efektif daripada yang sebenarnya terjadi.

Tidak disebutkan masalah tertentu yang disebutkan di peta jalan, yang menurut saya menyedihkan, saya benar-benar berharap akan ada sesuatu, menyebutkan, pengakuan ... diskusi ini diikuti pada perselisihan sudut —

Saya memberi mereka manfaat dari keraguan dan bertanya di komentar artikel peta jalan menengah itu , tanggapan Minko:

Dia cukup banyak mengulangi apa yang dia katakan di sini beberapa bulan yang lalu, tidak ada masalah terkait rxjs ini yang diperbaiki dalam waktu dekat, jadi ya.

Saya sudah selesai mencoba untuk menyampaikan maksud saya, tetapi izinkan saya mencoba untuk terakhir kalinya .. Saya tidak meminta Angular untuk diubah menjadi Cycle.js , menggantikan API saat ini, yang saya minta hanyalah tiga ceri reaktif kecil di atas API saat ini.

• siklus hidup yang dapat diamati
• masukan yang dapat diamati
• acara template yang dapat diamati

Tak satu pun dari ini mematahkan kompatibilitas ke belakang, meningkatkan kurva pembelajaran, tidak konsisten dengan API lain dan saya dapat membayangkan hampir tidak memengaruhi kinerja , jadi bagaimana mereka begitu rumit dan memerlukan perencanaan yang lebih lama & hati-hati, dibandingkan dengan tugas-tugas lain yang ada di depan. Cukup tambahkan satu per satu, tunjukkan bahwa Anda peduli. Silahkan.

@fxck :+1: pasti.

• siklus hidup yang dapat diamati
• masukan yang dapat diamati
• acara template yang dapat diamati

@insidewh Sabar

Meminta orang untuk lebih dari 5 tahun kesabaran tidak begitu pragmatis ketika ada banyak pesaing yang berlari melewati perlombaan semua berlomba-lomba untuk mendapatkan perhatian.

@ insidewh Itu dimaksudkan secara lebih umum.

@fxck Google memiliki (menurut hitungan terakhir saya) 4000 aplikasi dibangun di sudut dan sangat mirip sifatnya, beralih di antara proyek-proyek ini dan peer review (saya bayangkan) cukup mulus. Bahkan di perusahaan saya, salah satu manfaat besar Angular adalah bahwa tanpa saya meninjau kode tim lain, saya tahu itu dalam keadaan di mana peer review tidak menjalankan seluruh penyelidikan.

Sekarang katakanlah kita menerapkan masing-masing pintasan RxJS yang bermanfaat ini ke dalam inti, lalu apa yang terjadi? Mungkin saja kita akan berakhir dengan bias prosedural versus bias reaktif, tanpa panduan yang jelas tentang bias mana yang benar untuk kasus tertentu. Setelah membaca diskusi sejauh ini, jawaban dari tim sudut bukanlah "Ini adalah prioritas rendah" (seperti yang disarankan aliran Anda), itu sebenarnya tampak lebih dekat dengan "Kami tidak ingin berpihak".

Pengguna RxJS tingkat lanjut di komunitas Angular di sini adalah minoritas vokal, karena setelah Anda membuka TypeScript, DI, templating, dan berbagai perpustakaan Angular, Anda memiliki hampir 1 tahun di bawah ikat pinggang Anda menggunakan kerangka kerja setiap hari, dan Anda sekarang siap untuk benar-benar memahami RxJS. Membiarkan orang tingkat senior pergi dengan bias reaktivitas dalam tinjauan sejawat semakin mengasingkan orang, dan itu benar-benar hal terakhir yang dibutuhkan Angular.

Tujuan Angular (seperti yang saya lihat) adalah untuk mengurangi dan mengurangi percakapan dari "Gunakan teknologi X karena lebih baik, inilah novel singkat mengapa" dan menjaga percakapan dalam tinjauan sejawat tentang logika bisnis yang diterapkan. Apakah kita benar-benar ingin mengelompokkan komponen kita antara sudut "Lanjutan" dan sudut "Pemula" lebih dari yang sudah kita miliki?

Ini bisa dibilang argumen yang sama yang telah kita lihat dengan manajemen negara, mengapa Angular harus menentukan dari banyak kemungkinan pola mana yang benar?

Izinkan saya mengutip salah satu anggota tim sudut untuk Anda.

Omong-omong, sama sekali tidak ada yang maju tentang semua ini (siklus hidup yang dapat diamati, input yang dapat diamati, acara templat yang dapat diamati).

Ini bisa dibilang argumen yang sama yang telah kita lihat dengan manajemen negara, mengapa Angular harus menentukan dari banyak kemungkinan pola mana yang benar?

Perbedaan antara pengelolaan negara dan ini, adalah bahwa pengelolaan negara dapat dilakukan oleh masyarakat, tidak ada di dalam inti sudut yang mencegahnya. Sayangnya Angular tidak menyediakan cara untuk mengimplementasikan dengan benar ketiganya yang saya sebutkan. (edit: tautan dikoreksi ke komentar)

Saya sepenuh hati meninggalkan komunitas sebanyak mungkin, yang mencakup paket seperti formulir, router, tata letak fleksibel, universal, dll., biarkan tim Angular fokus pada inti, cli, dan komponen. Tetapi untuk itu mereka perlu menyediakan titik masuk yang cukup bagi komunitas, seperti misalnya mengizinkan komponen tingkat tinggi . Tetapi mereka gagal melakukan itu selama bertahun-tahun (seringkali mengatakan Ivy diperlukan terlebih dahulu) dan menolak untuk mengakui / membicarakan hal ini dalam rencana mereka sekarang.

Setelah membaca diskusi sejauh ini, jawaban dari tim sudut bukanlah "Ini adalah prioritas rendah" (seperti yang disarankan aliran Anda), itu sebenarnya tampak lebih dekat dengan "Kami tidak ingin berpihak".

Ya dan itu menakutkan.

@fxck Saya sangat berpikir kita berada di halaman yang sama tentang ini. Saya akan mengatakan bahwa setiap kali saya membawa RxJS di forum atau bahkan dengan rekan-rekan insinyur saya, sebagian besar kutipan yang dapat saya kutip adalah "Saya masih tidak mengerti ini, bagaimana saya belajar lebih banyak?" atau "Saya merasa kewalahan dengan banyaknya operator yang ada." atau "Saya kesulitan membaca saluran ini di PR ini". Untuk setiap 1 insinyur RxJS yang berpengalaman, tampaknya ada 15 insinyur Angular yang berpengalaman dengan alis berkerut.

Ya dan itu menakutkan.

Ini sedikit hiperbolik, kita tidak "membutuhkan" @angular/core untuk memiliki pola-pola ini, sebenarnya ada BANYAK varian dan pustaka dalam masalah ini yang dapat digunakan saat ini di proyek apa pun. Satu-satunya keengganan dalam menggunakan opsi yang disebutkan sebelumnya adalah bahwa Anda mungkin, di masa depan, harus bermigrasi ke sesuatu yang disediakan Angular sebagai pengganti @angular/core . Apakah sangat sulit bagi kita untuk npm uninstall dan memperbaiki semua kesalahan TypeScript?

Keputusan arsitektur besar, yang memengaruhi semua proyek sudut, dan membutuhkan waktu berjam-jam untuk mendokumentasikan dan bermigrasi jika tidak berhasil, bagi saya itu tampak lebih menakutkan, dan kami pernah ke sana sebelumnya:

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

Ini sedikit hiperbolik, kami tidak "membutuhkan" @angular/core untuk memiliki pola-pola ini, sebenarnya ada banyak BANYAK varian dan pustaka dalam masalah ini yang dapat digunakan hari ini di proyek apa pun.

Tidak, tidak juga, setiap solusi memerlukan peretasan atau mengandalkan API internal yang dapat berubah. Itulah inti .. membaca apa @insidewhy kata https://github.com/angular/angular/issues/5689#issuecomment -630.661.006 dan apa yang saya katakan di bawah ini bahwa sekitar Template acara sungai.

// edit tautan yang dikoreksi ke komentar

Tidak, tidak juga, setiap solusi memerlukan peretasan atau mengandalkan API internal yang dapat berubah.

API atau tipe internal apa yang menurut Anda harus dipublikasikan/generik agar hal ini dapat ditangani oleh komunitas? Jika desain ini dalam pola holding karena tidak ada jalan yang jelas ke depan, maka tampaknya tepat untuk meminta agar kita diizinkan untuk mendesain sendiri daripada terus-menerus membenturkan drum yang sama ini.

Baca komentar lain oleh @insidewhy dia mencoba menyelesaikannya di dalam inti.

@fxck Saya tidak akan membahas sejarah upaya untuk mengimplementasikan ini dalam inti atau bagaimana masalah ini telah terbuka selama 5 tahun, apa yang menghentikan kami sekarang dari membuka internal untuk memungkinkan komunitas mengembangkan desain sendiri?

Yo @insidewhy , saya ingin tahu apakah ini jenis pengecekan hack yang diandalkan lib Anda. Ternyata tidak berfungsi lagi menggunakan TS 4.0

Properti 'serviceStackId$' digunakan sebelum initialization.ts(2729)

Yo @insidewhy , saya ingin tahu apakah ini jenis pengecekan hack yang diandalkan lib Anda. Ternyata tidak berfungsi lagi menggunakan TS 4.0

Tidak, itu ada di kompiler template. Ini adalah sesuatu yang lain. Berengsek. Yah. Saya dapat menambahkan Anda ke daftar pengelola jika Anda ingin mencoba memperbaikinya.

@fxck Sebenarnya Anda harus menetapkan operator pipa itu di ngOnInit karena properti berbasis dekorator tidak akan disuntikkan sampai setelah konstruktor dijalankan, jadi ini sebenarnya masalah yang sah dengan kode Anda.

@insidewhy saya pasti berhasil sebelum TS4. Dan periksa ini ,

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

itu masuk

mencatat nilai modifikasi this.baz ObservableInput

jadi saya pikir itu harus tetap berfungsi, hanya di TS4 kompiler mengeluh karena tidak menyadari ada get dengan nilai di dalam dekorator itu..

Saya menggunakan dekorator untuk merasakan perubahan prop Input dan membuat versi prop Input yang dapat diamati. Lihat demo kode dan kotak ini.

Begini Cara kerjanya:

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

Seperti yang ditunjukkan @wmaurer , @Subjectize dapat diperlakukan sebagai "gula" untuk menyelesaikan sesuatu.

Layak untuk membaca panduan resmi angular Intercept perubahan properti input dengan setter , yang menjelaskan bahwa kita dapat merasakan perubahan Input menggunakan getter/setter .

@hankchiutw Solusi itu terlihat mirip dengan dekorator @BindObservable : https://github.com/PSanetra/bind-observable#usage

Terima kasih @hankchiutw

Karena Anda menginisialisasi ReplaySubject dengan 1, saya memilih untuk menggunakan BehaviorSubject sebagai gantinya.
Saya juga telah menginisialisasi nilai secara langsung di 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>;

    // ...
}

Saya berharap saya dapat menghindari penulisan jenis pada properti "Subjectized" karena harus dapat menebaknya dari properti terkait :( Adakah yang tahu bagaimana melakukannya?

Mimpinya adalah dapat melakukan itu dan secara otomatis membuat prop Subjek terkait (world$ dalam kasus saya) sebagai BehaviorSubjectdan diinisialisasi dengan benar.

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

    // ...
}

@mparpaillon Desain yang Anda usulkan cukup mirip dengan cara melakukannya di https://github.com/PSanetra/bind-observable
Satu-satunya perbedaan adalah bahwa dekorator @BindObservable() menggunakan ReplaySubject di bawah tenda. Jadi, jika Anda ingin Subjek itu berisi nilai awal, Anda juga perlu menginisialisasi properti terikat secara eksplisit (juga jika itu hanya tidak ditentukan karena ada kemungkinan bahwa tipe properti tidak mengizinkan nilai yang tidak ditentukan atau nol).

Contoh Stackblitz

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

Terima kasih @PSanetra tapi saya lebih suka solusi saya (yang sebenarnya adalah solusi Hank)

@mparpaillon Saya sudah mencoba sesuatu untuk impian Anda (ha) di demo lain .

Penggunaannya terlihat seperti

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

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

di mana Anda dapat memilih untuk menentukan nama prop subjek.

Meskipun secara teknis layak, saya khawatir itu mungkin ambigu bagi pengembang (karena anggota kelas baru dibuat di bawah naungan).

Terima kasih @hankchiutw ! TypeScript sepertinya tidak mengizinkan saya menggunakan count$ atau myCount$.

Anda juga mungkin benar tentang ambiguitas ... Terima kasih lagi

TypeScript sepertinya tidak mengizinkan saya menggunakan count$ atau myCount$.

Anda mendeklarasikan anggota kelas Anda sebagai "count" dan "anotherCount", itu sebabnya Anda tidak dapat mengakses "myCount$" dan "count$". Mereka sama sekali tidak ada, karena Anda tidak mendeklarasikannya di mana pun.

Aku tahu... itu intinya. Saya sedang mencari cara untuk mendeklarasikannya dari Dekorator. @hankchiutw menawarkan solusi dan saya hanya mengatakan itu tidak berfungsi apa adanya

@mparpaillon lihat solusi saya: https://github.com/Futhark/ngx-observable-input

@Futhark Oh itu panas! Terima kasih