Jangan Keliru Menganggap Data Shape sebagai State Shape
Saat Anda membangun form React, Anda sering kali mengelompokkan semuanya ke dalam satu objek state yang besar.
Anda melihat bagian Alamat di UI Anda. Anda membuat objek alamat di dalam state Anda. Terlihat terorganisir. Terlihat rapi.
Ini adalah jebakan.
Masalahnya bukan pada React. Masalahnya adalah bentuk (shape) dari state Anda.
Form bukanlah data statis. Form adalah sistem interaktif. Pengguna tidak memperbarui form bagian demi bagian. Mereka memperbaruinya field demi field.
Mengapa state bersarang (nested state) merugikan proyek Anda:
- Update menjadi berat. Untuk mengubah satu nama kota, Anda harus membuat ulang objek kota, alamat, dan objek form tingkat atas untuk menjaga immutability.
- Kompleksitas bocor. Seiring berkembangnya form, logika validasi dan rendering Anda menjadi lebih sulit dikelola.
- Re-render meningkat. Mengubah satu nilai bersarang menciptakan referensi objek baru. Hal ini dapat memicu pembaruan yang tidak perlu di seluruh pohon komponen (component tree) Anda.
- Beban kognitif meningkat. Anda berhenti memikirkan pengguna dan mulai memikirkan jalur objek (object paths).
Form kecil bersifat toleran. Form produk tidak.
Form produksi membutuhkan validasi, autosave, dan logika kondisional. Jika Anda membangun ini di atas objek yang bersarang dalam, setiap fitur baru akan terasa berat.
Solusinya adalah merancang state berdasarkan bagaimana data berubah, bukan berdasarkan tampilannya.
Bentuk state yang lebih datar (flatter) menawarkan manfaat berikut:
- Update lebih cepat. Anda menyentuh lebih sedikit kode untuk mengubah satu nilai.
- Debugging lebih mudah. Update tetap bersifat lokal dan dapat diprediksi.
- Batasan komponen yang lebih baik. Anda dapat mengirimkan potongan data kecil alih-alih objek besar.
Jangan meratakan (flatten) semuanya secara membabi buta. Jika data jarang berubah dan selalu bergerak bersamaan, nesting tidak masalah. Namun, jangan melakukan nesting pada bagian form yang berubah terus-menerus.
Ajukan pertanyaan-pertanyaan ini kepada diri sendiri sebelum Anda menulis kode:
- Field mana yang paling sering berubah?
- Bagian mana yang membutuhkan validasi independen?
- Update mana yang harus tetap terisolasi dari bagian UI lainnya?
Jika memperbarui satu field terasa lebih sulit daripada perubahan itu sendiri, maka struktur state Anda adalah masalahnya.
Berhentilah memodelkan state Anda mengikuti UI Anda. Mulailah memodelkannya mengikuti perilaku pengguna Anda.