Apa itu Redux: Panduan Desainer
Diterbitkan: 2022-03-10Pernahkah Anda mendengar tentang Redux? Apa itu? Jangan googling, tolong!
- “Barang-barang backend yang mewah.”
- “Aku pernah mendengarnya, tapi aku tidak tahu apa itu. Ini mungkin kerangka kerja React?”
- “Cara yang lebih baik untuk menyimpan dan mengelola status dalam aplikasi React.”
Saya telah mengajukan pertanyaan ini kepada lebih dari 40 desainer. Di atas adalah jawaban khas mereka. Banyak dari mereka yang sadar bahwa Redux bekerja dengan React dan tugasnya adalah “manajemen negara.”
Tapi tahukah Anda apa sebenarnya arti “pengelolaan negara” ini? Tahukah Anda bahwa kekuatan Redux yang sebenarnya berada di luar pengelolaan negara? Tahukah Anda bahwa Redux tidak selalu membutuhkan React untuk bekerja ? Apakah Anda ingin bergabung dengan diskusi tim Anda (atau setidaknya obrolan makan siang) tentang apakah akan menggunakan Redux? Apakah Anda ingin mendesain dengan pemahaman tentang cara kerja Redux?
Dengan bantuan artikel ini, saya ingin menunjukkan kepada Anda gambaran lengkap tentang Redux : apa yang dapat dilakukannya, mengapa ia melakukan hal-hal tersebut, apa kerugiannya, kapan menggunakannya, dan bagaimana kaitannya dengan desain.
Tujuan saya adalah membantu desainer seperti Anda. Bahkan jika Anda belum pernah menulis satu baris kode pun sebelumnya, saya pikir masih mungkin dan bermanfaat (dan menyenangkan) untuk memahami Redux. Harapkan bahasa Inggris dan coretan sederhana — tanpa kode atau pembicaraan abstrak.
Siap untuk perjalanan?
Apa itu Redux?
Pada tingkat yang sangat tinggi, Redux adalah alat yang digunakan pengembang untuk membuat hidup mereka lebih mudah. Seperti yang mungkin pernah Anda dengar, tugasnya adalah "manajemen negara". Saya akan menjelaskan apa arti manajemen negara beberapa bagian nanti. Pada titik ini, saya akan meninggalkan Anda dengan gambar ini:
Mengapa Anda Harus Peduli?
Redux lebih tentang cara kerja bagian dalam aplikasi daripada tampilan dan nuansanya. Ini adalah alat yang agak rumit dengan kurva belajar yang curam. Apakah itu berarti kita sebagai desainer harus menjauhinya?
Tidak. Saya pikir kita harus menerimanya. Seorang desainer mobil harus mengerti untuk apa mesin itu, bukan? Agar berhasil mendesain antarmuka aplikasi, desainer juga harus memiliki pengetahuan yang kuat tentang berbagai hal di bawah tenda . Kita harus belajar tentang apa yang dapat dilakukannya, memahami mengapa pengembang menggunakannya, dan menyadari keuntungan dan implikasinya.
“Desain bukan hanya seperti apa yang terlihat dan terasa. Desain adalah cara kerjanya.”
— Steve Jobs
Apa yang Dapat Dilakukan Redux?
Banyak orang menggunakan Redux untuk mengelola status di aplikasi React. Ini adalah kasus penggunaan paling umum di alam liar dan Redux meningkatkan aspek di mana React tidak berjalan dengan baik (belum).
Namun, Anda akan segera melihat bahwa kekuatan Redux yang sebenarnya jauh melampaui itu. Mari kita mulai dengan mempelajari apa arti sebenarnya dari manajemen negara.
Manajemen Negara
Jika Anda tidak yakin apa artinya "status" ini, mari kita ganti dengan istilah yang lebih umum: "data." State adalah data yang berubah dari waktu ke waktu . Status menentukan apa yang ditampilkan pada antarmuka pengguna.
Apa yang dimaksud dengan manajemen negara? Secara umum, ada tiga aspek data yang perlu kita kelola dalam sebuah aplikasi:
- Mengambil dan menyimpan data
- Menetapkan data ke elemen UI
- Mengubah data
Katakanlah kita sedang membangun halaman bidikan Dribbble. Data apa yang ingin kita tampilkan di halaman? Mereka termasuk foto profil penulis, nama, GIF animasi, jumlah hati, komentar, dan sebagainya.
Pertama, kita perlu mengambil semua data ini dari server di cloud dan meletakkannya di suatu tempat. Selanjutnya, kita perlu benar-benar menampilkan data. Kita perlu menetapkan potongan data ini ke elemen UI yang sesuai yang mewakili apa yang sebenarnya kita lihat di browser. Misalnya, kami menetapkan URL foto profil ke atribut src dari tag img HTML:
<img src='https://url/to/profile_photo'>Terakhir, kita perlu menangani perubahan pada data. Misalnya, jika pengguna menambahkan komentar baru ke bidikan Dribbble, atau menambahkan bintang, kita perlu memperbarui HTML yang sesuai.
Mengkoordinasikan ketiga aspek negara ini adalah bagian besar dalam pengembangan front-end, dan React memiliki berbagai tingkat dukungan untuk tugas ini. Terkadang fasilitas built-in di React bekerja dengan cukup baik. Tetapi ketika aplikasi tumbuh lebih kompleks, statusnya mungkin menjadi lebih sulit untuk dikelola dengan React saja. Itu sebabnya banyak orang mulai menggunakan Redux sebagai alternatif.
Mengambil Dan Menyimpan Data
Di React, kami memecah UI menjadi beberapa komponen. Masing-masing komponen ini dapat dipecah menjadi komponen yang lebih kecil (lihat “Apa itu React?”).
Jika UI kita terstruktur dengan cara ini, kapan kita mengambil data dan di mana menyimpannya sebelum mengisi UI?
Bayangkan ada seorang koki yang tinggal di setiap komponen . Mengambil data dari server seperti mencari semua bahan yang dibutuhkan untuk menyiapkan hidangan.
Cara yang naif adalah mengambil dan menyimpan data di mana dan kapan dibutuhkan. Ini seperti setiap koki pergi keluar untuk membeli sayuran dan daging langsung dari peternakan yang jauh.
Pendekatan ini sia-sia. Kita perlu memanggil server berkali-kali dari banyak komponen — bahkan untuk data yang sama. Koki akan membuang banyak gas dan waktu bepergian bolak-balik.
Dengan Redux, kami mengambil data satu kali dan menyimpannya di tempat terpusat, yang biasa disebut "simpan". Data tersebut kemudian siap digunakan kapan saja oleh komponen apa pun. Ini tidak seperti memiliki superstore terdekat di mana koki kami dapat membeli semua bahan. Superstore mengirimkan truk untuk membawa kembali sayuran dan daging dalam jumlah besar dari peternakan. Ini jauh lebih efisien daripada meminta koki individu untuk pergi ke peternakan sendiri!
Toko juga berfungsi sebagai satu-satunya sumber kebenaran. Komponen selalu mengambil data dari toko, bukan dari tempat lain. Ini membuat semua konten UI konsisten.
Menetapkan Data Ke Elemen UI
Dengan hanya React, sebenarnya ada cara yang lebih baik untuk mengambil dan menyimpan data. Kami dapat meminta koki Shotwell kami yang sangat baik untuk berbelanja untuk semua teman kokinya. Dia akan mengendarai truk ke peternakan dan membawa kembali barang-barangnya. Kita dapat mengambil data dari komponen container, misalnya, komponen "Shot" dalam contoh Dribbble, dan menggunakannya sebagai satu-satunya sumber kebenaran.
Pendekatan ini lebih efisien daripada cara naif dalam mengambil data dari setiap komponen. Tapi bagaimana Shotwell memberikan bahan-bahannya ke koki lain? Bagaimana cara meneruskan data ke komponen yang benar-benar merender elemen HTML? Kami meneruskan data dari komponen luar ke komponen dalam seperti tongkat estafet dalam relai, sepanjang jalan hingga data mencapai tujuan.
Misalnya, URL avatar penulis harus diteruskan dari “Shot”, ke “ShotDetail”, ke “Title” dan terakhir ke <img> . Jika koki kami tinggal di apartemen, itu benar-benar terlihat seperti ini:
Untuk mengirimkan data ke tujuan, kita harus melibatkan semua komponen di jalur, bahkan jika mereka tidak membutuhkan data sama sekali. Akan sangat menyebalkan jika ada banyak lantai!
Bagaimana jika superstore melakukan pengiriman dari pintu ke pintu? Dengan Redux 1 , kita dapat memasukkan data apa pun ke komponen apa pun, tanpa memengaruhi komponen lain sama sekali, seperti:
1 Agar benar-benar akurat, ada perpustakaan lain yang disebut react-redux yang menyerahkan data ke komponen React, bukan Redux itu sendiri. Tetapi karena react-redux hanya melakukan pemipaan dan orang-orang hampir selalu menggunakan Redux dan react-redux bersama-sama, saya pikir tidak apa-apa untuk memasukkan ini sebagai salah satu manfaat Redux.
Catatan : Dalam versi terbaru dari React (16.3), ada API "konteks" baru yang melakukan pekerjaan yang hampir sama dalam hal memasukkan data ke dalam komponen. Jadi jika ini adalah satu-satunya alasan tim Anda menggunakan Redux, pertimbangkan untuk meningkatkan ke React 16.3 dengan serius! Lihat dokumen resmi untuk informasi lebih lanjut (peringatan: banyak kode di depan).
Mengubah Data
Terkadang logika memperbarui data dalam aplikasi bisa cukup rumit. Ini mungkin melibatkan beberapa langkah yang bergantung satu sama lain. Kami mungkin perlu menunggu tanggapan dari beberapa server sebelum memperbarui status aplikasi. Kami mungkin perlu memperbarui banyak tempat di negara bagian pada waktu yang berbeda dalam kondisi yang berbeda.
Ini bisa menjadi luar biasa jika kita tidak memiliki struktur yang baik untuk semua logika ini. Kode akan sulit untuk dipahami dan dipelihara.
Redux memungkinkan kita untuk membagi dan menaklukkan . Ini menyediakan cara standar untuk memecah logika pembaruan data menjadi "pereduksi" kecil. Pereduksi tersebut bekerja sama secara harmonis untuk menyelesaikan tindakan yang kompleks.
Perhatikan perkembangan terbaru dari React. Seperti halnya API "konteks", mungkin ada API "setState" baru di versi React yang akan datang. Akan lebih mudah untuk memecah logika pembaruan yang kompleks menjadi bagian-bagian yang lebih kecil. Setelah API baru ini tersedia, Anda mungkin tidak memerlukan Redux lagi untuk mengelola aspek pengelolaan status ini.
Kekuatan Nyata Redux
Sejauh ini, tampaknya Redux hanyalah sebuah band-aid untuk React. Orang-orang menggunakan Redux untuk meningkatkan aspek yang React tidak lakukan dengan baik (belum). Tapi React mengejar dengan cepat! Faktanya, Dan Abramov, pencipta Redux, bergabung dengan tim inti React di Facebook beberapa tahun yang lalu. Mereka sibuk mengerjakan peningkatan yang disebutkan di atas untuk Bereaksi: API konteks (dirilis pada 16.3), API pengambilan data yang lebih baik (didemo pada Februari 2018), API setState yang lebih baik, dan seterusnya.
Apakah itu akan membuat Redux usang?
Tebak apa? Saya belum menunjukkan kepada Anda kekuatan Redux yang sebenarnya!
Redux memaksa pengembang untuk mengikuti beberapa aturan ketat, yang memberi Redux banyak kekuatan (yup, kekuatan disiplin!):
- Semua data (status aplikasi) harus dijelaskan dalam teks yang jelas. Anda harus dapat menuliskan semua data dengan pena di atas kertas.
- Setiap tindakan (perubahan data) harus dijelaskan dalam teks yang jelas. Anda harus menuliskan apa yang akan Anda lakukan sebelum mengubah apa pun. Anda tidak dapat mengubah data tanpa meninggalkan bekas. Proses ini disebut "mengirimkan tindakan" dalam bahasa gaul Redux.
- Kode Anda yang mengubah data harus berperilaku seperti rumus matematika. Itu harus mengembalikan hasil yang sama dengan input yang sama. Kuadrat 4 selalu 16 tidak peduli berapa kali Anda menjalankannya.
Saat Anda mengikuti aturan ini untuk membuat aplikasi, keajaiban terjadi. Ini memungkinkan banyak fitur keren yang sulit atau mahal untuk diterapkan. Berikut beberapa contohnya. 2
2 Saya mengumpulkan contoh-contoh ini dari posting Dan Abramov “Anda Mungkin Tidak Membutuhkan Redux” dan “Utas Pertanyaan Pemula Bereaksi.”
Urungkan, Ulangi
Fitur undo/redo yang populer memerlukan perencanaan tingkat sistem. Karena undo/redo perlu merekam dan memutar ulang setiap perubahan data dalam aplikasi, Anda harus memperhitungkannya dalam arsitektur sejak awal. Jika dilakukan sebagai renungan, itu akan membutuhkan banyak perubahan file yang merupakan resep untuk banyak bug.
Karena Redux mengharuskan setiap tindakan dijelaskan dalam teks yang jelas, dukungan untuk undo/redo hampir gratis. Petunjuk tentang cara mengimplementasikan undo/redo dengan Redux cocok di halaman sederhana.
Lingkungan Kolaborasi
Jika Anda sedang membuat aplikasi yang mirip dengan Google Documents tempat banyak pengguna bekerja sama dalam tugas yang kompleks, pertimbangkan untuk menggunakan Redux. Ini mungkin akan melakukan banyak angkat besi untuk Anda.
Redux membuatnya sangat mudah untuk mengirim apa yang terjadi melalui jaringan. Sangat mudah untuk menerima tindakan yang dilakukan pengguna lain di komputer lain, memutar ulang perubahan dan menggabungkan dengan apa yang terjadi secara lokal.
UI Optimis
UI yang optimis adalah cara untuk meningkatkan pengalaman pengguna aplikasi. Itu membuat aplikasi tampak merespons lebih cepat melalui jaringan yang lambat. Ini adalah strategi populer di aplikasi yang memerlukan respons waktu nyata, misalnya, game penembak orang pertama.
Sebagai contoh sederhana, di aplikasi Twitter, ketika Anda mengklik hati pada sebuah tweet, itu perlu meminta server untuk melakukan beberapa pemeriksaan, misalnya, apakah tweet itu masih ada. Alih-alih menunggu beberapa detik untuk hasilnya, aplikasi memilih untuk menipu! Ini mengasumsikan semuanya baik-baik saja dan segera menunjukkan hati yang terisi.
Pendekatan ini berhasil karena sebagian besar waktu semuanya baik-baik saja. Ketika semuanya tidak beres, aplikasi akan mengembalikan pembaruan UI sebelumnya dan menerapkan hasil aktual dari server, misalnya, menampilkan pesan kesalahan.
Redux mendukung UI optimis dengan cara yang sama seperti yang dilakukannya untuk membatalkan dan mengulang. Itu memudahkan untuk merekam, memutar ulang, dan mengembalikan perubahan data saat menerima hasil negatif dari server.
Bertahan Dan Booting Dari Status
Redux memudahkan untuk menyimpan apa yang terjadi di aplikasi di penyimpanan. Kemudian, bahkan jika komputer dihidupkan ulang, aplikasi dapat memuat semua data dan melanjutkan dari tempat yang sama persis, seolah-olah tidak pernah terputus.
Jika Anda membuat game dengan Redux, Anda hanya perlu beberapa baris kode lagi untuk menyimpan/memuat progres game, tanpa mengubah kode lainnya.
Sistem yang Benar-benar Dapat Diperluas
Dengan Redux, Anda harus "mengirimkan" tindakan untuk memperbarui data apa pun di aplikasi. Pembatasan ini memungkinkan untuk menghubungkan ke hampir setiap aspek dari apa yang terjadi di sebuah aplikasi.
Anda dapat membangun aplikasi yang benar-benar dapat diperluas di mana setiap fungsi dapat disesuaikan oleh pengguna. Misalnya, lihat Hyper, aplikasi terminal yang dibuat dengan Redux. Ekstensi "hyperpower" menambahkan taburan ke kursor dan mengguncang jendela. Bagaimana Anda menyukai mode "wow" ini? (Mungkin tidak terlalu berguna tetapi cukup untuk mengesankan pengguna)
Debugging Perjalanan Waktu
Bagaimana kalau bisa melakukan perjalanan tepat waktu saat men-debug aplikasi? Anda menjalankan aplikasi, memundurkan atau meneruskan beberapa kali untuk menemukan tempat yang tepat ketika bug terjadi, memperbaiki bug dan memutar ulang untuk mengonfirmasi.
Redux mewujudkan impian para pengembang ini. Redux DevTools memungkinkan Anda untuk memanipulasi kemajuan aplikasi yang sedang berjalan sebagai video YouTube — dengan menyeret penggeser!
Bagaimana cara kerjanya? Ingat tiga aturan ketat yang diberlakukan Redux? Itulah saus rahasia keajaiban.
Laporan Bug Otomatis
Bayangkan ini: Seorang pengguna menemukan sesuatu yang salah di aplikasi Anda dan ingin melaporkan bug tersebut. Dia dengan susah payah mengingat dan menjelaskan apa yang telah dia lakukan. Pengembang kemudian mencoba mengikuti langkah-langkah secara manual untuk melihat apakah bug terjadi lagi. Laporan bug mungkin tidak jelas atau tidak akurat. Pengembang kesulitan menemukan di mana bug itu berada.
Sekarang, bagaimana dengan ini. Pengguna mengklik tombol "Laporkan bug". Sistem secara otomatis mengirimkan apa yang telah dia lakukan kepada pengembang. Pengembang mengklik tombol "Putar ulang bug" dan melihat bagaimana bug itu terjadi. Bugnya tergencet di tempat, semua orang senang!
Inilah yang akan terjadi jika Anda menggunakan Redux Bug Reporter. Bagaimana cara kerjanya? Pembatasan Redux membuat keajaiban.
Kelemahan Redux
Tiga aturan utama yang ditegakkan Redux adalah pedang bermata dua. Mereka mengaktifkan fitur-fitur canggih, tetapi pada saat yang sama menyebabkan kerugian yang tak terhindarkan.
Kurva Pembelajaran Curam
Redux memiliki kurva belajar yang relatif curam. Butuh waktu untuk memahami, mengingat, dan membiasakan diri dengan polanya. Tidak disarankan untuk mempelajari Redux dan Bereaksi secara bersamaan jika keduanya baru bagi Anda.
Kode “Boilerplate”
Dalam banyak kasus, menggunakan Redux berarti menulis lebih banyak kode. Sering kali diperlukan untuk menyentuh banyak file agar fitur sederhana berfungsi. Orang-orang telah mengeluh tentang kode "boilerplate" yang harus mereka tulis dengan Redux.
Saya tahu, ini terdengar kontradiktif. Bukankah saya mengatakan Redux memungkinkan untuk mengimplementasikan fitur dengan kode minimal ? Ini sedikit seperti menggunakan mesin pencuci piring. Pertama, Anda harus menghabiskan waktu dengan hati-hati mengatur piring dalam barisan. Tidak sampai saat itu Anda akan melihat manfaat dari mesin pencuci piring: menghemat waktu untuk benar-benar membersihkan piring, membersihkan piring, dll. Anda harus memutuskan apakah waktu persiapan itu sepadan!
Penalti Performa
Redux juga dapat berdampak pada kinerja karena pembatasan yang diberlakukannya. Itu menambahkan sedikit overhead setiap kali data berubah. Dalam kebanyakan kasus, ini bukan masalah besar, dan perlambatan tidak terlihat. Namun, saat ada banyak data di penyimpanan dan saat data sering berubah (misalnya saat pengguna mengetik dengan cepat di perangkat seluler), akibatnya UI mungkin menjadi lamban.
Bonus: Redux Bukan Hanya Untuk Bereaksi
Kesalahpahaman yang umum adalah bahwa Redux hanya untuk Bereaksi. Sepertinya Redux tidak bisa melakukan apapun tanpa React. Memang, Redux melengkapi React dalam beberapa hal penting, seperti yang telah kita bahas sebelumnya. Ini adalah kasus penggunaan yang paling umum.
Namun, pada kenyataannya, Redux dapat bekerja dengan kerangka kerja front-end apa pun, seperti Angular, Ember.js atau bahkan jQuery, atau bahkan vanilla JavaScript. Coba googling, Anda akan menemukan ini, ini, ini atau bahkan ini. Ide umum Redux berlaku di mana saja!
Selama Anda menggunakan Redux dengan bijak, Anda bisa mendapatkan manfaatnya dalam banyak situasi — tidak hanya di aplikasi React.
Kesimpulan
Seperti alat apapun, Redux menawarkan tradeoff. Ini memungkinkan fitur-fitur canggih tetapi juga memiliki kelemahan yang tak terhindarkan. Tugas tim pengembangan adalah mengevaluasi apakah pengorbanan itu sepadan dan membuat keputusan secara sadar.
Sebagai desainer, jika kita memahami kelebihan dan kekurangan Redux, kita akan dapat berkontribusi pada pengambilan keputusan ini dari perspektif desain. Misalnya, mungkin kita dapat mendesain UI untuk mengurangi potensi dampak kinerja? Mungkin kami dapat menganjurkan penyertaan fitur undo/redo untuk menghapus banyak dialog konfirmasi? Mungkin kami dapat menyarankan UI yang optimis karena meningkatkan pengalaman pengguna dengan biaya yang relatif rendah?
Pahami manfaat dan keterbatasan suatu teknologi, dan rancang sesuai dengan itu. Saya pikir itulah yang dimaksud Steve Jobs dengan "desain adalah cara kerjanya."