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
Mari kita bicara tentang komponen Avatar .
<Avatar image="simons-cat.png" />
Avatar ditemukan di mana-mana dalam aplikasi dan biasanya datang dalam berbagai ukuran. Anda memerlukan avatar besar untuk profil pengguna, yang kecil di daftar drop-down dan beberapa yang menengah.
Mari kita tambahkan size penyangga (penyangga untuk ukuran).
Kami tidak ingin memberi pengembang kemampuan untuk menentukan lebar dan tinggi sewenang-wenang, sebaliknya, kami ingin memberi pengembang beberapa ukuran yang memungkinkan.
<Avatar size="xsmall" image="simons-cat.png" /> <Avatar size="small" image="simons-cat.png" /> <Avatar size="medium" image="simons-cat.png" /> <Avatar size="large" image="simons-cat.png" /> <Avatar size="xlarge" image="simons-cat.png" />
Di kosmos , kami masih memiliki avatar untuk aplikasi. Kami ingin mereka terlihat sedikit berbeda - bujur sangkar bukannya lingkaran.
Bagian dari menciptakan API yang baik adalah untuk memberikan pengembang kemampuan untuk berpikir tentang data daripada desain - desain harus sudah ada dalam komponen
Kita dapat menambahkan prop lainnya yang membedakan antara dua jenis avatar. Satu penyangga kecil tidak sakit, kan?
<Avatar type="user" image="simons-cat.png" /> <Avatar type="app" image="firebase.png" />
Terlihat bagus, bukan?
Dan ya, kami mendapatkan dukungan multi-ukuran untuk avatar aplikasi, karena itu adalah komponen yang sama. Secara umum, kami tidak membutuhkan ini, tetapi mengapa tidak, karena tidak ada biaya apa pun dari kami
<Avatar type="app" size="xsmall" image="firebase.png" /> <Avatar type="app" size="small" image="firebase.png" /> <Avatar type="app" size="medium" image="firebase.png" /> <Avatar type="app" size="large" image="firebase.png" /> <Avatar type="app" size="xlarge" image="firebase.png" />
Mari kita bicara tentang bagaimana pengembang akan benar-benar menggunakan komponen ini dalam aplikasinya. Informasi pengguna mungkin berasal dari API dan berisi URL avatar. Pengembang akan meneruskan informasi ini ke komponen Avatar menggunakan alat peraga.
Dan jika pengguna belum mengunggah avatar, kami ingin menunjukkan nilai default, hal yang sama berlaku untuk logo aplikasi.
<Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} />
Gambar default sudah termasuk dalam komponen, jadi kami tidak meminta pengembang untuk gambar gambar default.
Ini adalah mundur yang bagus, tetapi kita bisa berbuat lebih banyak.
Kami dapat menunjukkan inisial nama pengguna dengan latar belakang yang unik (Gmail menjadikan templat ini populer, membantu membedakan dengan cepat antara orang-orang)
<Avatar type="user" image={props.user.avatar} /> <Avatar type="user" image={missing} /> <Avatar type="user" initials={props.user.intials} image={missing} /> <Avatar type="app" image={props.app.logo} /> <Avatar type="app" image={missing} /> <Avatar type="app" icon={props.app.type} image={missing} />
Mari kita lihat semua alat peraga yang didukung oleh komponen kami:
Kami mulai dengan komponen avatar yang sederhana, tetapi sekarang mendukung semua alat peraga dan perilaku ini!
Ketika Anda melihat komponen yang mendukung banyak alat peraga, itu mungkin mencoba melakukan terlalu banyak hal. Anda baru saja membuat Apropcalypse .
Menciptakan konsep ini oleh Jenn Creighton .
Kami mencoba membuat komponen Avatar kami berfungsi untuk pengguna dan untuk aplikasi, dan pada saat yang sama bekerja dengan ukuran dan opsi yang berbeda untuk perilaku mundur.
Itu juga memungkinkan untuk kombinasi aneh yang tidak direkomendasikan untuk digunakan, seperti avatar aplikasi teks cadangan. Ingat, ini tip # 1 - jangan membuat alat peraga yang bertentangan (lihat Menulis API untuk komponen Bereaksi, bagian 1: jangan membuat alat peraga yang bertentangan )!
Oke, bagaimana kita akan berurusan dengan ini? Buat dua komponen berbeda.
Kiat:
Jangan takut untuk membuat komponen baru alih-alih menambahkan alat peraga dan logika tambahan ke komponen yang ada.
Pertama, beginilah tampilan API untuk dua komponen avatar yang berbeda:
<UserAvatar size="large" image="simons-cat.png" /> <UserAvatar size="large" image="" /> <UserAvatar size="large" fallback="LA" image="" /> <AppAvatar image="firebase.png" /> <AppAvatar image="" /> <AppAvatar fallback="database" image="" />
Ada beberapa hal yang perlu diperhatikan dalam API ini:
- Kami dapat menghapus fitur yang tidak perlu, seperti
size , di AppAvatar . - Kami mengurangi ukuran API kami dengan mempertahankan nama
fallback sama (fallback) untuk dua komponen.
Ingat tip nomor 2 dalam seri ini ? Kami ingin pengembang memikirkan perilaku ( fallback ), dan bukan tentang interaksi / implementasi (inisial atau ikon) . Ini membantu pengembang mempelajari API dan cara menggunakan komponen lebih cepat. - Kami juga dapat menghindari alat peraga yang bertentangan .
- Akhirnya, kami mengurangi jumlah alat peraga. Lihatlah tabel alat peraga, itu menjadi jauh lebih bersih:
UserAvatar:
AppAvatar:
Satu-satunya hal yang sedikit mengecewakan saya dalam API ini adalah meskipun kedua komponen memiliki nama dan tipe yang sama untuk fallback: string (fallback dengan tipe string adalah string), salah satunya mengambil dua huruf untuk inisial, sementara waktu seperti yang lain adalah nama ikon.
Mari kita bicara tentang implementasi. Sangat menggoda untuk membuat komponen BaseAvatar yang akan menggunakan UserAvatar dan AppAvatar , sementara beberapa alat peraga akan diblokir.
function UserAvatar(props) { return ( <BaseAvatar image={props.image} type="user" initials={props.fallback} /> ) } render(<UserAvatar fallback="LA" />)
Dan ini sama sekali bukan ide yang buruk. Tetapi pada awalnya sangat sulit untuk memperkirakan apa yang mungkin kita butuhkan. Kami memprediksi permintaan di masa depan dengan buruk.
Mulailah dengan dua komponen berbeda, dan saat Anda mengembangkannya, Anda dapat mulai melihat pola yang sama dan menemukan abstraksi yang baik. Kurangnya abstraksi jauh lebih baik daripada abstraksi yang salah.
Duplikasi lebih baik daripada abstraksi yang salah - Sandi Metz
Kembali ke kode Anda dan temukan komponen yang membutuhkan terlalu banyak alat peraga dan lihat apakah Anda dapat menyederhanakannya dengan memecahnya menjadi beberapa komponen.
Untuk studi lebih lanjut:
- kuliah oleh Jenn Creighton , di mana dia berbicara tentang Apropacalips
- Sandi Metz memberi kuliah tentang duplikat dan abstraksi