Warning: getimagesize(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/yfzbjhce/indonesiamendesain.com/wp-content/plugins/td-cloud-library/shortcodes/header/tdb_header_logo.php on line 792

Warning: getimagesize(http://indonesiamendesain.com/wp-content/uploads/2020/09/Screen-Shot-2020-07-16-at-13.07.54-300x136.png): failed to open stream: no suitable wrapper could be found in /home/yfzbjhce/indonesiamendesain.com/wp-content/plugins/td-cloud-library/shortcodes/header/tdb_header_logo.php on line 792

Warning: getimagesize(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/yfzbjhce/indonesiamendesain.com/wp-content/plugins/td-cloud-library/shortcodes/header/tdb_header_logo.php on line 792

Warning: getimagesize(http://indonesiamendesain.com/wp-content/uploads/2020/09/Screen-Shot-2020-07-16-at-13.07.54-300x136.png): failed to open stream: no suitable wrapper could be found in /home/yfzbjhce/indonesiamendesain.com/wp-content/plugins/td-cloud-library/shortcodes/header/tdb_header_logo.php on line 792

Tips Membuat Desain komponen Yang Baik Dalam Bereaksi

- Advertisement -
- Advertisement -
- Advertisement -

Sebagian besar dari kita yang menggunakan React menyukainya karena sifat deklaratifnya dan bagaimana ia mendorong kita untuk berpikir tentang aplikasi yang kompleks sebagai komposisi dari beberapa komponen UI.

Namun, sebagai pengembang, kami tidak selalu menghabiskan cukup waktu untuk memikirkan desain komponen kami dan bagaimana komponen akan berubah dan berubah dengan aplikasi kami. Pada satu titik, Anda mungkin mulai memperhatikan potongan kode yang sangat besar di basis kode Anda dan bertanya-tanya apa yang terjadi. Bahkan, jika Anda telah mengerjakan suatu proyek cukup lama, Anda mungkin tidak menyadari ada masalah, sampai seorang anggota tim meminta untuk berjalan melalui sepotong kode tertentu.

Bayangkan Anda berdua melihat komponen kompleks yang merupakan bagian dari fitur yang perlu diperluas. Anda mungkin menemukan bahwa membaca dan memahami kode memerlukan beberapa alat peraga yang berbeda untuk mendapatkan gagasan tentang bagaimana interaksi pengguna mengubah data yang diterima komponen ini. Selain itu, Anda mungkin juga harus mengikuti alat peraga yang sama di beberapa komponen pembungkus induk (hanya satu tingkat naik, jika Anda beruntung) untuk menentukan di mana keadaan masing-masing alat peraga, dan bagaimana data itu kemudian digunakan, misalnya , oleh API.

Jika Anda berada dalam situasi di mana pertimbangan tentang komponen yang kompleks menghasilkan ketidaknyamanan atau kebingungan, sebaiknya menyadari bahwa ini kemungkinan merupakan efek samping dari desain komponen yang dipikirkan, daripada langkah penting dalam pengembangan UI. Jadi mengapa kita tidak lebih peduli tentang desain komponen?

Setiap basis kode memiliki kerumitannya. Membangun produk dan memberikan fitur dengan cepat kepada pengguna memberikan nilai lebih bagi tim Anda (dan bisnis) daripada memiliki solusi yang direkayasa secara berlebihan. Sifat Bereaksi memungkinkan Anda dengan cepat menyusun komponen yang dapat digunakan kembali dan menambahkan fungsionalitas yang hilang dengan melewati beberapa alat peraga lainnya, tetapi adalah tanggung jawab kami sebagai insinyur untuk mempertimbangkan solusi dan pendekatan yang tangguh untuk berubah dan menganggap bahwa produk kami akan berkembang. Masa depan produk dan desain komponen yang baik harus ada di pikiran Anda, tetapi sering kali dilupakan. Terkadang sulit untuk memahami bagaimana menerjemahkan desain visual atau persyaratan untuk komponen Bereaksi yang berfungsi dan dapat diuji. Mungkin fitur yang akan Anda bangun tampak rumit atau mungkin Anda berurusan dengan komponen yang tampaknya memiliki banyak tanggung jawab.Atau mungkin Anda kesulitan melihat bagaimana komponen yang sudah ada yang kelebihan muatan dengan puluhan alat peraga dapat diperpanjang atau digunakan kembali di aplikasi Anda.

Berikut adalah salah satu pendekatan yang ingin saya ikuti ketika berpikir tentang desain komponen saya di awal siklus hidup fitur.

Memikirkan komponen secara terpisah

Mari kita pikirkan komponen Bereaksi secara umum. Bereaksi komponen adalah fungsi. Terlepas dari bagaimana Anda menerapkan komponen tertentu – sebagai kelas atau sebagai fungsi – komponen Anda mungkin menggunakan beberapa alat peraga sebagai argumen dan mengembalikan JSX yang menjelaskan apa yang pada akhirnya akan diberikan dalam DOM. Dengan Bereaksi, kami bertujuan untuk menulis komponen kami sebagai fungsi murni sehubungan dengan alat peraga mereka . Artinya, untuk setiap set alat peraga, komponen kami harus mengembalikan JSX yang sama.

Mengikuti prinsip Single-responsibility, fungsi – dan karenanya komponen Bereaksi – harus melakukan satu hal. Misalnya, komponen yang hanya membuat avatar pengguna yang diberi URL gambar akan dianggap sebagai komponen yang mengikuti prinsip ini. Di sisi lain, prinsipnya akan dianggap rusak jika Anda memiliki komponen yang membuat avatar pengguna jika ada, dan memanggil API untuk menghasilkan gambar acak jika tidak.

Memikirkan Bereaksi komponen secara terpisah dan mengidentifikasi peran yang dimainkan setiap komponen dengan sendirinya akan membuat Anda tidak menulis kode multi-tujuan yang terlalu rumit. Komponen murni dengan tanggung jawab tunggal berarti lebih sedikit alat peraga yang, pada gilirannya, menghasilkan komponen yang lebih mudah untuk diuji dan lebih mudah untuk dipikirkan.

Dengan mengingat hal ini, bagaimana kita benar-benar dapat menentukan apa sebenarnya tanggung jawab komponen itu? Dan bagaimana kita bisa membuatnya tahan terhadap perubahan?

Berpikir dalam istilah “nilai” & “onChange”

Kami melihat bahwa secara umum kami dapat menganggap komponen UI sebagai fungsi yang mengambil beberapa data dan mengembalikan representasi visual dari data tersebut. Kita dapat memikirkan komponen input sederhana dengan cara yang sama. Komponen input teks (input dengan atribut type = ”text”) mengambil string sebagai datanya dan merender bidang input dengan nilai itu. Demikian pula, komponen input kotak centang mengambil boolean dan menjadikan kotak dicentang atau tidak dicentang. Anda mungkin memperhatikan bahwa bidang input dan kotak centang mewakili tipe data yang berbeda – string dan boolean masing-masing. Memahami hal ini dapat membantu Anda mendekati desain komponen Anda sendiri dengan cara yang berbeda.

Bayangkan Anda sedang mengerjakan komponen input baru untuk barang belanjaan yang akan digunakan dalam bentuk belanja yang lebih besar. Seharusnya terlihat seperti ini:

Pengguna yang berinteraksi dengan komponen ini harus bisa mengetik item ke dalam bidang dan setiap item yang ditambahkan harus ditampilkan sebagai label kecil. Pengguna kemudian dapat terus menambahkan lebih banyak item atau menghapus item yang ada dengan mengklik tombol “x” pada label. Seharusnya juga mungkin untuk menghapus semua label dengan mengklik “hapus semua”.

Luangkan waktu sejenak untuk memikirkan tipe data apa yang diwakili komponen ini? Bagaimana komponen akan mengubah data itu dari waktu ke waktu?

Anda mungkin memperhatikan bahwa komponen ini mewakili daftar string – item belanja yang ditambahkan pengguna. Cara yang baik untuk merepresentasikan data ini adalah hanya dengan menggunakan serangkaian string. Saya suka menyebutnya komponen nilai .

Komponen formulir belanja yang menggunakan komponen input baru kami ✨

Untuk kesederhanaan, mari kita simpan barang belanjaan sebagai string. Dalam aplikasi dunia nyata, item individual dalam kasus penggunaan seperti ini bisa lebih kompleks, tetapi prinsip yang sama masih berlaku.

Hal berikutnya yang perlu dipertimbangkan adalah perubahan yang dapat dilakukan komponen terhadap nilainya. Kami menyebutkan dalam persyaratan bahwa komponen ini harus memungkinkan penambahan & penghapusan item individual, serta memiliki fungsi “hapus semua”. Anda dapat memilih pendekatan berikut:

Melewati beberapa alat bantu panggilan balik ke InputWithLabels. Inilah yang ingin kita hindari.

Anda mungkin telah memperhatikan bahwa dalam contoh ini, serta yang pertama, saya telah menghilangkan kode implementasi untuk komponen InputWithLabels. Terlepas dari detail implementasinya, merancang InputWithLabels sehingga menggunakan beberapa alat bantu panggilan balik hadir dengan beberapa kelemahan. Masalah pertama yang muncul adalah prop bloat. Kompleksitas komponen meningkat semata-mata oleh kenyataan bahwa ia membutuhkan 3 alat panggilan balik untuk melakukan tugasnya. Masalah kedua adalah bahwa komponen induk (dalam kasus kami itu adalah ShoppingForm) bertanggung jawab untuk memperbarui data setiap kali salah satu alat panggilan balik dipanggil, dan sebelum bertahan dalam keadaan tersebut. Ini berarti bahwa jika InputWithLabels digunakan kembali di tempat lain, logika itu perlu diimplementasikan kembali.

Ingat bahwa nilai komponen kami adalah serangkaian string. Alih-alih memiliki masing-masing alat peraga untuk setiap penangan fungsi yang diperlukan, mari kita fokus pada bagaimana nilai kita diubah oleh komponen tergantung pada fungsinya yang berbeda:

  • Ketika label ditambahkan, string baru ditambahkan ke string yang saat ini dalam array nilai.
  • Saat label dihapus, string dihapus dari array nilai.
  • Saat mengklik “hapus semua”, semua item dalam array nilai dihapus.

Kita dapat melihat bahwa dengan fungsionalitas yang diperlukan, kami dapat menggambarkan perubahan yang dilakukan pada nilai kami . Oleh karena itu alih-alih memiliki beberapa alat peraga individual pada komponen InputWithLabel kami, kami dapat menggunakan alat bantu panggilan balik tunggal. Saya menyebutnya komponen onChange .

Logika untuk menangani perubahan nilai menjadi tanggung jawab komponen kami

Fungsi yang diteruskan ke prop onChange akan dipanggil dengan nilai yang diperbarui setiap kali perlu diubah. Dengan cara ini, komponen induk tidak mengetahui detail implementasi ( bagaimana nilainya berubah). Itu dapat mengasumsikan data benar dan hanya memperbarui negara, memanggil API atau melakukan hal-hal “pintar” lainnya. Komponen lain yang menggunakan InputWithLabel dapat membuat asumsi yang sama dan tidak perlu menerapkan kembali logika yang sama berulang kali.

Mengapa ini penting?

Dengan memikirkan nilai komponen kami dan perubahan, kami dapat menggambarkan struktur data yang paling mewakili komponen kami, serta bagaimana komponen tersebut berubah seiring waktu. Mengikuti pendekatan ini membantu mendesain komponen dengan aliran data yang dapat diprediksi, membuat tujuan komponen Anda dalam aplikasi yang kompleks lebih mudah dipahami dan dipikirkan. Ketika aplikasi Anda berubah dan tumbuh dan Anda membangun aplikasi Anda di atas komponen yang dirancang dengan cara ini, memperluas fungsionalitas menjadi pertanyaan untuk mendukung perubahan baru pada nilai komponen, atau mengubah struktur data nilai jika sesuai. Sama pentingnya, memungkinkan Anda untuk mempromosikan gaya kode yang konsisten di seluruh aplikasi Anda – memfokuskan komponen bangunan di sekitar dua alat peraga utama, yang dapat terbukti sangat berharga ketika membangun sistem desain.

Unit pengujian komponen UI dalam isolasi menjadi sepele juga. Karena kita memperlakukan komponen kita sebagai fungsi nilai dan alat peraga onChange, mudah untuk menulis tes yang menyatakan panggilan balik onChange disebut dengan nilai yang diharapkan berdasarkan interaksi dengan komponen kita.

Terakhir, saya menemukan bahwa pendekatan ini bersinar lebih terang dengan TypeScript . Untuk setiap komponen yang Anda buat, Anda bisa secara eksplisit menentukan tipe untuk nilai dan onChange, atau sebagai alternatif, membuat tipe generik yang dapat digunakan kembali untuk digunakan dengan semua komponen Anda mengikuti pola ini:

atau buatlah tipe generik yang dapat digunakan kembali untuk digunakan dengan semua komponen Anda

Tentu saja, seperti halnya apa pun, ini bukan solusi peluru perak untuk semua masalah yang mungkin Anda temui. Akan ada kasus di mana pola ini tidak cocok sama sekali atau komponen di mana alat peraga tambahan di atas nilai dan onChange benar-benar dibenarkan – seperti bidang pencarian atau daftar paginasi. Ini hanya satu pendekatan untuk desain komponen dan ada pendekatan dan pola lain yang terdokumentasi dengan baik, masing-masing berlaku untuk kelas masalah yang berbeda. Terserah Anda dan tim Anda untuk secara bertahap membangun pendekatan Anda saat produk Anda tumbuh, dan tetap waspada dengan perubahan kode Anda seiring meningkatnya kompleksitas produk Anda.

Nikmati pengkodean!

sumber:blog.marvelapp.com

- Advertisement -

Latest articles

7,350 Followers
Follow

Related articles