Tutorial Bereaksi: Komponen, Kait, dan Performa

Seperti yang ditunjukkan di bagian pertama tutorial React kami, memulai dengan React relatif mudah. Mulailah dengan menggunakan Create React App (CRA), memulai proyek baru, dan mulai mengembangkan. Sayangnya, seiring waktu, Anda mungkin menghadapi situasi di mana kode Anda akan menjadi agak sulit untuk dipertahankan, terutama jika Anda baru mengenal React. Komponen mungkin menjadi terlalu besar atau Anda bisa berakhir dengan elemen yang bisa menjadi komponen tetapi bukan, sehingga Anda bisa menulis kode berulang di sana-sini.

Di situlah Anda harus benar-benar memulai perjalanan React Anda—dengan mulai memikirkan solusi pengembangan React.

Setiap kali Anda mendekati aplikasi baru, desain baru yang Anda perlukan untuk diubah menjadi aplikasi React nanti, pertama-tama coba putuskan komponen apa yang akan ada dalam sketsa Anda, bagaimana Anda dapat memisahkan sketsa agar lebih mudah dikelola, dan elemen mana yang berulang (atau setidaknya perilaku mereka). Cobalah untuk menghindari menambahkan kode yang mungkin "berguna di masa depan"—mungkin menggoda, tetapi masa depan itu mungkin tidak akan pernah datang dan Anda akan mempertahankan fungsi/komponen generik ekstra yang memiliki banyak opsi yang dapat dikonfigurasi.

Juga, jika sebuah komponen lebih panjang dari, katakanlah 2-3 tinggi jendela, mungkin ada baiknya memisahkan (jika mungkin)—karena akan lebih mudah untuk membacanya nanti.

Komponen Terkendali vs. Tidak Terkendali di React

Di sebagian besar aplikasi, ada kebutuhan untuk input dan beberapa bentuk interaksi dengan pengguna, memungkinkan mereka untuk mengetik sesuatu, mengunggah file, memilih bidang, dan sebagainya. React menangani interaksi pengguna dalam dua cara berbeda— komponen yang dikontrol dan tidak dikontrol .

Nilai dari komponen yang dikontrol, seperti namanya, dikendalikan oleh React dengan memberikan nilai pada elemen yang berinteraksi dengan pengguna, sedangkan elemen yang tidak dikontrol tidak mendapatkan properti nilai. Berkat itu, kami memiliki satu sumber kebenaran yang kebetulan adalah status React, jadi tidak ada ketidaksesuaian antara apa yang kami lihat di layar dan apa yang kami miliki saat ini di negara kami. Pengembang harus melewati fungsi yang akan merespons interaksi pengguna dengan formulir, yang akan mengubah statusnya.

 class ControlledInput extends React.Component { state = { value: "" }; onChange = (e) => this.setState({ value: e.target.value }); render() { return ( <input value={this.state.value} onChange={this.onChange}/> ); } }

Dalam komponen React yang tidak terkontrol, kita tidak peduli tentang bagaimana nilainya berubah, tetapi jika kita ingin mengetahui nilai pastinya, kita cukup mengaksesnya melalui ref.

 class UncontrolledInput extends React.Component { input = React.createRef(); getValue = () => { console.log(this.input.current.value); }; render() { return ( <input ref={this.input}/> ); } }

Jadi mana yang harus digunakan kapan? Saya akan mengatakan bahwa komponen yang dikontrol adalah cara yang harus dilakukan dalam banyak kasus, tetapi ada beberapa pengecualian. Misalnya, satu kasus di mana Anda perlu menggunakan komponen yang tidak terkontrol di React adalah input jenis file , karena nilainya hanya-baca dan tidak dapat diatur secara terprogram (interaksi pengguna diperlukan). Selain itu, menurut saya komponen yang dikontrol lebih mudah dibaca dan digunakan. Melakukan validasi untuk komponen yang dikontrol didasarkan pada rendering, status dapat diubah, dan kita dapat dengan mudah menunjukkan bahwa ada sesuatu yang salah dengan input (misalnya, format atau kosong).

referensi

Kami telah menyebutkan refs , yang merupakan fitur khusus yang tersedia di komponen kelas hingga kait muncul di 16.8.

Referensi dapat memberi pengembang akses ke komponen React atau elemen DOM (tergantung pada tipe tempat kita melampirkan referensi) melalui referensi. Ini dianggap sebagai praktik yang baik untuk mencoba menghindarinya dan menggunakannya hanya dalam skenario yang harus dimiliki, karena membuat kode sedikit lebih sulit untuk dibaca dan memutus aliran data dari atas ke bawah. Namun, ada kasus di mana mereka diperlukan, terutama pada elemen DOM (misalnya, mengubah fokus secara terprogram). Saat melampirkan ke elemen komponen React, Anda dapat dengan bebas menggunakan metode dari dalam komponen yang Anda maksud. Namun, praktik ini harus dihindari karena ada cara yang lebih baik untuk mengatasinya (misalnya, mengangkat status dan memindahkan fungsi ke komponen induk).

Referensi juga memiliki tiga cara berbeda untuk menyelesaikannya:

• Menggunakan string literal (warisan dan harus dihindari),
• Menggunakan fungsi panggilan balik yang diatur dalam atribut ref,
• Dengan membuat ref sebagai React.createRef() dan mengikatnya ke properti kelas dan mengaksesnya melaluinya (perhatikan bahwa referensi akan tersedia dari siklus hidup componentDidMount).

Terakhir, ada kasus ketika referensi tidak diturunkan dan saat Anda ingin mengakses elemen referensi yang lebih dalam dari komponen saat ini (misalnya, Anda memiliki komponen <Button> yang memiliki elemen DOM <input> di dalam dan saat ini Anda berada dalam komponen <Row> , dan dari komponen baris Anda ingin memiliki akses untuk memasukkan fungsi fokus DOM. Di situlah Anda akan menggunakan forwardRef ).

Satu kasus di mana referensi tidak diturunkan adalah ketika ada komponen tingkat tinggi yang digunakan pada suatu komponen — alasannya cukup dapat dimengerti karena ref BUKAN prop (mirip dengan key ) sehingga tidak diturunkan sehingga akan akan mereferensikan HOC alih-alih komponen yang dibungkus olehnya. Dalam kasus seperti itu, kita dapat menggunakan React.forwardRef yang mengambil props dan ref sebagai argumen, yang kemudian dapat diberikan ke prop dan diturunkan ke komponen yang ingin kita akses.

 function withNewReference(Component) { class Hoc extends React.Component { render() { const {forwardedRef, ...props} = this.props; return <Component ref={forwardedRef} {...props}/>; } } return React.forwardRef((props, ref) => { return <Hoc {...props} forwardedRef={ref} />; }); }

Batas Kesalahan

Hal-hal yang lebih kompleks mendapatkan, semakin tinggi kemungkinan bahwa sesuatu akan salah. Itu sebabnya batas kesalahan adalah bagian dari Bereaksi. Jadi bagaimana mereka bekerja?

Jika terjadi kesalahan dan tidak ada batasan kesalahan sebagai induknya, itu akan mengakibatkan seluruh aplikasi React gagal. Lebih baik tidak menampilkan informasi daripada menyesatkan pengguna dan menampilkan informasi yang salah, tetapi itu tidak berarti bahwa Anda harus membuat crash seluruh aplikasi dan menampilkan layar putih. Dengan batasan kesalahan, Anda memiliki tingkat fleksibilitas tambahan yang dapat Anda gunakan. Anda dapat menggunakan satu di seluruh aplikasi dan menampilkan pesan kesalahan, atau menggunakannya di beberapa widget dan tidak menampilkannya, atau menampilkan sejumlah kecil informasi sebagai gantinya widget tersebut.

Ingatlah bahwa ini hanya tentang masalah dengan kode deklaratif daripada kode imperatif yang Anda tulis untuk menangani beberapa peristiwa atau panggilan. Untuk ini, Anda masih harus menggunakan pendekatan coba/tangkap biasa.

Batas kesalahan juga merupakan tempat di mana Anda dapat mengirim informasi ke Pencatat Kesalahan yang Anda gunakan (dalam metode siklus hidup componentDidCatch ).

 class ErrorBoundary extends React.Component { state = { hasError: false }; static getDerivedStateFromError(error) { return { hasError: true }; } componentDidCatch(error, info) { logToErrorLogger(error, info); } render() { if (this.state.hasError) { return <div>Help, something went wrong.</div>; } return this.props.children; } }

Komponen Orde Tinggi

Komponen Orde Tinggi (HOC) sering disebutkan dalam Bereaksi dan merupakan pola yang sangat populer, yang mungkin akan Anda gunakan (atau sudah melakukannya). Jika Anda terbiasa dengan HOC, Anda mungkin pernah melihat withNavigation, connect, withRouter di banyak perpustakaan.

HOC hanyalah fungsi yang mengambil komponen sebagai argumen dan akan mengembalikan komponen baru dengan kemampuan yang diperluas dibandingkan dengan yang tanpa pembungkus HOC. Berkat itu, Anda dapat mencapai beberapa fungsi yang dapat diperluas dengan mudah yang dapat meningkatkan komponen Anda (misalnya, akses ke navigasi). HOC juga dapat mengambil beberapa bentuk yang dipanggil tergantung pada apa yang kita miliki, satu-satunya argumen yang selalu diperlukan adalah komponen, tetapi dapat mengambil argumen tambahan—beberapa opsi, atau seperti di connect , Anda terlebih dahulu memanggil fungsi dengan konfigurasi yang kemudian mengembalikan fungsi yang mengambil komponen argumen dan mengembalikan HOC.

Ada beberapa hal yang bisa Anda tambahkan dan hindari:

• Tambahkan nama tampilan untuk fungsi HOC pembungkus Anda (sehingga Anda tahu bahwa itu sebenarnya adalah HOC dengan mengubah nama tampilan komponen HOC Anda).
• Jangan gunakan HOC di dalam metode render—Anda seharusnya sudah menggunakan komponen yang disempurnakan di dalamnya, alih-alih membuat komponen HOC baru di sana karena selalu memasangnya kembali dan kehilangan statusnya saat ini.
• Metode statis tidak disalin, jadi jika Anda ingin memiliki beberapa metode statis di dalam HOC yang baru dibuat, Anda harus menyalinnya sendiri.
• React.forwardRef seperti yang disebutkan sebelumnya untuk menyelesaikan masalah tersebut.

 export function importantHoc() { return (Component) => class extends React.Component { importantFunction = () => { console.log("Very Important Function"); }; render() { return ( <Component {...this.props} importantFunction={this.importantFunction} /> ); } }; }

Penataan gaya

Penataan gaya tidak selalu terkait dengan React itu sendiri tetapi perlu disebutkan karena sejumlah alasan.

Pertama-tama, gaya CSS/inline biasa berlaku di sini seperti biasa dan Anda cukup menambahkan nama kelas dari CSS di atribut className, dan itu akan berfungsi dengan benar. Penataan inline sedikit berbeda dari penataan HTML biasa. String tidak diturunkan dengan gaya melainkan objek dengan nilai yang benar untuk masing-masingnya. Atribut style juga camelCased, jadi border-radius menjadi borderRadius dan seterusnya.

React tampaknya telah mempopulerkan beberapa solusi yang menjadi biasa tidak hanya di React, seperti modul CSS yang baru-baru ini terintegrasi dalam CRA, di mana Anda dapat mengimpor name.modules.css dan menggunakan kelasnya seperti properti untuk menata komponen Anda (beberapa IDE , misalnya, WebStorm, juga memiliki Pelengkapan Otomatis untuk itu, yang memberi tahu Anda nama apa yang tersedia).

Solusi lain yang juga populer di React adalah CSS-in-JS (misalnya, perpustakaan emotion ). Hanya untuk menunjukkan lagi, modul dan emosi CSS (atau CSS-in-JS secara umum) tidak terbatas pada Bereaksi.

Kait di React

Hooks mungkin merupakan tambahan yang paling ditunggu-tunggu untuk React sejak penulisan ulang. Apakah produknya sesuai dengan hype? Dari sudut pandang saya, ya, karena mereka benar-benar fitur yang hebat. Mereka pada dasarnya adalah fungsi yang membuka peluang baru, seperti:

• Mengizinkan penghapusan banyak komponen class yang hanya kami gunakan karena kami tidak dapat memilikinya, misalnya, status lokal atau referensi, sehingga kode untuk komponen terlihat lebih mudah dibaca.
• Memungkinkan Anda menggunakan lebih sedikit kode untuk efek yang sama.
• Membuat fungsi menjadi lebih mudah untuk dipikirkan dan diuji, misalnya dengan menggunakan react-testing-library.
• Dapat juga mengambil parameter, dan hasilnya dapat dengan mudah digunakan oleh kait lain (misalnya, setState dari useState di useEffect ).
• Memperkecil jauh lebih baik daripada kelas, yang cenderung sedikit lebih bermasalah untuk minifier.
• Mungkin menghapus HOC dan merender pola alat peraga di aplikasi Anda yang menimbulkan masalah baru meskipun telah dirancang untuk menyelesaikan masalah lain.
• Mampu dibuat khusus oleh pengembang React yang terampil.

Ada beberapa kait React yang disertakan sebagai default. Tiga yang dasar adalah useState , useEffect , dan useContext . Ada juga beberapa tambahan, misalnya useRef dan useMemo , tetapi untuk saat ini, kita akan fokus pada dasar-dasarnya.

Mari kita lihat useState , dan mari kita gunakan untuk membuat contoh penghitung langsung. Bagaimana cara kerjanya? Yah, pada dasarnya, seluruh konstruksinya sangat mudah dan terlihat seperti:

 export function Counter() { const [counter, setCounter] = React.useState(0); return ( <div> {counter} <button onClick={() => setCounter(counter + 1)}>+</button> </div> ); };

Itu dipanggil dengan initialState (nilai) dan mengembalikan array dengan dua elemen dengannya. Berkat tugas destrukturisasi array, kita dapat langsung menetapkan variabel ke elemen-elemen ini. Yang pertama selalu merupakan status terakhir setelah pembaruan, sedangkan yang lainnya adalah fungsi yang akan kita gunakan untuk memperbarui nilainya. Tampaknya agak mudah, bukan?

Juga, karena komponen seperti itu dulu disebut komponen fungsional stateless, nama seperti itu tidak tepat lagi, karena mereka dapat memiliki status seperti yang ditunjukkan di atas. Oleh karena itu, nama komponen kelas dan komponen fungsi tampaknya lebih sesuai dengan apa yang sebenarnya mereka lakukan, setidaknya dari 16.8.0.

Fungsi update (dalam kasus kami setCounter ), juga dapat digunakan sebagai fungsi yang akan mengambil nilai sebelumnya sebagai argumen dalam bentuk berikut:

 <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button>

Namun, tidak seperti komponen kelas this.setState yang melakukan penggabungan dangkal, pengaturan fungsi ( setCounter dalam kasus kami) menggantikan seluruh status.

Selain itu, initialState juga bisa berupa fungsi, bukan sekadar nilai biasa. Ini memiliki keuntungannya sendiri, karena fungsi itu hanya akan dijalankan selama render awal komponen dan setelah itu, tidak akan dipanggil lagi.

 const [counter, setCounter] = useState(() => calculateComplexInitialValue());

Terakhir, jika kita akan menggunakan setCounter dengan nilai yang sama persis dengan yang kita miliki pada saat yang sama dalam status saat ini ( counter ), maka komponen tidak akan dirender.

Di sisi lain, useEffect adalah tentang menambahkan efek samping ke komponen fungsional kami, baik itu langganan, panggilan API, timer, atau apa saja yang mungkin berguna bagi kami. Setiap fungsi yang akan kita berikan ke useEffect akan dijalankan setelah render, dan itu akan dilakukan setelah setiap render kecuali jika kita menambahkan batasan mengenai perubahan properti apa yang harus dijalankan kembali sebagai argumen kedua dari fungsi tersebut. Jika kita ingin menjalankannya hanya saat mount dan membersihkan saat unmount, maka kita hanya perlu melewatkan array kosong di dalamnya.

 const fetchApi = async () => { const value = await fetch("https://jsonplaceholder.typicode.com/todos/1"); console.log(await value.json()); }; export function Counter() { const [counter, setCounter] = useState(0); useEffect(() => { fetchApi(); }, []); return ( <div> {counter} <button onClick={() => setCounter(prevCounter => prevCounter + 1)}>+</button> <button onClick={() => setCounter(prevCounter => prevCounter - 1)}>-</button> </div> ); };

Kode di atas hanya akan dijalankan sekali karena array kosong sebagai argumen kedua. Pada dasarnya, ini adalah sesuatu seperti componentDidMount dalam kasus seperti itu, tetapi ia menyala sedikit kemudian. Jika Anda ingin memiliki kait serupa yang dipanggil sebelum browser paint, gunakan useLayoutEffect , tetapi pembaruan ini akan diterapkan secara sinkron, tidak seperti useEffect .

useContext tampaknya paling mudah untuk dipahami, karena seseorang menyediakan konteks mana yang ingin kita akses (objek yang dikembalikan oleh fungsi createContext ) dan sebagai imbalannya, itu memberi kita nilai untuk konteks itu.

 const context = useContext(Context);

Akhirnya, untuk menulis hook Anda sendiri, Anda bisa menulis sesuatu seperti berikut:

 function useWindowWidth() { let [windowWidth, setWindowWidth] = useState(window.innerWidth); function handleResize() { setWindowWidth(window.innerWidth); } useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); return windowWidth; }

Pada dasarnya, kami menggunakan kait useState biasa yang kami tetapkan sebagai lebar jendela nilai awal. Kemudian di useEffect, kami menambahkan pendengar yang akan memicu handleResize pada setiap ukuran jendela. Kami juga menghapus komponen setelah dilepas (lihat kembalinya di useEffect ). Mudah?

Catatan: Penggunaan kata di semua kait adalah penting. Ini digunakan karena memungkinkan Bereaksi untuk memeriksa apakah Anda tidak melakukan sesuatu yang buruk, misalnya, memanggil kait dari fungsi JS biasa.

Memeriksa Jenis

React memiliki pemeriksaan propsnya sendiri, sebelum Flow dan TypeScript menjadi opsi.

PropTypes memeriksa apakah properti (props) yang diterima oleh komponen React dan memeriksa apakah mereka sesuai dengan yang kita miliki. Setiap kali situasi yang berbeda terjadi (misalnya, objek alih-alih array), kita akan mendapatkan peringatan di konsol. Penting untuk dicatat bahwa PropTypes hanya diperiksa dalam mode pengembangan karena dampaknya terhadap kinerja dan peringatan konsol yang disebutkan di atas.

Pada React 15.5, PropTypes berada dalam paket berbeda yang perlu diinstal secara terpisah. Mereka dideklarasikan di sepanjang properti dalam properti statis yang disebut propTypes (kejutan), menggabungkannya dengan defaultProps yang digunakan jika properti tidak terdefinisi ( undefined adalah satu-satunya kasus). DefaultProps tidak terkait dengan PropTypes, tetapi mereka dapat mengatasi beberapa peringatan yang mungkin muncul karena PropTypes.

Dua opsi lainnya adalah Flow dan TypeScript, dan keduanya jauh lebih populer saat ini (terutama TypeScript).

• TypeScript adalah superset JavaScript yang diketik, dikembangkan oleh Microsoft, yang dapat memeriksa kesalahan bahkan sebelum aplikasi berjalan dan menyediakan fungsionalitas pelengkapan otomatis yang unggul untuk pengembangan. Ini juga sangat meningkatkan refactoring. Karena dukungan Microsoft, yang memiliki pengalaman luas dengan bahasa yang diketik, ini juga merupakan pilihan yang agak aman.
• Flow bukanlah bahasa, tidak seperti TypeScript. Ini adalah pemeriksa tipe statis untuk JavaScript, jadi ini lebih mirip dengan alat yang Anda sertakan dalam JavaScript daripada bahasa. Seluruh ide di balik Flow sangat mirip dengan apa yang ditawarkan TypeScript. Ini memungkinkan Anda untuk menambahkan jenis sehingga kecil kemungkinannya untuk memiliki bug sebelum Anda menjalankan kode. Sama seperti TypeScript, Flow sekarang didukung di CRA (Create React App) sejak awal.

Secara pribadi, saya menemukan TypeScript lebih cepat (hampir seketika), terutama dalam pelengkapan otomatis, yang tampaknya sedikit lebih lambat dengan Flow. Perlu dicatat bahwa IDE seperti WebStorm, yang saya gunakan secara pribadi, menggunakan CLI untuk integrasi dengan Flow. Namun, tampaknya lebih mudah untuk mengintegrasikan penggunaan opsional dalam file, di mana Anda cukup menambahkan // @flow di awal file untuk mulai memeriksa jenis. Juga, dari apa yang saya tahu, tampaknya TypeScript memenangkan pertempuran melawan Flow pada akhirnya—ini jauh lebih populer sekarang, dan beberapa perpustakaan paling populer mendapatkan refactored dari Flow ke TypeScript.

Ada beberapa opsi lagi, yang disebutkan juga dalam dokumentasi resmi, seperti Reason (dikembangkan oleh Facebook dan mendapatkan popularitas di komunitas React), Kotlin (bahasa yang dikembangkan oleh JetBrains) dan banyak lagi.

Jelas, untuk pengembang front-end, pendekatan termudah adalah masuk dan mulai menggunakan Flow dan TypeScript, daripada beralih ke Kotlin atau F#. Namun, untuk pengembang back-end yang bertransisi ke front-end, ini mungkin sebenarnya lebih mudah untuk memulai.

Performa Produksi dan Reaksi

Perubahan paling mendasar dan jelas yang perlu Anda lakukan untuk mode produksi adalah beralih ke "produksi" untuk DefinePlugin dan menambahkan UglifyJsPlugin dalam kasus Webpack. Dalam kasus CRA, ini sesederhana menggunakan npm run build (yang akan menjalankan react-scripts build ). Ketahuilah bahwa Webpack dan CRA bukan satu-satunya opsi, karena Anda dapat menggunakan alat build lain seperti Brunch. Ini biasanya tercakup dalam dokumentasi resmi, baik itu dokumentasi React resmi atau dokumentasi untuk alat tertentu. Untuk memastikan bahwa mode diatur dengan benar, Anda dapat menggunakan React Developer Tools, yang akan memberi Anda indikasi jenis build yang Anda gunakan (produksi vs. pengembangan). Langkah-langkah di atas akan membuat aplikasi Anda berjalan tanpa pemeriksaan dan peringatan yang datang dari React dan bundel itu sendiri juga akan diminimalkan.

Ada beberapa hal lagi yang dapat Anda lakukan untuk aplikasi React Anda. Apa yang Anda lakukan dengan file JS yang dibangun? Anda dapat memulai hanya dengan "bundle.js" jika ukurannya relatif kecil, atau mungkin melakukan sesuatu seperti "vendor + bundel" atau mungkin "vendor + bagian terkecil yang diperlukan + mengimpor barang saat dibutuhkan." Ini berguna ketika Anda berurusan dengan aplikasi yang sangat besar dan Anda tidak perlu mengimpor semuanya di awal. Ketahuilah bahwa menggabungkan beberapa kode JavaScript dalam bundel utama yang bahkan tidak digunakan hanya akan menambah ukuran bundel dan membuat aplikasi memuat lebih lambat di awal.

Bundel vendor dapat berguna jika Anda berencana untuk membekukan versi perpustakaan setelah menyadari bahwa mereka mungkin tidak berubah untuk waktu yang lama (jika pernah). Juga, file yang lebih besar lebih baik dalam gzip sehingga manfaat yang Anda dapatkan dari pemisahan terkadang tidak sepadan. Itu tergantung pada ukuran file dan terkadang Anda hanya perlu mencobanya sendiri.

Pemisahan Kode

Pemisahan kode dapat muncul dalam lebih banyak cara daripada yang disarankan di sini, tetapi mari kita fokus pada apa yang kita miliki di CRA dan React itu sendiri. Pada dasarnya, untuk membagi kode menjadi potongan yang berbeda, kita dapat menggunakan import() yang bekerja berkat Webpack ( import itu sendiri adalah proposal di Tahap 3 sampai sekarang, jadi ini belum menjadi bagian dari standar bahasa). Setiap kali Webpack melihat import , ia akan mengetahui bahwa ia perlu memulai pemecahan kode pada tahap ini dan tidak dapat memasukkannya ke dalam bundel utama (kode yang ada di dalam impor).

Sekarang kita bisa menghubungkannya dengan React.lazy() yang membutuhkan import() dengan path file yang berisi komponen yang perlu di-render di tempat itu. Selanjutnya, kita dapat menggunakan React.suspense() yang akan menampilkan komponen berbeda di tempat itu hingga komponen yang diimpor dimuat. Orang mungkin bertanya-tanya; jika kita mengimpor satu komponen, lalu mengapa kita membutuhkannya?

Bukan itu masalahnya, karena React.lazy() akan menampilkan komponen yang kita import() , tetapi import() mungkin mengambil potongan yang lebih besar daripada komponen tunggal itu. Misalnya, komponen tertentu mungkin memiliki pustaka lain di belakangnya, lebih banyak kode, dll., jadi satu file tidak diperlukan—mungkin lebih banyak file yang digabungkan bersama. Terakhir, kita dapat membungkus semua itu di ErrorBoundary (Anda dapat menemukan kode di bagian kami tentang batas kesalahan) yang akan berfungsi sebagai cadangan jika ada yang gagal dengan komponen yang ingin kita impor (misalnya, jika ada kesalahan jaringan).

 import ErrorBoundary from './ErrorBoundary'; const ComponentOne = React.lazy(() => import('./ComponentOne')); function MyComponent() { return ( <ErrorBoundary> <React.Suspense fallback={<div>Loading...</div>}> <ComponentOne/> </React.Suspense> </ErrorBoundary> ); }

Ini adalah contoh dasar, tetapi Anda jelas dapat berbuat lebih banyak. Anda dapat menggunakan import dan React.lazy untuk pemisahan rute dinamis (misalnya, admin vs. pengguna biasa, atau hanya jalur besar yang membawa banyak). Ketahuilah bahwa React.lazy hanya mendukung ekspor default untuk saat ini dan tidak mendukung rendering sisi server.

Performa Kode Bereaksi

Mengenai kinerja, jika aplikasi React Anda berjalan lambat, ada dua alat yang dapat membantu Anda mengatasi masalah tersebut.

Yang pertama adalah Tab Kinerja Chrome, yang akan memberi tahu Anda apa yang terjadi dengan setiap komponen (misalnya, pasang, perbarui). Berkat itu, Anda harus dapat mengidentifikasi komponen mana yang menunjukkan masalah masalah kinerja dan kemudian mengoptimalkannya.

Pilihan lainnya adalah menggunakan DevTools Profiler yang telah tersedia di React 16.5+, dan dengan kerja sama dari shouldComponentUpdate (atau PureComponent, yang dijelaskan di bagian pertama dari tutorial ini), kita dapat meningkatkan kinerja untuk beberapa komponen penting.

Jelas, menerapkan praktik terbaik dasar untuk web adalah optimal, seperti mendebouncing beberapa peristiwa (misalnya, menggulir), berhati-hati dengan animasi (menggunakan transformasi alih-alih mengubah ketinggian dan menganimasikannya) dan seterusnya. Menggunakan praktik terbaik dapat diabaikan dengan sangat mudah, terutama jika Anda baru saja menguasai React.

Keadaan Bereaksi pada 2019 dan Setelahnya

Jika kita membahas masa depan React, secara pribadi, saya tidak akan terlalu khawatir. Dari sudut pandang saya, React tidak akan kesulitan mempertahankan tahtanya di 2019 dan seterusnya.

React memiliki kedudukan yang begitu kuat, didukung oleh komunitas yang besar, sehingga akan sulit untuk diturunkan dari tahta. Komunitas React sangat bagus, tidak kehabisan ide, dan tim inti terus bekerja untuk meningkatkan React, menambahkan fitur baru, dan memperbaiki masalah lama. React juga didukung oleh perusahaan besar, tetapi masalah lisensi telah hilang—ini adalah lisensi MIT sekarang.

Ya, ada beberapa hal yang diharapkan untuk diubah atau ditingkatkan; misalnya, membuat React sedikit lebih kecil (salah satu langkah yang disebutkan adalah menghapus kejadian sintetis) atau mengganti nama className menjadi class. Tentu saja, bahkan perubahan yang tampaknya kecil ini dapat menyebabkan masalah seperti memengaruhi kompatibilitas browser. Secara pribadi, saya juga bertanya-tanya apa yang akan terjadi ketika WebComponent mendapatkan lebih banyak popularitas, karena mungkin menambah beberapa hal yang sering digunakan React saat ini. Saya tidak percaya bahwa mereka akan menjadi pengganti langsung, tetapi saya percaya mereka dapat saling melengkapi dengan baik.

Adapun jangka pendek, kait baru saja datang ke React. Itu mungkin perubahan terbesar sejak penulisan ulang terjadi di Bereaksi, karena mereka akan membuka banyak kemungkinan dan meningkatkan komponen fungsi lebih lanjut (dan mereka benar-benar sedang digembar-gemborkan sekarang).

Terakhir, karena itulah yang saya lakukan baru-baru ini, ada React Native. Bagi saya, ini adalah teknologi hebat yang banyak berubah selama beberapa tahun terakhir (kurangnya tautan asli reaksi mungkin merupakan masalah terbesar bagi kebanyakan orang, dan jelas ada banyak bug). React Native sedang menulis ulang intinya, dan itu harus dilakukan dengan cara yang mirip dengan React rewrite (semuanya internal, tidak ada atau hampir tidak ada yang harus diubah untuk pengembang). Render asinkron, jembatan yang lebih cepat dan lebih ringan antara native dan JavaScript, dan banyak lagi.

Ada banyak hal yang dinanti-nantikan di ekosistem React, tetapi pembaruan hook (dan React Native jika seseorang menyukai ponsel) mungkin merupakan perubahan terpenting yang akan kita lihat di tahun 2019.