Bagaimana saya menstruktur komponen Sudut saya dengan Isyarat

Dalam artikel pendek ini saya ingin menunjukkan kepada anda cara saya suka menstruktur komponen saya dengan isyarat, tanpa pustaka luaran. Sudah tentu perkara seperti NgRx akan memainkan peranan yang besar untuk menjadikan kod kami lebih mantap, tetapi mari kita mulakan dengan mudah!

Pertama sekali saya mentakrifkan semua keadaan saya dengan isyarat:

export class TodoListComponent {
  todos = signal<todo>([]);
}
</todo>

Perkara yang sama berlaku untuk input juga! Jika komponen saya memerlukan input, saya mengisytiharkannya dengan fungsi input() baharu oleh Angular, yang memberi saya isyarat juga. Dan jika ia berlaku sebagai parameter laluan, saya menggunakan input.required().

Kemudian, jika saya ingin menunjukkan beberapa keadaan yang boleh diperoleh daripada yang lain, saya sentiasa menggunakan pengiraan:

completedTodos = computed(() => this.todos().filter(t => t.completed));

Kemudian, jika anda mengenali saya, anda tahu betapa saya tidak suka melakukan kesan sampingan tak segerak secara langsung di dalam kaedah kelas... ?

export class TodoListComponent {
  todoService = inject(TodoService);

  toggleTodo(id: string) {
    this.todoService.toggle(id).subscribe(newTodo => ...);
  }
}

Kenapa awak tanya? Kerana jika kaedah itu adalah yang secara langsung memulakan kesan sampingan (dalam kes ini, memanggil langganan), anda tidak mempunyai kawalan ke atas tekanan belakang.

Tekanan belakang boleh disimpulkan dengan ini: apakah yang berlaku jika pengguna menogol todo semasa panggilan sebelumnya belum selesai?

Terdapat beberapa masalah, contohnya:

1. Adakah kita mahu melakukan panggilan kedua? Atau tunggu yang pertama selesai? Atau patutkah kita membatalkan yang pertama?
2. Bagaimana jika kita menogol item yang berbeza dalam masa yang singkat?
3. Bagaimana jika kami ingin memperkenalkan sejenis debounce atau throttle?

Jika anda tahu RxJS (dan jika anda membaca ini, anda sepatutnya sekarang!) anda tahu bahawa masalah pertama mudah diselesaikan dengan 4 Operator Meratakan (mergeMap, concatMap, switchMap, exhaustMap).

Kemudian, jika anda mengenali RxJS dengan baik, anda tahu bahawa anda boleh menyelesaikan masalah kedua dengan pengendali hebat yang dipanggil groupBy!

Tetapi untuk menggunakan semua kebaikan ini, anda mesti mempunyai sumber yang Boleh Diperhatikan, jadi... bukan kaedah.

Mata pelajaran

Fikirkan Subjek seperti terbuka (tidak lengkap), kosong Boleh Diperhatikan. Ia adalah alat yang sesuai untuk mewakili acara tersuai.

Semua acara dalam komponen kami boleh diwakili oleh Subjek:

export class TodoListComponent {
  ...

  toggleTodo$ = new Subject<string>();
  deleteTodo$ = new Subject<string>();
  addTodo$ = new Subject<void>();
}
</void></string></string>

Kemudian, templat kami hanya boleh memanggilnya apabila perlu, bukannya memanggil kaedah, contohnya:

<button>delete</button>

Sekarang sumber kami Boleh Diperhatikan, kami boleh menggunakan pengendali kami yang dihormati: mari buat beberapa kesan.

Kesan

Saya suka menentukan kesan saya di dalam pembina supaya saya boleh menggunakan pengendali takeUntilDestroyed() untuk membersihkan kesan apabila komponen dimusnahkan! Jadi, sebagai contoh:

constructor() {
  this.addTodo$.pipe(
    concatMap(() => this.todoService.add())
    takeUntilDestroyed()
  ).subscribe(newTodo => this.todos.update(todos => [...todos, newTodo]));
}

Di sini saya menggunakan concatMap untuk mengekalkan susunan respons, supaya todos ditambah mengikut tertib. Ini bermakna tiada panggilan serentak. Saya rasa ia sesuai untuk operasi tambah, tetapi ini mungkin pilihan yang salah untuk panggilan lain: contohnya, untuk permintaan GET, biasanya lebih baik menggunakan exhaustMap atau switchMap, bergantung pada kes penggunaan.

Saya juga menggunakan pendekatan yang dipanggil Kemas Kini Pesimis, yang bermaksud saya menunggu panggilan ditamatkan untuk mengemas kini keadaan dalaman saya. Ini adalah pilihan peribadi! Anda boleh menambah todo dengan serta-merta, dan kemudian kembalikannya semula dengan menggunakan catchError jika ralat panggilan API keluar.

Kemudian terdapat fungsi kesan sebenar dari Angular yang dimaksudkan untuk digunakan bersama dengan isyarat: Saya menggunakan fungsi ini untuk tugas penyegerakan. Contohnya, apabila parameter berubah dalam URL (merujuk kepada ID entiti baharu), saya mungkin mahu mengemas kini borang dengan entiti baharu:

// This comes from the router
id = input.required<string>();

// Always stores the current invoice information
currentInvoice = toSignal(toObservable(this.id).pipe(
  switchMap(id => this.invoiceService.get(id))
));

constructor() {
  effect(() => {
    // Assuming the 2 structures match, every time we browse
    // to a new invoice, the form gets populated
    this.form.patchValue(this.currentInvoice());
  })
}
</string>

Perhatikan bahawa kami tidak mempunyai kawalan ke atas tekanan belakang dengan teknik ini. Untuk perkara seperti ini tidak mengapa, tetapi ingat: itulah sebabnya kami masih memerlukan RxJS untuk mencipta apl bebas pepijat. Atau perpustakaan lain yang menguraikan kerumitan ini di bawah hud.

Menjadi penuh Reaktif bukanlah idea yang baik

Banyak negeri yang kami wakili dengan isyarat boleh dianggap secara teknikal keadaan tak segerak yang diperoleh. Sebagai contoh, senarai Todo kami boleh dianggap sebagai keadaan terbitan daripada pelayan:

// Trigger this when you need to refetch the todos
fetchTodos$ = new Subject<void>();

todos = toSignal(toObservable(this.fetchTodos$).pipe(
  switchMap(id => this.todoService.getAll())
));
</void>

Pendekatan ini serupa dengan pendekatan yang digunakan oleh perpustakaan seperti TanStack Query, di mana anda membatalkan pertanyaan secara manual apabila anda memerlukan data baharu. Dalam erti kata lain, anda sentiasa pergi ke pelayan untuk setiap mutasi.

Ini mungkin bagus dalam sesetengah senario, tetapi terdapat 2 perkara yang perlu dipertimbangkan:

1. Ia menyukarkan pengemaskinian keadaan secara manual (kemas kini optimistik). Ini dipermudahkan oleh perpustakaan seperti TanStack Query, tetapi melakukannya secara manual memang susah.
2. Ia menjadikan kod itu agak sukar untuk difahami oleh kebanyakan pembangun, inilah yang saya lihat sebagai perunding yang mengusahakan perkara seperti ini setiap hari.

Pendek kata, saya biasanya tidak mengesyorkannya. Dan saya berkata biasanya! :)

결론

이 짧은 기사가 마음에 드셨기를 바랍니다! 요약하자면:

• 상태를 신호로 정의
• 파생된 상태를 계산된 신호로 정의
• 비동기 효과를 Observable로 정의하세요
• 효과로 동기화 효과 정의

이러한 원칙을 따르면 앱을 유지 관리하기가 훨씬 쉬워질 것이라고 확신합니다!

Atas ialah kandungan terperinci Bagaimana saya menstruktur komponen Sudut saya dengan Isyarat. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!