Jadi Bereaksi 16.4.0 telah keluar! (Note translator - fitur ini ditambahkan dalam versi 16.4.0, maka tulisan ini ditulis). Dan pada saat-saat seperti itu Anda mengerti bagaimana JavaScript Anda - geek jika Anda mengikuti pembaruan kecil kerangka kerja favorit Anda. Hebat!
Jika Anda membaca
catatan rilis untuk versi 16.4 yang diterbitkan oleh tim React, pembaruan ini seharusnya dianggap agak membosankan.
Pointer Events terlihat menarik, tetapi sejujurnya, saya telah mendengar sedikit tentang mereka sebelumnya.
Selain itu, ada perbaikan bug untuk semacam metode
getDerivedStateFromProps baru (sekarang akan dipanggil pada setiap render). Saya belum cukup menggunakannya, jadi bagi saya pembaruan ini tidak terlalu penting.
Lalu saya melihat pengumuman, terkubur di bawah judul, bahwa mereka telah menambahkan komponen eksperimental baru,
unstable_Profiler . Melihat bahwa hidup saya sekarang sangat tidak stabil (
unstable_ ), saya memutuskan untuk membaca
RFC dan mencobanya.
TLDR
Orang-orang dari tim Bereaksi
mencoba menjadikan rendering asinkron . Ini dapat membuat sulit untuk menentukan kapan membuat komponen saat pemasangan / pembaruan. Oleh karena itu, mereka bermain-main dengan komponen
Profiler baru yang mengkilap ini.
Jadi apa yang bisa Anda gunakan hari ini?Jadi, jika Anda ahli dalam melacak kinerja aplikasi reaksi Anda, ini pasti akan menjadi alat lain yang baik di gudang senjata Anda. Jika ini bukan tentang Anda, Anda tidak bisa lagi membaca dan kembali membuat aplikasi keren.
Menggunakan <Profiler />
Peringatan : mungkin Anda sebaiknya tidak menggunakan ini dalam produksi (well, sebenarnya, ini unstable_ ). Nantinya mereka akan menyelesaikan kemampuan profil dan kode produksi.Pada dasarnya,
Profiler adalah komponen yang dapat diekstraksi dari paket Bereaksi default. Karena memiliki nama garis bawah yang hati-hati yang disumpah oleh banyak linter, Anda dapat mengatasi ini sebagai berikut:
import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler;
Sekarang Anda memiliki
Profiler , mari kita profil komponen-komponennya! Anda bisa membungkus bagian mana pun dari pohon JSX Anda di
Profiler untuk melihat apa yang terjadi padanya.
Profiler menerima fungsi
onRender , yang menangkap informasi tentang waktu render.
Berikut ini contoh contoh sederhana :
import React, { unstable_Profiler as Profiler } from 'react'; class ComponentWithProfiling extends React.Component { state = { count: 0 }; logProfile = (id, phase, actualTime, baseTime, startTime, commitTime) => { console.log(`${id}'s ${phase} phase:`); console.log(`Actual time: ${actualTime}`); console.log(`Base time: ${baseTime}`); console.log(`Start time: ${startTime}`); console.log(`Commit time: ${commitTime}`); }; go = direction => () => this.setState(({ count }) => ({ count: direction === "up" ? count + 1 : count - 1 })); render() { return ( <Profiler id="app" onRender={this.logProfile}> <button onClick={this.go("up")}>️</button> <div>The count is {this.state.count}</div> <button onClick={this.go("down")}></button> </Profiler> ); } }
Perhatikan bahwa Anda harus memberikan
id setiap fragmen yang Anda profil. Seperti yang Anda lihat di bawah,
onRender menerima banyak metrik yang menarik:
7jroojkv30.codesandbox.ioPertama, Anda dapat melihat apa fase rendering itu (baik
mount atau
update ), yang dapat digunakan untuk mengidentifikasi bagian-bagian dari kode yang diperbarui secara tak terduga (seperti paket
mengapa-did-Anda-perbarui yang sangat baik yang saya gunakan berkali-kali dan sangat merekomendasikan).
Selanjutnya, kita mendapatkan
actualTime dan
baseTime . Mereka terkait dengan waktu aktual yang React habiskan untuk merender perhitungan; yaitu mencari tahu apa yang telah berubah. Harap dicatat bahwa waktu aktual (waktu awal) dari koneksi awal (pemasangan) lebih panjang dari waktu pembaruan (pembaruan). Ini karena pada koneksi awal, secara teknis semuanya "baru". Saat memperbarui, perhitungan
harus lebih sederhana, karena, saya harap, komponen dalam pohon diperbarui hanya jika mereka benar-benar telah berubah (yaitu, ketika nilai prop / negara telah berubah).
Dalam aplikasi besar / dunia nyata, data ini akan memungkinkan Anda untuk memahami di
shouldComponentUpdate digunakan dengan salah atau tidak sama sekali, tempat-tempat di mana props dengan tipe referensi sering berubah atau props baru dikirim, atau hanya tempat-tempat di mana Anda tidak mengharapkan pembaruan memakan waktu lama.
Nilai terakhir yang kami dapatkan di
onRender adalah
startTime dan
commitTime . Ini sebenarnya adalah cap waktu sejak peluncuran awal.
startTime adalah waktu dari mana komponen yang dipilih mulai melakukan perhitungan untuk rendering, sementara
commitTime adalah waktu ketika Bereaksi benar-benar
melakukan perubahan ini selama rendering.
Jika Anda melacak peristiwa lain dengan cap waktu (seperti klik atau penekanan tombol), maka metrik ini dapat membantu mengidentifikasi delta antara saat peristiwa pengguna terjadi dan ketika rendering yang sebenarnya terjadi. Jika kesenjangannya besar, keterlambatan ini dapat diraba oleh pengguna dan harus diperiksa dengan cermat.
Kesimpulan
Bagi saya pribadi, alat ini belum terlalu bermanfaat. Tetapi ini adalah salah satu hal yang baik untuk diketahui, karena jika saya pernah menemukan hambatan kinerja ini, itu akan menjadi cara yang baik untuk mengukurnya.
Penting untuk terlebih dahulu mengukur masalah kinerja Anda, jadi ketika Anda melakukan "perbaikan", Anda dapat mengetahui apakah ini benar-benar memperbaiki situasi atau hanya memburuk. Saya menemukan bahwa mengoptimalkan kinerja adalah salah satu hal yang dapat Anda habiskan banyak waktu. Karena itu, sebelum Anda mengoptimalkan sesuatu., Pastikan itu benar-benar diperlukan.
Saya menantikan apa yang akan dilakukan tim React dengan
Profiler di masa depan. Terima kasih
@bvaughn untuk menambahkan fitur
bagus ini!
Dari penerjemah:Saat ini (versi 16.6.0 saat ini) Profiler tidak berfungsi dengan rendering sisi server.
Permintaan fitur sudah ada.