Bagaimana mereka melakukannya? Bagaimana mereka beralih dari mereka yang tidak bisa membuka PR tanpa bantuan dari luar ke mereka yang meminta bantuan orang lain? Apa yang membuat orang meminta saran yang bersedia diberikan saran kepada orang lain? Bagaimana siswa menjadi guru? Saya menanyakan pertanyaan-pertanyaan ini kepada mereka. Inilah yang mereka jawab.
1. Gunakan ESLint dan TypeScript
JavaScript adalah bahasa pemrograman yang diketik secara longgar. Dengan menggunakan bahasa ini, kita dapat memecahkan masalah yang sama dalam banyak cara. JavaScript tidak memiliki mekanisme bawaan untuk melindungi kami dari penulisan kode kereta atau kode yang kinerjanya buruk. Tetapi, untungnya bagi kita, kita dapat memperbaiki situasi dengan menggunakan dua alat untuk analisis kode statis. Ini adalah TypeScript dan ESLint.
Dengan menggunakan ESLint untuk analisis kode statis, kami dapat mengidentifikasi masalah sebelum mencapai produksi. Kami dapat memeriksa kode terhadap standar kami. Ini meningkatkan rawatan basis kode.
Misalnya, Anda dapat menginstal plugin ESLint
eslint-plugin-react-hooks... Plugin ini akan melihat masalah dalam kode berikut, yang terlihat sangat normal, dan akan memberi tahu kami bahwa kami melanggar salah satu aturan untuk menggunakan kait.
// ,
if (userName !== '') {
useEffect(function persistForm() {
localStorage.setItem('formData', userName);
});
}
TypeScript memungkinkan Anda untuk menggunakan sistem tipe statis untuk menangkap kesalahan terkait. Saat menggunakan TypeScript, Anda dapat menggunakan tooltip IntelliSense yang kuat yang membuat bekerja dengan berbagai komponen dan pustaka lebih cepat dan lebih mudah. Tooltips yang muncul saat Anda menulis kode Anda memberikan informasi tentang mekanisme internal komponen dan pustaka. Ini mempercepat refactoring dan mendorong konvensi pengkodean seperti obat generik.
Seseorang yang pandai mengetikkan Script tidak hanya menjadi programmer JavaScript yang lebih baik, tetapi akhirnya mulai menulis kode Bereaksi yang lebih baik.
2. Biasakan diri dengan React hooks
React Hooks telah benar-benar mengambil alih dunia pengembangan React sejak diperkenalkan pada Februari 2019. Meskipun tim Bereaksi mengatakan bahwa Anda tidak boleh memperbaiki kode lama dengan menerjemahkannya ke dalam kait, kait ada di mana-mana saat ini.
Jika Anda ingin maju dalam bidang React development, waktu terbaik yang dapat Anda lakukan adalah mempelajari hook secara mendalam sehingga Anda dapat memahaminya sepenuhnya.
Apakah Anda memerlukan semacam efek samping? Jika demikian, maka kail
useEffectadalah teman terbaik Anda. Perlu memantau keadaan komponen dan merendernya kembali saat keadaan berubah? MelihatuseState... Perlu menyimpan dan memperbarui beberapa nilai antar render, tetapi ketika nilai-nilai ini berubah, jangan render? Atau mungkin Anda perlu tahu tentang tinggi atau lebar elemen DOM? Maka temanmu adalah ini useRef.
Sebagai contoh, mari kita lihat use case yang paling sederhana
useEffect. Misalkan kita ingin mengatur agar judul halaman diperbarui (dalam bentuk efek samping) ketika sebuah tombol diklik. Anda dapat mencoba menyelesaikan masalah ini seperti ini:
useEffect(() => {
document.title = `You clicked ${count} times`;
}); //
Kait ini mudah dioptimalkan dengan membuatnya tidak berjalan di setiap render, tetapi hanya saat variabel berubah
count. Ini dilakukan dengan memasukkan countdependensi dalam array:
useEffect(() => {
document.title = `You clicked ${count} times`;
}, [count]); // count
Anda harus nyaman menggunakan kait yang paling umum dan membuat kait Anda sendiri. Anda juga harus berpengalaman dalam penggunaan kait secara rasional. Misalnya, mengetahui kapan menggunakan kait tampaknya
useEffectmenghasilkan rendering ulang dan kapan tidak.
3. Jangan optimalkan kode Anda terlalu dini
Pembicaraan tentang pengait membawa kita ke topik optimisasi prematur. Terlalu sering saya telah melihat calon pengembang Bereaksi pergi ke tulang untuk membuat kode mereka secepat mungkin. Kode Bereaksi paling sering dioptimalkan menggunakan kait
useMemodan useCallback. Namun penggunaannya tidak selalu dibenarkan.
Mari kita lihat komponen sederhana yang mengambil array informasi gula sebagai
props. Komponen menyaring array dan menampilkan daftar nama cokelat (propertinya typesama dengan nilai string chocolate).
Beberapa pengembang mungkin memiliki keinginan yang tak tertahankan untuk menulis kode yang mirip dengan yang ditunjukkan di bawah ini. Mereka mungkin berpikir, "Saya hanya akan memperbarui daftar cokelat ketika daftar keseluruhan permen berubah." Menerapkan ide ini akan menghasilkan kode kelebihan beban dengan konstruksi pembantu yang sulit dibaca.
const Chocolate = (props) => {
const chocolates = useMemo(
() => props.candies.filter((candy) => candy.type === "chocolate"),
[props.candies]
);
return (
<>
{chocolates.map((item) => (
<p>{item.name}</p>
))}
</>
);
};
Alih-alih membuat komponen seperti ini, saya akan menyarankan menulis kode sederhana dan bersih. Dalam kasus seperti ini, tidak ada alasan untuk menggunakannya
useMemo. Pengait useMemoatau useCallbackhanya digunakan untuk memoisasi hasil operasi rumit yang membuat beban besar pada sistem.
Saya sarankan menunda dimulainya pekerjaan optimasi sampai Anda mendapatkan pengukuran kinerja aplikasi yang jelas menunjukkan masalah.
Anda tidak boleh menggunakannya di mana
useCallback- mana dan useMemohanya karena Anda baru saja membaca tentang mereka di suatu tempat. Jangan mengoptimalkan semuanya. Lebih baik menunggu masalah muncul, dan kemudian menyelesaikannya. Jangan memecahkan masalah yang tidak ada.
4. Ketahui kapan harus membuat komponen baru
Saya telah melihat banyak calon programmer React mengimplementasikan logika bisnis suatu proyek dalam komponen yang dimaksudkan untuk memainkan peran presentasi murni. Untuk membuat kode Anda dapat digunakan kembali sebanyak mungkin, penting untuk membuat komponen yang semudah dan senyaman mungkin untuk digunakan kembali.
Untuk mencapai ini, Anda harus berusaha menjaga pemisahan antara komponen presentasi dan komponen yang menerapkan beberapa jenis logika. Sebelumnya, teknik umum adalah membagi komponen menjadi "wadah" dan, pada kenyataannya, "komponen". Namun pendekatan ini secara bertahap kehilangan relevansinya.
Mari kita lihat komponen yang memuat daftar item dari suatu tempat dan menampilkannya di halaman. Perhatikan bahwa kedua tugas ini diimplementasikan dalam komponen yang sama.
const ListItems = () => {
const items = React.useState([]);
React.useEffect(() => {
async function fetchItems() {
await fetched = fetchItems();
setItems(fetched);
}
});
return (
<>
{items.map((item) => (
<div className="item-container">
<img src={item.img} />
<div className="name">{item.name}</div>
<div className="author">{item.author}</div>
</div>
))}
</>
);
};
Mungkin tergoda untuk mengambil rute "wadah". Mengikuti aspirasi ini, kami akan membuat dua komponen:
const ListContainer = () => {
const items = React.useState([]);
React.useEffect(() => {
async function fetchItems() {
await fetched = fetchItems();
setItems(fetched);
}
});
return <List items={items} />;
};
const List = (props) => {
return (
<>
{props.items.map((item) => (
<div className="item-container">
<img src={item.img} />
<div className="name">{item.name}</div>
<div className="author">{item.author}</div>
</div>
))}
</>
);
};
Tetapi dalam situasi seperti itu, Anda harus bertindak berbeda. Yaitu, Anda perlu abstrak bagian-bagian komponen yang memainkan peran presentasi murni. Hasilnya akan menjadi dua komponen - komponen
List(daftar) dan komponen Item(elemen):
const List = () => {
const items = React.useState([]);
React.useEffect(() => {
async function fetchItems() {
await fetched = fetchItems();
setItems(fetched);
}
});
return (
<>
{items.map((item) => (
<Item item={item} />
))}
</>
);
};
const Item = ({ item }) => {
return (
<div className="item-container">
<img src={item.img} />
<div className="name">{item.name}</div>
<div className="author">{item.author}</div>
</div>
);
};
5. Berikan perhatian khusus pada pengujian
Tingkat kemahiran dalam teknologi pengujian adalah apa yang memisahkan junior dari senior. Jika Anda tidak terbiasa dengan pengujian aplikasi Bereaksi, Anda dapat menemukan dan mempelajari banyak materi tentangnya.
Mungkin Anda telah menulis beberapa unit test pada beberapa titik, tetapi pengalaman Anda tidak cukup untuk membuat tes integrasi yang menjangkau seluruh aplikasi? Ini seharusnya tidak mengganggu Anda, karena, sekali lagi, ada banyak sumber daya untuk membantu Anda mengisi kesenjangan dan pengalaman pengetahuan.
Sebagai contoh, inilah artikel saya tentang siklus penuh pengujian aplikasi tumpukan penuh berdasarkan Bereaksi.
6. Bedakan antara situasi di mana Anda harus menggunakan negara lokal dan global
Di sini kita akan menyentuh pada topik mengelola status aplikasi di Bereaksi. Ada banyak teknologi untuk mengatasi masalah ini. Misalnya, ini adalah redux, mobx, recoil, API,
contextdan banyak lagi. Bahkan tidak mudah untuk mendaftarkan mereka.
Tetapi terlepas dari teknologi manajemen negara mana yang Anda pilih, saya sering melihat React junior bingung ketika memutuskan apakah akan menggunakan negara global atau lokal. Sayangnya, tidak ada aturan yang jelas untuk membuat keputusan seperti itu dengan jelas. Tetapi beberapa aturan tentang masalah ini masih bisa dirumuskan. Yaitu, untuk memutuskan apakah akan menggunakan negara global atau lokal untuk menyimpan beberapa data, jawab pertanyaan berikut:
- Apakah kita memerlukan beberapa komponen yang tidak terkait langsung dengan komponen kita untuk dapat bekerja dengan datanya? Misalnya, nama pengguna dapat muncul di bilah navigasi dan pada layar pembuka.
- Haruskah data tetap ada saat menavigasi antara halaman aplikasi?
- Apakah banyak komponen menggunakan data yang sama?
Jika pertanyaan ini dapat dijawab secara positif, maka mungkin ada baiknya memanfaatkan negara global. Tapi, saya akan segera memberi tahu Anda, Anda tidak boleh menyimpan informasi tentang apa yang terjadi dengan menu di negara global. Saat memutuskan di mana akan menyimpan beberapa data, cobalah untuk berspekulasi tentang data apa yang digunakan di berbagai tempat dalam aplikasi, dan data apa yang mungkin disimpan hanya di dalam komponen.
Hasil
Sekarang Anda tahu jalan mana yang harus diambil untuk tumbuh secara profesional di bidang pengembangan Bereaksi.
Ketika saya mengingat kembali kode yang saya tulis ketika saya masih React Junior, satu hal muncul di benak saya. Saya menulis kode yang terlalu rumit yang sulit dimengerti. Ketika saya memperoleh lebih banyak pengalaman, saya mulai memperhatikan bagaimana kode saya menjadi lebih sederhana. Semakin sederhana kodenya, semakin baik. Kode saya sekarang mudah dimengerti, dan Anda dapat memahaminya bahkan enam bulan setelah ditulis, ketika ternyata kesalahan telah merayap ke dalamnya yang perlu ditangani.
Apa jalan menuju pertumbuhan profesional untuk programmer React yang Anda tahu?
