Mengapa saya menggunakan kueri RTK untuk panggilan API di React – Beragampengetahuan

Bagian kueri RTK dari tutorial Redux Essentials sangat bagus, tetapi karena ini adalah bagian dari rangkaian dokumentasi yang lebih besar, saya merasa permata dari kueri RTK ini mulai hilang.

Apa itu Redux?

Banyak orang menganggap Redux sebagai perpustakaan manajemen negara, dan memang demikian. Bagi mereka, nilai utama Redux adalah ia dapat mengakses (dan mengubah) status aplikasi dari mana saja dalam aplikasi. Ini melenceng dari gunanya menggunakan sesuatu seperti Redux, jadi mari kita perkecil sedikit dan melihatnya lagi.

Kita semua pernah melihat gambar ini atau gambar serupa:

Anda dapat melihat bahwa dalam mockup ini, UI memiliki tempat untuk menampilkan jumlah toko saat ini, serta tombol yang dapat diklik pengguna untuk menunjukkan bahwa dia ingin menyetor atau menarik uang. Setelah salah satu tombol diklik, kami keluar dari komponen untuk mengirimkan tindakan berdasarkan apa yang diminta pengguna. Perhatikan bahwa statusnya belum berubah saat ini. Selanjutnya, operasi mencapai penyimpanan, yang dilihat oleh peredam untuk memutuskan tindakan apa, jika ada, yang harus dilakukan atas permintaan pengguna. Jika peredam memutuskan untuk memenuhi permintaan pengguna, perubahan status akan disebarkan ke UI.

Apa yang kita dapatkan dari ini? Pertama, katakanlah pengguna memiliki $5 di akunnya dan mengklik tombol “Tarik $10”. Peredam mungkin memutuskan untuk mengabaikan permintaan tersebut dan tidak membuat saldo negatif. Alternatifnya, peredam dapat merutekan kesalahan ke status yang dipantau oleh komponen toast. Jika kita mencoba memasukkan logika ini ke dalam komponen UI, hal ini akan membuat komponen menjadi lebih kompleks dan berarti harus dilakukan perubahan pada komponen yang tidak terkait dengan komponen tersebut.

Pada saat yang sama, jika kita membutuhkan logika tersebut di komponen lain, kita akan mendapat masalah. Ya, orang bilang hook menyelesaikan masalah ini, tapi karena hook normal terkait dengan logika tampilan, biasanya ada cukup banyak logika dalam tampilan yang berinteraksi dengan logika di hook. Jadi dalam praktiknya Anda biasanya tidak bisa menggunakan hook di tempat lain tanpa banyak logika duplikat di komponennya.

Semakin banyak status kesalahan dan situasi lain yang perlu kita tangani, semakin buruk kompleksitas komponennya. Tidak hanya itu, jika semua logika Anda ada di komponen Anda, itu berarti banyak negara Anda ada di komponen tersebut. Jadi, begitu pengguna menavigasi ke tempat lain, status tersebut akan hilang.

Dengan memberikan ruang hidup khusus bagi negara dan menambahkan pesan antar bagian sistem, kami menciptakan fleksibilitas dan elastisitas dalam sistem, konsisten dengan akar reaktif React.

Anatomi panggilan API di Redux

Semua ini mulai menjadi lebih rumit ketika Anda mulai membuat panggilan API, karena rasa asli Redux (seperti React) tidak memiliki tempat alami untuk logika asinkron. Untungnya, Redux menyediakan mekanisme untuk menambahkan middleware lain di atasnya untuk merespons operasi dengan lebih banyak cara daripada sekadar mengirimkannya ke semua reduksi dan menghasilkan status baru.

Dua middleware paling populer untuk menangani konten semacam ini adalah redux-sagas dan redux-thunk. Sebagai catatan, saya sangat menyukai saga, dan saya mulai menggunakan Redux Toolkit dengan serius ketika saya mencari apa yang dilakukan orang-orang yang menyukai saga sekarang dan menemukan middleware pendengar yang baru ditambahkan. Singkat cerita, saya menemukan bahwa sebagian besar hal yang saya lakukan dengan saga ditangani secara lebih ergonomis dengan kueri RTK. Namun hal ini sudah terlalu maju.

Pada tingkat yang sangat tinggi, middleware ini memungkinkan Anda menentukan urutan langkah sebagai respons terhadap satu tindakan yang dikirim, termasuk mengirimkan tindakan tambahan yang akan mengubah status saat langkah tersebut masih berlangsung. Ini mungkin terlihat seperti ini:

Diagramnya terlihat cukup sederhana, namun logika untuk melakukan hal ini bisa sangat panjang dan seringkali sulit untuk diuji. Biasanya kode ini diulangi untuk setiap panggilan API. Tidak hanya itu, setelah Anda menyelesaikan semua itu, Anda masih harus menulis sekumpulan pemilih untuk mendapatkan status pemuatan, status kesalahan, dan data untuk setiap panggilan API. Ini hanyalah sebuah aplikasi yang relatif sederhana.

Pola yang relatif umum adalah master/detail, di mana Anda mendapatkan cukup data tentang kumpulan “sesuatu” untuk menampilkan daftarnya, dan kemudian pengguna menelusuri untuk mendapatkan lebih banyak data.

Pengguna dapat mengklik masuk dan keluar dari entri detail yang sama, jadi cara yang jelas untuk meningkatkan kinerja adalah dengan menyimpan hasil setiap panggilan detail ke dalam cache, lalu memeriksa apakah Anda sudah memilikinya sebelum mengambilnya lagi. Namun hal ini menambah kerumitan karena kita harus memikirkan cara menyimpannya, cara memeriksanya, dan kemudian hanya menjalankan panggilan API jika kita belum memilikinya. Panggilan run akan bersifat asinkron, sedangkan mengembalikan hasil yang sudah kita miliki dapat dilakukan secara sinkron.

Segalanya menjadi lebih rumit ketika Anda mulai mengedit data. Tiba-tiba, saat Anda mengedit catatan, Anda perlu memperbarui daftar utama atau memicu daftar untuk memuat ulang sendiri.

Sebelum Anda menyadarinya, Anda mungkin menemukan kode yang membingungkan saat mencoba mencari tahu apa yang harus dilakukan, kapan dan bagaimana mendapatkan atau memperbarui data pada waktu yang tepat. Hal ini bisa menjadi lebih buruk jika ada banyak orang dalam tim, karena setiap orang mungkin mempunyai pendekatan yang sedikit berbeda untuk setiap masalah.

Masukkan kueri RTK

Redux Toolkit Query, atau RTK Query, seperti namanya, dibangun di atas Redux Toolkit, yang tidak akan saya bahas secara detail. Dalam kueri RTK, logika API Anda berada dalam potongan khusus yang hanya berlaku untuk titik akhir API Anda. Ada dua jenis titik akhir: kueri dan mutasi. Kueri hanya mengembalikan satu atau lebih catatan, sedangkan mutasi membuat, mengedit, atau memperbarui data dengan cara tertentu, mungkin mengembalikan status yang diperbarui.

Dalam irisan ini, kueri RTK membuat “hash” tidak hanya untuk setiap titik akhir, namun juga untuk setiap titik akhir dan parameter yang digunakan untuk memanggilnya. Hal ini membuatnya murah dan mudah untuk menyimpan hasil kueri yang baru saja Anda jalankan untuk sementara waktu untuk berjaga-jaga jika pengguna mengklik kembali ke detail tersebut.

Status yang terdapat di setiap bagian hash berisi bagian-bagian yang sebelumnya harus kita tulis banyak logika untuk dikelola: