Menulis API untuk komponen Bereaksi, bagian 1: jangan membuat alat peraga yang bertentangan
Menulis API untuk Komponen Bereaksi, Bagian 2: Beri Nama untuk Perilaku, Bukan Interaksi
Menulis API untuk komponen Bereaksi, bagian 3: urutan alat peraga penting
Menulis API untuk Komponen Bereaksi, Bagian 4: Waspadai Apropacalypse!
Menulis API untuk Komponen Bereaksi, Bagian 5: Cukup Gunakan Komposisi
Kami menulis API untuk komponen Bereaksi, bagian 6: kami membuat komunikasi antar komponen
Kami memiliki komponen sakelar - Switch , yang menerima prop, sebut saja itu something saat ini.
Pengembang yang menggunakan komponen kami dapat melewati suatu fungsi, dan kami akan menyebutnya ketika nilainya berubah.
<Switch something={fn} />
Bereaksi memberi kita kemampuan untuk memanggil prop seperti yang kita inginkan: handler / clickHandler / onClick / onToggle , dll.
Konvensi bahwa nama penangan acara harus dimulai dengan, misalnya, onClick , onClick . Ini karena spesifikasi HTML memiliki banyak penangan yang sudah mengikuti konvensi ini: onkeydown , onchange , onclick , dll.
Menggunakan kembali perjanjian yang ada adalah ide bagus, pengembang tidak perlu mengingat sesuatu yang baru.
OK, bagaimana dengan onClick ?
<Switch onClick={fn} />
Di sini saya bukan pendukung nama onClick , nama seperti itu menunjukkan bahwa klik mouse adalah satu-satunya cara untuk berinteraksi dengan komponen ini.
Pengguna pada perangkat seluler dapat menekan sakelar dengan jari atau menyeretnya ke kanan. Pengguna tunanetra dapat menggunakannya dengan perangkat lunak pembaca layar dan menggunakan tombol keyboard.
Sebagai pengembang yang menggunakan komponen ini, saya tidak ingin memikirkan bagaimana pengguna akhir berinteraksi dengan komponen ini. Saya hanya ingin melampirkan fungsi yang dipanggil ketika nilai berubah.
Berikan nama untuk API Anda yang tidak akan menunjukkan cara berinteraksi:
<Switch onToggle={fn} />
Itu masuk akal, bukan? Beralih Toggle (beralih) antara dua nilai.
Di dalam komponen, Anda mungkin ingin mem-proxy semua interaksi yang mungkin dalam fungsi yang sama
function Switch(props) { return ( <div className="switch" /* */ onClick={props.onToggle} onKeyDown={function(event) { /* enter , event */ if (event.key === 'Enter') props.onToggle(event) }} onDrag={function(event) { /* */ if (event.toElement === rightSide) props.onToggle(event) }} /> ) }
Kami memperhitungkan semua opsi untuk memberikan API yang jelas kepada pengguna kami (pengembang).
Sekarang mari kita bicara tentang komponen input teks.
<TextInput />
HTML memiliki atribut onchange , Bereaksi dokumentasi menggunakan onChange dalam contohnya. Rupanya, ada konsensus tentang skor ini.
<TextInput onChange={fn} />
Sangat sederhana.
Sekarang mari kita letakkan kedua komponen ini berdampingan.
<TextInput onChange={fn} /> <Switch onToggle={fn} />
Lihat sesuatu yang aneh?
Terlepas dari kenyataan bahwa kedua komponen memerlukan perilaku yang sama, properti disebut berbeda. Alat peraga ini sempurna untuk komponen masing-masing, tetapi ketika Anda melihat komponen Anda bersama-sama, itu terlihat sangat kontroversial.
Pengembang yang akan menggunakan komponen ini harus selalu memeriksa nama prop sebelum menggunakannya.
Jadi di sini adalah tip # 2: berusaha untuk alat peraga yang konsisten antara komponen . Perilaku yang sama harus memiliki penyangga yang sama untuk semua komponen.
Saran ini juga dapat dirumuskan sebagai berikut: Berusaha keras untuk area API minimum . Anda harus membatasi jumlah API yang harus dikuasai pengembang sebelum ia dapat bekerja secara produktif.
Saya ingin mengatakan bahwa semua manfaat pada topik ini ditujukan kepada Sebastian Markbåge . (Presentasinya: Area Permukaan API Minimal )
Cara menerapkan saran ini adalah dengan memilih satu prop dan menggunakannya di semua komponen Anda. Dari dua alat peraga yang kita miliki dalam contoh kita, onChange juga dalam spesifikasi HTML, sehingga beberapa pengembang mungkin mengenalinya.
<TextInput onChange={fn} /> <Switch onChange={fn} /> <Select onChange={fn} /> // etc.
Konsistensi antara komponen dan, sebagai akibatnya, kesederhanaan mempelajari API Anda melebihi pilihan prop "ideal" untuk satu komponen.
Bonus kecil.
Mari kita bicara tentang tanda tangan dari fungsi ini.
<TextInput onChange={fn} />
onChange event onChange ( fn dalam contoh ini) menerima satu argumen - event .
Ini bekerja dengan setiap perubahan. Anda bisa mendapatkan banyak informasi berguna dari acara ini.
function fn(event) { console.log(event.target)
Kemungkinan besar, sebagian besar pengembang akan tertarik pada event.target.value sehingga mereka dapat menggunakannya untuk beberapa tugas lain - gunakan dalam keadaan, kirimkan formulir, dll.
Dalam kasus komponen Switch kami, setiap tindakan mewakili "peristiwa" yang terpisah - event . event ini akan memiliki properti berbeda untuk mengklik dan menarik. Bagaimana kami memastikan API konsisten?
Kami dapat secara manual mengatur event.target.value untuk setiap "acara":
function Switch(props) { const fireHandler = event => { const newValue = !oldValue event.target.value = newValue props.onChange(event) } return ( <div className="switch" /* */ onClick={fireHandler} onKeyDown={function(event) { if (event.key === 'Enter') fireHandler(event) }} onDrag={function(event) { if (event.toElement === rightSide) fireHandler(event) }} /> ) }