Pendengar Acara dan Pekerja Web

Baru-baru ini saya menemukan API Pekerja Web . Sangat disayangkan bahwa saya tidak meluangkan waktu untuk alat yang didukung ini sebelumnya. Aplikasi web modern sangat menuntut kemampuan utas eksekusi JavaScript utama. Ini memengaruhi produktivitas proyek dan kemampuan mereka untuk memastikan pengalaman pengguna yang nyaman. Pekerja web adalah apa yang akhir-akhir ini dapat membantu pengembang untuk membuat proyek web yang cepat dan nyaman.

Saat aku mengerti segalanya

Pekerja web memiliki banyak kualitas positif. Tetapi saya benar-benar menyadari kegunaannya ketika saya menemukan sebuah situasi di mana aplikasi tertentu menggunakan beberapa pendengar acara DOM. Seperti acara pengiriman formulir, pengubahan ukuran jendela, klik tombol. Semua pendengar ini harus bekerja di utas utama. Jika utas utama kelebihan beban dengan operasi tertentu yang membutuhkan waktu lama untuk diselesaikan, ini berdampak buruk pada tingkat reaksi pendengar acara terhadap pengaruh pengguna. Aplikasi "melambat", acara menunggu rilis utas.

Saya harus mengakui bahwa alasan mengapa saya begitu tertarik pada acara pendengar adalah bahwa saya awalnya salah memahami tugas-tugas yang dirancang untuk diselesaikan oleh pekerja web. Pada awalnya, saya pikir mereka dapat membantu meningkatkan kecepatan eksekusi kode. Saya berpikir bahwa suatu aplikasi akan dapat melakukan lebih banyak dalam periode waktu tertentu jika beberapa fragmen kodenya akan dieksekusi secara paralel, dalam utas yang terpisah. Tetapi selama pelaksanaan kode proyek web, suatu situasi cukup umum ketika, sebelum Anda mulai melakukan sesuatu, Anda perlu menunggu beberapa peristiwa. Katakanlah DOM perlu diperbarui hanya setelah beberapa perhitungan selesai. Mengetahui hal ini, saya secara naif percaya bahwa jika saya, dalam hal apa pun, harus menunggu, itu berarti tidak masuk akal untuk mentransfer eksekusi beberapa kode ke utas terpisah.

Berikut adalah contoh kode yang dapat Anda ingat di sini:

const calculateResultsButton = document.getElementById('calculateResultsButton'); const openMenuButton = document.getElementById('#openMenuButton'); const resultBox = document.getElementById('resultBox'); calculateResultsButton.addEventListener('click', (e) => {     // "    -, ,   ,     //   DOM   ?"     const result = performLongRunningCalculation();     resultBox.innerText = result; }); openMenuButton.addEventListener('click', (e) => {     //      . }); 

Di sini saya memperbarui teks di lapangan setelah beberapa perhitungan selesai, mungkin panjang. Tampaknya tidak ada gunanya menjalankan kode ini di utas terpisah, karena DOM tidak memperbarui sebelum kode ini selesai. Akibatnya, tentu saja, saya memutuskan bahwa kode ini perlu dijalankan secara serempak. Namun, melihat kode seperti itu, pada awalnya saya tidak mengerti bahwa selama utas utama diblokir, pendengar acara lainnya tidak memulai. Ini berarti "rem" mulai muncul di halaman.

Cara "memperlambat" halaman

Berikut adalah proyek CodePen yang menunjukkan hal di atas.


Sebuah proyek yang menunjukkan situasi di mana halaman lambat

Menekan tombol Freeze menyebabkan aplikasi mulai menyelesaikan tugas sinkron. Semua ini membutuhkan waktu 3 detik (ini mensimulasikan kinerja perhitungan yang panjang). Jika Anda mengklik tombol Increment , kemudian sampai 3 detik berlalu, nilai dalam bidang Click Count tidak akan diperbarui. Nilai baru yang sesuai dengan jumlah klik pada Increment akan ditulis ke bidang ini hanya setelah tiga detik berlalu. Aliran utama diblokir selama jeda. Akibatnya, semua yang ada di jendela aplikasi terlihat tidak beroperasi. Antarmuka aplikasi dibekukan. Peristiwa yang muncul dalam proses "pembekuan" sedang menunggu kesempatan untuk menggunakan sumber daya dari arus utama.

Jika Anda mengeklik Freeze dan coba resize me! , lalu, sekali lagi, hingga tiga detik berlalu, ukuran bidang tidak akan berubah. Dan setelah itu, ukuran bidang, bagaimanapun, akan berubah, tetapi tidak perlu berbicara tentang "kelancaran" di antarmuka.

Pendengar acara adalah fenomena yang jauh lebih besar daripada yang terlihat pada pandangan pertama

Setiap pengguna tidak akan suka bekerja dengan situs yang berperilaku seperti yang ditunjukkan pada contoh sebelumnya. Tetapi di sini hanya beberapa acara pendengar digunakan di sini. Di dunia nyata, kita berbicara tentang skala yang sama sekali berbeda. Saya memutuskan untuk menggunakan metode getEventListeners di Chrome dan, menggunakan skrip berikut, cari tahu jumlah pendengar acara yang dilampirkan pada elemen DOM dari berbagai halaman. Script ini dapat dijalankan langsung di konsol alat pengembang. Ini dia:

 Array  .from([document, ...document.querySelectorAll('*')])  .reduce((accumulator, node) => {    let listeners = getEventListeners(node);    for (let property in listeners) {      accumulator = accumulator + listeners[property].length    }    return accumulator;  }, 0); 

Saya menjalankan skrip ini di halaman yang berbeda dan mengetahui tentang jumlah pendengar acara yang digunakan pada mereka. Hasil percobaan saya ditunjukkan pada tabel berikut.

Anda tidak dapat memperhatikan nomor-nomor tertentu. Hal utama di sini adalah bahwa kita berbicara tentang sejumlah besar pendengar acara. Akibatnya, jika setidaknya satu operasi yang berjalan lama dalam aplikasi berjalan salah, semua pendengar ini akan berhenti merespons pengaruh pengguna. Ini memberi pengembang banyak cara untuk membuat marah para pengguna aplikasi mereka.

Singkirkan "rem" dengan pekerja web

Dengan semua hal di atas, mari kita tulis ulang contoh sebelumnya. Ini versi barunya. Ini terlihat persis seperti yang lama, tetapi di dalamnya diatur secara berbeda. Yaitu, sekarang operasi yang digunakan untuk memblokir utas telah dipindahkan ke utasnya sendiri. Jika Anda melakukan hal yang sama dengan contoh ini seperti yang sebelumnya, Anda dapat melihat perbedaan positif yang serius. Yaitu, jika setelah mengklik tombol Freeze klik pada Increment , bidang Click Count akan diperbarui (setelah pekerja web selesai, dalam hal apa pun, angka 1 akan ditambahkan ke nilai Click Count ). Hal yang sama berlaku untuk resize me! . Kode yang berjalan di utas terpisah tidak memblokir pendengar acara. Ini memungkinkan semua elemen halaman untuk tetap beroperasi bahkan selama pelaksanaan operasi yang sebelumnya hanya "membeku" halaman.

Berikut adalah kode JS untuk contoh ini:

 const button1 = document.getElementById('button1'); const button2 = document.getElementById('button2'); const count = document.getElementById('count'); const workerScript = `  function pause(ms) {    let time = new Date();    while ((new Date()) - time <= ms) {}               }  self.onmessage = function(e) {    pause(e.data);    self.postMessage('Process complete!');  } `; const blob = new Blob([  workerScript, ], {type: "text/javascipt"}); const worker = new Worker(window.URL.createObjectURL(blob)); const bumpCount = () => {  count.innerText = Number(count.innerText) + 1; } worker.onmessage = function(e) {  console.log(e.data);  bumpCount(); } button1.addEventListener('click', async function () {  worker.postMessage(3000); }); button2.addEventListener('click', function () {  bumpCount(); }); 

Jika Anda mempelajari sedikit kode ini, Anda akan memperhatikan bahwa, meskipun Web Workers API dapat diatur dan lebih nyaman, tidak ada yang sangat menakutkan dalam bekerja dengannya. Kode ini mungkin terlihat menyeramkan karena fakta bahwa ini adalah demo sederhana yang ditulis dengan cepat. Untuk meningkatkan kegunaan API dan membuatnya lebih mudah untuk bekerja dengan pekerja web, Anda dapat menggunakan beberapa alat tambahan. Misalnya, berikut ini sepertinya menarik bagi saya:

• Workerize - memungkinkan Anda menjalankan modul di pekerja web.
• Greenlet - memungkinkan untuk mengeksekusi potongan kode asinkron yang sewenang-wenang pada pekerja web.
• Comlink - menyediakan lapisan abstraksi yang nyaman di atas API Pekerja Web.

Ringkasan

Jika aplikasi web Anda adalah proyek modern yang khas, itu berarti sangat mungkin memiliki banyak pendengar acara. Mungkin juga, di utas utama, melakukan banyak perhitungan, yang bisa dilakukan di utas lain. Sebagai hasilnya, Anda dapat memberikan layanan yang baik untuk pengguna dan pendengar acara, mempercayakan perhitungan "berat" kepada pekerja web.

Perlu dicatat bahwa antusiasme yang berlebihan untuk pekerja web dan penghapusan segala sesuatu yang tidak terkait langsung dengan antarmuka pengguna dengan pekerja web mungkin bukan ide terbaik. Pemrosesan aplikasi semacam itu mungkin memerlukan banyak waktu dan usaha, kode proyek akan menjadi lebih rumit, dan manfaat dari konversi semacam itu akan sangat kecil. Sebagai gantinya, mungkin layak memulai dengan mencari kode yang benar-benar “berat” dan membawanya ke pekerja web. Seiring waktu, ide menggunakan pekerja web akan menjadi lebih akrab, dan Anda mungkin akan dipandu olehnya bahkan pada tahap desain antarmuka.

Namun, saya sarankan Anda memahami API Pekerja Web. Teknologi ini menikmati dukungan browser yang sangat luas, dan persyaratan kinerja aplikasi web modern semakin berkembang. Karenanya, kami tidak punya alasan untuk menolak mempelajari alat seperti pekerja web.

Pembaca yang budiman! Apakah Anda menggunakan pekerja web dalam proyek Anda?