Lebih dari 4 tahun yang lalu, saya jatuh cinta dengan
ReactJS dan sejak itu saya telah mengembangkan semua aplikasi Front End dengan alat yang luar biasa ini. Selama waktu ini, saya dan tim-tim tempat saya beruntung bekerja membuat banyak kesalahan, banyak di antaranya berhasil diperbaiki. Banyak solusi optimal telah ditemukan dalam eksperimen yang sulit dan mahal.
Hari ini saya ingin berbagi kesalahan paling kritis dan menyakitkan yang dibuat lebih sering daripada yang lain. Sebelum menulis artikel ini, saya, tentu saja, mempelajari Internet untuk mencari artikel serupa, dan saya terkejut menemukan bahwa kebanyakan dari mereka sudah ketinggalan zaman dan berbicara tentang hal-hal yang kurang relevan pada tahun 2019. Jadi, saya mencoba menyusun daftar masalah yang paling mendesak saat ini.
1. Komponen stateful (kelas) lebih buruk dari kait
Mungkin, ada baiknya dimulai dengan fitur
ReactJS yang paling sensasional, yang muncul dalam versi 16.8+ Bertentangan dengan beberapa kepercayaan, fitur ini terganggu oleh kesalahan generasi pengembang sebelumnya dan menyelesaikan banyak masalah. Jika Anda masih menggunakan komponen kelas alih-alih kait pada 2019, maka Anda membuat kesalahan besar dan tidak mengerti apa keuntungan mereka. Saya tidak akan menjelaskan ini secara rinci dalam artikel ini, terlihat lebih
baik video indah ini oleh Den Abramov , tapi saya tidak bisa memulai artikel ini jika tidak
Ini, tentu saja, bukan kesalahan itu sendiri, tetapi pendekatan kelas dibandingkan dengan kait jauh lebih rentan kesalahan, karena banyak artikel telah ditulis tentang:
- Kesalahan paling umum dalam kode Bereaksi yang Anda (mungkin) buat
- 7 Kesalahan Paling Umum yang Terjadi pada Pengembang
2. Menggunakan fungsi anonim sebagai alat peraga
Jika kesalahan pertama masih bisa dianggap sebagai penghargaan untuk fashion, maka mengetahui yang kedua, saya jamin, akan menyelamatkan Anda dari malam tanpa tidur dan sakit kepala. Lagipula, dialah yang membuat aplikasi bekerja tidak memadai sehingga penggunanya selamanya bisa kecewa dengan
ReactJS . Tapi kami ingin pengguna mencintainya, sama seperti Anda dan saya, bukan? Untuk menghindari kesalahan ini, Anda dapat menggunakan aturan yang sangat sederhana - tidak pernah, TIDAK PERNAH melewatkan fungsi anonim ke komponen sebagai alat peraga.
export default function MyOtherComponent() { return ( <MyComponent getValue={i => i.value} /> {/* */} ); }
Versi yang lebih canggih dari kesalahan ini mungkin terlihat seperti ini (jangan baca jika Anda tidak terbiasa dengan Redux):
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; const mergeProps = ( { projectId, ...restState }: any, { fetchProjectData, ...restDispatch }: any, { memberId, ...restOwn }: any ) => ({ ...restState, ...restDispatch, ...restOwn, fetchProjectData: () => fetchProjectData(projectId), }); export default connect( mapStateToProps, mapDispatchToProps, mergeProps )(MyComponent);
Dalam kedua kasus, tentu saja, fungsi anonim masuk ke komponen
alat peraga . Ini buruk karena dengan setiap render elemen induk, fungsi ini akan merujuk ke objek baru di memori, yang berarti bahwa itu tidak akan sama dengan yang sebelumnya, dan komponen Anda akan berhasil dirender ulang secara tidak perlu. Ini dapat memperlambat kinerja aplikasi Anda sehingga Anda sendiri akan mulai meludah dan menjadi kecewa dalam
Bereaksi , tetapi intinya adalah FUNGSI ANONIM di
alat peraga . Jangan pernah melakukannya - dan berbahagialah.
Masalahnya adalah, seringkali kesalahan seperti itu tidak membuat kesalahan. Kode hanya berfungsi untuk dirinya sendiri - dan hanya itu. Dan tidak ada hal buruk yang terjadi. Tepat sampai saat Anda sekali lagi mendorong panggilan anonim untuk menerima data dari server di sana (contoh kedua), maka Anda akan memahami keseriusan masalah. Akumulasi alat peraga anonim semacam itu, sebagai hasilnya, akan memperlambat aplikasi Anda ke tingkat pengalaman pada tahun 1995, ketika kami harus meminta tetangga untuk melepaskan saluran telepon untuk mengunduh halaman tersebut.
Hanya beberapa kata, cara menulis dengan benar. Begini caranya:
const getValue = i => i.value; return default function MyOtherComponent() { return ( <MyComponent getValue={getValue} /> ); }
import { connect } from 'react-redux'; import { createStructuredSelector } from 'reselect'; import MyComponent from './MyComponent'; import { fetchProjectData, projectId } from "./store/projects" const mapStateToProps = createStructuredSelector({ projectId, }); const mapDispatchToProps = { fetchProjectData, }; export default connect( mapStateToProps, mapDispatchToProps )(MyComponent);
3. Beberapa Contoh Bereaksi dalam Aplikasi
Kesalahan ini kemungkinan besar berkaitan dengan arsitektur seluruh aplikasi secara keseluruhan, dan bukan hanya ReactJS pada khususnya. Tetapi masalah praktis ini seringkali terlalu mahal untuk pengembang dan terlalu sering untuk malam tanpa tidur.
Tolong jangan mencoba menjejalkan lebih dari satu contoh aplikasi Bereaksi pada satu halaman. Bahkan, dalam dokumentasi Bereaksi tidak ada larangan pendekatan semacam itu, saya bahkan bertemu rekomendasi untuk melakukan hal itu di beberapa artikel (dan, tentu saja, saya melakukan ini dalam aplikasi saya), TETAPI optimasi pendekatan ini dan koordinasi semua bagian aplikasi, dalam hal ini mulai mengambil lebih dari setengah dari seluruh waktu kerja. Ini dapat dengan mudah dihindari: misalnya, jika Anda perlu merespons beberapa peristiwa dalam kode lama dalam aplikasi
Bereaksi baru Anda, Anda dapat menggunakan model acara. Misalnya, seperti ini:
import React, { useCallback, useEffect } from 'react'; export default function MyComponent() { const reactHandlerOfLegacyEvent = useCallback((event) => {}, []); useEffect(() => { document.addEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); return () => { document.removeEventListener("myLegacyEvent", reactHandlerOfLegacyEvent); }; }, [reactHandlerOfLegacyEvent]); return ({}); }
4. Menulis pustaka Anda sendiri, bukan sumber terbuka yang ada
Masalah ini bukan tentang
ReactJS sama sekali, tetapi tentang seluruh pengembangan. Tentu saja, ketika Anda baru belajar, menulis sejumlah besar perpustakaan Anda sendiri akan memungkinkan Anda untuk tumbuh lebih cepat dan menjadi lebih besar, tetapi jika Anda ingin berada di garis depan pemrograman, Anda setidaknya harus mencoba masing-masing perpustakaan open source yang menyelesaikan masalah Anda. Tanyakan saja pada robot pencarian apakah ada perpustakaan yang memecahkan masalah Anda - mereka dapat menjawab pertanyaan seperti itu dengan sempurna.
Saya tidak akan memberikan contoh perpustakaan yang saya gunakan sendiri, karena Saya tahu bahwa setengah dari mereka akan menjadi usang dalam beberapa bulan dan yang lainnya akan menggantikan mereka. Dan, tampaknya, ini bertentangan dengan pernyataan aslinya. Dan sungguh, mengapa menggunakan perpustakaan yang menjadi usang dalam beberapa bulan? Jawabannya sangat sederhana - Anda dapat melihat solusi untuk masalah-masalah yang belum muncul sebelum Anda. Anda dapat meningkatkan praktik yang ada, atau memahami cara memecahkan masalah dengan lebih baik dengan contoh masalah di perpustakaan yang ada. Ini hanya dapat dilakukan dengan berinteraksi dengan dunia pengembangan melalui penggunaan perpustakaan open source.
5. Takut menggunakan kode orang lain
Seperti kesalahan sebelumnya, ini tidak
unik untuk aplikasi
ReactJS , tetapi cukup umum di dalamnya. Seberapa sering saya melihat bagaimana Juni yang hebat dengan berani menerjang pertempuran dan menulis ulang bagian-bagian dari kode yang bekerja dengan baik dan yang tidak memiliki masalah, hanya karena mereka membaca tentang salah satu dari 4 kesalahan sebelumnya. Saya sendiri seperti itu. Tetapi apa yang ada untuk menipu, saya sering membuang waktu sekarang, hanya karena gerakan adalah hidup.
Tapi saya juga belajar memahami pengembang lain, pemikiran dan masalah yang mereka temui. Lihat jumlah waktu dan upaya yang telah dihabiskan (dan tidak sia-sia) untuk menyelesaikan masalah. Dalam 3 kasus dari 5, ketika saya mencoba untuk "meningkatkan" kode orang lain, saya mendapatkan hasil yang hampir sama dengan yang saya lakukan. Hanya karena pada awal tugas, Anda biasanya tidak melihat semua masalah yang ada di masa depan. Jadi, sekarang saya menghormati kode orang lain, tidak peduli betapa aneh dan "ketinggalan zaman" bagi saya. Yang saya sarankan Anda.
Terima kasih
Terima kasih telah membaca artikel ini dan semua orang yang saya beruntung bisa bekerja sama. Terima kasih kepada kami karena membuat dunia kami lebih menarik dan memajukannya. Biarkan tidak selalu benar, tidak selalu terampil, tetapi bergerak.
Tulis tentang masalah yang Anda temui dalam komentar. Mungkin Anda memiliki solusi untuk masalah yang dijelaskan dalam artikel ini yang saya lewatkan (saya yakin itu). Semua sukses dan suasana hati yang baik!