আমি j20000 এর উত্তরে কিছু মন্তব্য এবং জবাবদিহি যুক্ত করতে চাই। (বেশিরভাগই আমার অন্ত্র অনুভূতির উপর ভিত্তি করে আমার মতামত)
না - আপনার সমস্ত প্রতিনিধি ইভেন্ট হ্যান্ডলারদের ডকুমেন্ট অবজেক্টে আবদ্ধ করা উচিত নয়। এটি সম্ভবত আপনি তৈরি করতে পারেন সবচেয়ে খারাপ পারফরম্যান্স।
প্রথমত, ইভেন্ট প্রতিনিধি সবসময় আপনার কোডটি দ্রুত করে না। কিছু ক্ষেত্রে, এটি সুবিধাজনক এবং কিছু ক্ষেত্রে না। আপনার যখন ইভেন্টের প্রতিনিধি প্রয়োজন আসলে এবং আপনি যখন এতে উপকৃত হন তখন আপনার ইভেন্ট প্রতিনিধি ব্যবহার করা উচিত। অন্যথায়, ইভেন্ট হ্যান্ডলারগুলিকে সরাসরি অবজেক্টগুলিতে আবদ্ধ করা উচিত যেখানে ইভেন্টটি ঘটে কারণ এটি সাধারণত আরও কার্যকর হবে।
যদিও এটি সত্য যে আপনি কেবলমাত্র একটি একক উপাদানের জন্য নিবন্ধকরণ এবং ইভেন্ট করতে যাচ্ছেন পারফরম্যান্স কিছুটা ভাল হতে পারে, আমি বিশ্বাস করি প্রতিনিধিরা যে পরিমাণ স্কেলিবিলিটি সুবিধা নিয়ে আসে তার বিপরীতে এটি ভারসাম্যপূর্ণ হয় না। আমি আরও বিশ্বাস করি যে ব্রাউজারগুলি এটিকে আরও বেশি দক্ষতার সাথে পরিচালনা করছে (যদিও আমার কাছে এর কোনও প্রমাণ নেই)। আমার মতে, ইভেন্ট প্রতিনিধিদলই যাওয়ার উপায়!
দ্বিতীয়বার, ডকুমেন্ট স্তরে আপনার সমস্ত প্রতিনিধি ইভেন্টগুলিকে আবদ্ধ করা উচিত নয়। ঠিক এই কারণেই। লাইভ () অবমূল্যায়ন করা হয়েছিল কারণ আপনার যখন প্রচুর ইভেন্টে এইভাবে আবদ্ধ থাকে তখন এটি অত্যন্ত অযোগ্য। প্রতিনিধি ইভেন্ট হ্যান্ডলিংয়ের জন্য এগুলি গতিশীল নয় এমন নিকটতম পিতামাতার সাথে আবদ্ধ করা আরও দক্ষ।
আমি এই বিষয়ে একমত। আপনি যদি 100% নিশ্চিত হন যে কোনও ইভেন্ট কেবল একটি ধারকের ভিতরেই ঘটবে, তবে ইভেন্টটি এই ধারকটির সাথে আবদ্ধ করা বুদ্ধিমান হয়ে যায় তবে আমি এখনও সরাসরি ট্রিগার উপাদানটির সাথে বাঁধার ঘটনাগুলির বিরুদ্ধে তর্ক করব।
তৃতীয় কথা, সমস্ত ইভেন্ট কাজ করে না বা সমস্ত সমস্যা প্রতিনিধি দলের মাধ্যমে সমাধান করা যায় না। উদাহরণস্বরূপ, আপনি যদি কোনও ইনপুট নিয়ন্ত্রণে কী ইভেন্টগুলিকে আটকে রাখতে চান এবং ইনপুট নিয়ন্ত্রণে অবৈধ কীগুলি প্রবেশ করতে আটকাতে চান, তবে আপনি প্রতিনিধি ইভেন্ট হ্যান্ডলিং দিয়ে এটি করতে পারবেন না কারণ সময়টি ইভেন্টটি হস্তান্তরিত হ্যান্ডলারের উপর বুদবুদ হয়ে যায়, এটি ইতিমধ্যে হয়ে গেছে has ইনপুট নিয়ন্ত্রণ দ্বারা প্রক্রিয়াভুক্ত হয়েছে এবং এই আচরণটি প্রভাবিত করতে খুব দেরী হয়েছে।
এই কেবল সত্য নয়। দয়া করে এই কোডপেনটি দেখুন: https://codepen.io/pwkip/pen/jObGmjq
document.addEventListener('keypress', (e) => {
e.preventDefault();
});
এটি ডকুমেন্টটিতে কীপ্রেস ইভেন্টটি নিবন্ধভুক্ত করে আপনি কীভাবে কোনও ব্যবহারকারীকে টাইপ করা থেকে বিরত রাখতে পারবেন তা চিত্রিত করে।
ইভেন্টের প্রতিনিধি প্রয়োজন বা সুবিধাজনক যখন এখানে আসে:
আপনি যে বিষয়গুলিতে ইভেন্টগুলি ক্যাপচার করছেন সেগুলি যখন গতিশীলভাবে তৈরি / সরিয়ে ফেলা হয় এবং আপনি এখনও যখন কোনও নতুন তৈরি করেন তখন ইভেন্ট হ্যান্ডলারগুলিকে স্পষ্টতই পুনরায় প্রত্যাবর্তন না করে আপনি সেগুলিতে ইভেন্টগুলি ক্যাপচার করতে চান। যখন আপনার কাছে প্রচুর অবজেক্ট থাকে যা সকলেই একই ঘটনা ইভেন্ট হ্যান্ডলার চায় (যেখানে প্রচুর পরিমাণ কমপক্ষে শত শত হয়)। এই ক্ষেত্রে, শত বা ততোধিক সরাসরি ইভেন্ট হ্যান্ডলারের পরিবর্তে কোনও প্রতিনিধি ইভেন্ট হ্যান্ডলারকে আবদ্ধ করার জন্য সেটআপের সময় এটি আরও কার্যকর it দ্রষ্টব্য, প্রতিনিধি ইভেন্ট হ্যান্ডলিং সরাসরি ইভেন্ট হ্যান্ডলারের তুলনায় রান-টাইমে সর্বদা কম দক্ষ।
আমি এই উদ্ধৃতিটির সাথে https: //ehsang বাজার.com/optimizing-javascript-event-listeners-for-performance-e28406ad406c থেকে উত্তর দিতে চাই
Event delegation promotes binding as few DOM event handlers as possible, since each event handler requires memory. For example, let’s say that we have an HTML unordered list we want to bind event handlers to. Instead of binding a click event handler for each list item (which may be hundreds for all we know), we bind one click handler to the parent unordered list itself.
এছাড়াও, performance cost of event delegation googleইভেন্ট প্রতিনিধিদের পক্ষে আরও ফলাফলের জন্য গুগলিং করা ।
যখন আপনি দস্তাবেজের কোনও উপাদানগুলিতে ঘটে যাওয়া ইভেন্টগুলি (আপনার দস্তাবেজের একটি উচ্চ স্তরে) ক্যাপচার করার চেষ্টা করছেন। যখন আপনার ডিজাইনটি আপনার পৃষ্ঠায় কিছু সমস্যা বা বৈশিষ্ট্য সমাধান করতে স্পষ্টভাবে ইভেন্ট বুদবুদ এবং স্টপপ্রোপেশন () ব্যবহার করছে। এটি আরও কিছুটা বোঝার জন্য, একজনকে বুঝতে হবে কীভাবে jQuery ডেলিগেট ইভেন্ট হ্যান্ডলারগুলি কাজ করে। আপনি যখন এই জাতীয় কিছু কল করবেন:
$ ("# আমার পিতা") on ('ক্লিক করুন', 'বাটন.অ্যাকশনবটন', মাইএফএন); এটি # মাই প্যারেন্ট অবজেক্টে জেনেরিক জিকুয়ের ইভেন্ট ইভেন্ট হ্যান্ডলার ইনস্টল করে। যখন কোনও ক্লিক ইভেন্টটি এই প্রতিনিধি ইভেন্ট হ্যান্ডলারের উপর বুদবুদ হয়ে থাকে, তখন jQuery কে এই অবজেক্টের সাথে সংযুক্ত প্রতিনিধি ইভেন্ট হ্যান্ডলারগুলির তালিকাটি দেখতে হবে এবং নির্ধারিত ইভেন্ট হ্যান্ডলারের কোনও নির্বাচকের সাথে ইভেন্টটির উত্স উপাদানটি মিলবে কিনা তা দেখতে হবে।
যেহেতু নির্বাচকগুলি মোটামুটিভাবে জড়িত হতে পারে, এর অর্থ এই যে jQuery কে প্রতিটি নির্বাচককে বিশ্লেষণ করতে হবে এবং তারপরে এটি প্রতিটি নির্বাচকের সাথে মেলে কিনা তা দেখার জন্য এটি ইভেন্টের মূল লক্ষ্যটির বৈশিষ্ট্যের সাথে তুলনা করতে হবে। এটি কোনও সস্তা অপারেশন নয়। তাদের মধ্যে যদি কেবলমাত্র একটি থাকে তবে এটি কোনও বড় বিষয় নয়, তবে আপনি যদি সমস্ত নির্বাচককে নথির অবজেক্টে রেখে দেন এবং প্রতিটি বুদবুদ ইভেন্টের সাথে তুলনা করার জন্য কয়েকশ নির্বাচক থাকেন তবে এটি গুরুত্ব সহকারে ইভেন্ট হ্যান্ডলিংয়ের পারফরম্যান্সকে নিমজ্জিত করতে পারে।
এই কারণে, আপনি আপনার প্রতিনিধি ইভেন্ট হ্যান্ডলারগুলি সেট আপ করতে চান যাতে কোনও প্রতিনিধি ইভেন্ট হ্যান্ডলারটি ব্যবহারিক হিসাবে যতটা টার্গেট অবজেক্টের কাছাকাছি থাকে। এর অর্থ হ'ল প্রতিটি প্রতিনিধি ইভেন্ট হ্যান্ডলারের মাধ্যমে কম ইভেন্টগুলি বুদবুদ হবে, এইভাবে কর্মক্ষমতা উন্নত করবে। নথি অবজেক্টে সমস্ত প্রতিনিধি ইভেন্ট স্থাপন করা সবচেয়ে খারাপ সম্ভাব্য পারফরম্যান্স কারণ সমস্ত বুদ্বুদ্বিত ইভেন্টগুলি সমস্ত প্রতিনিধি ইভেন্ট হ্যান্ডলারের মধ্য দিয়ে যেতে হয় এবং সমস্ত সম্ভাব্য প্রতিনিধি ইভেন্ট নির্বাচকদের বিরুদ্ধে মূল্যায়ন করতে হয়। ঠিক এই কারণেই। লাইভ () অবমূল্যায়ন করা হয়েছে কারণ এটিই ছিল। লাইভ () যা করেছে এবং এটি অত্যন্ত অযোগ্য হিসাবে প্রমাণিত হয়েছে।
এই নথি কোথায়? যদি এটি সত্য হয়, তবে jQuery মনে হয় খুব অদক্ষ উপায়ে প্রতিনিধিদের পরিচালনা করছে এবং তারপরে আমার পাল্টা যুক্তিগুলি কেবল ভ্যানিলা জেএস-এ প্রয়োগ করা উচিত।
তবুও: আমি এই দাবিকে সমর্থন করে একটি সরকারী উত্স খুঁজে পেতে চাই।
:: সম্পাদনা ::
দেখে মনে হচ্ছে jQuery সত্যিই খুব অদক্ষ উপায়ে ইভেন্ট বুদবুদ করছে (কারণ তারা IE8 সমর্থন করে)
https://api.jquery.com/on/#event-performance
সুতরাং এখানে আমার বেশিরভাগ যুক্তি কেবল ভ্যানিলা জেএস এবং আধুনিক ব্রাউজারগুলির জন্যই সত্য।