मुझे बताइए कि जब आप किसी click handler के अंदर await करते हैं, तो event loop में असल में क्या होता है।

handler तब तक synchronously चलता है जब तक await नहीं आता, फिर वह कंट्रोल ब्राउज़र को लौटा देता है और बाकी function को microtask की तरह schedule कर देता है। जिस promise का इंतज़ार था वह निपटते ही, वह continuation microtask queue में जाता है, जो मौजूदा task के बाद और अगले timer या paint से पहले पूरी तरह खाली होती है। तो await कभी main thread नहीं रोकता; वह function को दो हिस्सों में बांट देता है।

ज़रूर। handler किसी भी दूसरे function की तरह main thread पर शुरू होता है, और पहले await तक सब कुछ synchronously चलता है। await पर function रुक जाता है और अपने caller को एक promise लौटा देता है, तो ब्राउज़र को thread वापस मिल जाता है और वह paint कर सकता है। जिस promise का इंतज़ार था वह resolve होने पर function का बाकी हिस्सा microtask queue में धकेला जाता है, task queue में नहीं। यह इसलिए मायने रखता है कि ब्राउज़र के अगला timer या अगला frame लेने से पहले microtasks पूरी तरह निपटते हैं, तो promise resolutions की लंबी कड़ी तकनीकी रूप से कुछ synchronous न होते हुए भी rendering रोक सकती है। इसका व्यावहारिक रूप मुझे एक dashboard पर काटा। हम करीब 300 rows पर for loop के अंदर await कर रहे थे, तो हर request अपने से पहले वाली का इंतज़ार करती थी और पेज भरने में 12 सेकंड लगते थे। एक छोटी concurrency सीमा के साथ Promise.all पर जाने से यह एक सेकंड से नीचे आ गया। वही कोड, वही thread, बिल्कुल अलग बर्ताव।