ওয়েব কম্পোনেন্ট ওরিয়েন্টেশন

ওয়েব কম্পোনেন্ট হল কাস্টম এলিমেন্ট, Shadow DOM এবং HTML টেমপ্লেট: এগুলি হল প্ল্যাটফর্ম প্রিমিটিভ যা আবার ব্যবহার করা যায়, ফ্রেমওয়ার্ক-অ্যাগনস্টিক কম্পোনেন্ট যার মার্কআপ ও স্টাইল ডকুমেন্ট থেকে এনক্যাপসুলেট করা হয়। ডিজাইন সিস্টেম, এম্বেড করা যায় এমন উইজেট ও সেল্ফ-কন্টেনড UI-এর জন্য এগুলি ব্যবহার করুন।

নিচে উল্লেখ করা নিয়মগুলি ক্রস-কাটিং। হাতে থাকা টাস্কের জন্য নির্দিষ্ট গাইড খুঁজে নিন; প্রতিটি গাইড তার প্রয়োজনীয় কন্টেক্সট আবার উল্লেখ করে এবং এর জন্য অনন্য API ও সম্ভাব্য সমস্যা ডকুমেন্ট করে।

আপনার আদৌ কোনও কাস্টম এলিমেন্ট প্রয়োজন কিনা তা ঠিক করুন

কোনও ট্যাগে এনক্যাপসুলেটেড আচরণ, লাইফসাইকেল বা আবার ব্যবহারযোগ্য JS-ব্যাকড API-এর প্রয়োজন হলে তবেই কাস্টম এলিমেন্ট ব্যবহার করুন। এইসব ক্ষেত্রে তৈরি করবেন না:

• CSS সহ একটি সাধারণ HTML এলিমেন্টই যথেষ্ট। একটি স্টাইল করা <button> বা <details> আরও অ্যাক্সেসযোগ্য এবং পুনরায় প্রয়োগ করার চেয়ে সস্তা।
• জিনিসটি শুধুমাত্র উপস্থাপনার জন্য, এর কোনও আচরণ নেই। নেটিভ এলিমেন্টের ক্লাস আরও বেশি পারফর্ম করে এবং @layer বা @scope-এর মাধ্যমে স্কোপ করা যায়।
• কোনও ইন্টার‍্যাক্টিভিটি ছাড়াই সার্ভারে আপনার শুধু স্টাইল স্কোপিং প্রয়োজন; একটি স্কোপড স্টাইলশিট বা ডিক্লারেটিভ শ্যাডো DOM (আপগ্রেড ছাড়াই) যথেষ্ট হতে পারে।

নেটিভ সিম্যান্টিকস (একটি কাস্টম <my-button> যা ফোকাস, অ্যাক্টিভেশন এবং ARIA পুনরায় তৈরি করে) পুনর্নির্মাণ করা হল সবচেয়ে সাধারণ অপব্যবহার: আপনি প্ল্যাটফর্মের অ্যাক্সেসিবিলিটি বিনামূল্যে তখনই পাবেন যদি আপনি নেটিভ এলিমেন্ট পুনরায় ব্যবহার করেন। যখন <my-button>-স্টাইল র‍্যাপার প্রয়োজন হয় — সাধারণত শেয়ার করা স্টাইলিং হুক, অতিরিক্ত মার্কআপ বা নেটিভ এলিমেন্ট প্রকাশ করতে পারে না এমন আচরণের জন্য — আসল <button>-কে আবার প্রয়োগ করার পরিবর্তে র‍্যাপ করুন (অভ্যন্তরীণ নেটিভ এলিমেন্টে স্টাইল ফরওয়ার্ড করার জন্য ওয়েব কম্পোনেন্ট স্টাইল করা দেখুন)।

পরীক্ষাটি হল আপনার এনক্যাপসুলেটেড স্টেট, স্ক্রিপ্ট করা যায় এমন API বা নেটিভ এলিমেন্ট প্রকাশ করতে পারে না এমন আচরণ প্রয়োজন কিনা — শুধুমাত্র একটি ভিন্ন লুক নয়। একটি লাইক/পছন্দের টগল উপযুক্ত: এটি ল্যাচ করা ডোমেন স্টেট বহন করে, আশেপাশের পৃষ্ঠার জন্য একটি স্টাইলিং হুক হিসাবে সেই স্টেটটি প্রকাশ করে এবং নিজস্ব change ইভেন্ট পাঠায় — যার কোনওটিই স্টাইল করা <button> আপনাকে দেয় না। একটি বোতাম যা শুধুমাত্র প্রেস করা হলে রঙ পরিবর্তন করে, তা করে না: <button> + CSS-এর জন্য পৌঁছান। আপনি এটি তৈরি করার সময়, উপযুক্ত কাস্টম স্টেট বা অ্যাট্রিবিউট দিয়ে এর স্টেট মডেল করুন (কাস্টম এলিমেন্ট দেখুন)।

কোডবেসের সাথে টুলটি ম্যাচ করুন

কোনও কিছু কাস্টম এলিমেন্ট হওয়া উচিত কিনা তা নির্ভর করে প্রোজেক্টে আগে থেকে কী ব্যবহার করা হচ্ছে তার উপর। এজেন্টরা খুব বেশি অ্যাবস্ট্রাক্ট করে এবং খুব আগ্রহের সাথে নতুন এলিমেন্ট ব্যবহার করতে চায় — সন্দেহ হলে, হালকা বিকল্প (নেটিভ এলিমেন্ট, CSS, সার্ভার টেমপ্লেট) সাধারণত সঠিক হয় এবং পরে যদি আবার ব্যবহার বা আচরণের জন্য প্রয়োজন হয়, তাহলে আপনি কাস্টম এলিমেন্টে প্রোমোট করতে পারেন। হিউরিস্টিকস, মোটামুটি অগ্রাধিকারের ভিত্তিতে:

• কোডবেসে আগে থেকেই একটি কম্পোনেন্ট মডেল (React, Vue, Svelte, …) আছে। ইন-অ্যাপ UI-এর জন্য সেই ফ্রেমওয়ার্কের কম্পোনেন্ট ডিফল্ট হিসেবে সেট করুন। কাস্টম এলিমেন্ট তখনই ব্যবহার করুন যখন কোনও কিছুকে ফ্রেমওয়ার্ক থেকে এড়িয়ে যেতে বা তার বাইরে থাকতে হবে: অ্যাপ বা ফ্রেমওয়ার্ক জুড়ে শেয়ার করা ডিজাইন-সিস্টেম প্রিমিটিভ, ফ্রেমওয়ার্ক কন্ট্রোল করে না এমন মার্কআপে ড্রপ করা উইজেট অথবা প্লেইন HTML (ইমেল, CMS, SSR ফ্র্যাগমেন্ট) হিসেবে কাজ করতে হবে এমন আউটপুট। সাধারণ ইন-অ্যাপ ভিউয়ের জন্য সমান্তরাল কম্পোনেন্ট সিস্টেম তৈরি করবেন না।
• কোনও টুলিং নেই, বেশিরভাগই স্ট্যাটিক মার্কআপ। প্লেন HTML + CSS বা সার্ভার টেমপ্লেট/আংশিক টেমপ্লেট ব্যবহার করো। একটি কাস্টম এলিমেন্ট শুধুমাত্র তখনই তার উপযোগিতা প্রমাণ করে যখন আপনার ট্যাগে সত্যিই আচরণ, লাইফসাইকেল বা JS-ব্যাকড API-এর প্রয়োজন হয় — শুধু মার্কআপ শেয়ার করার জন্য নয়, যা একটি সার্ভার অন্তর্ভুক্ত করে বা <template> কোনও JS শিপিং ছাড়াই করে।
• ইন্টারঅ্যাক্টিভিটির আইল্যান্ড সহ স্ট্যাটিক সাইট জেনারেটর। মার্কআপ স্ট্যাটিক্যালি রেন্ডার করুন; ইন্টার‍্যাক্টিভ অংশের জন্য কাস্টম এলিমেন্ট রিজার্ভ করুন। "অনেক মার্কআপ, অল্প ইন্টার‍্যাক্টিভিটি"র জন্য, মার্কআপকে লাইট DOM (বা ডিক্লেরেটিভ শ্যাডো DOM)-এ রাখুন এবং JS থেকে সবকিছু আবার রেন্ডার করার পরিবর্তে একটি ছোট কাস্টম এলিমেন্টকে প্রোগ্রেসিভ এনহ্যান্সমেন্ট করতে দিন।
• এর পরিবর্তে আপনি বিল্ট-ইন এলিমেন্ট আরও পুশ করতে পারেন। নেটিভ এলিমেন্টকে যতটা সম্ভব ব্যবহার করা (CSS, কিছু লিসেনার, মাঝে মাঝে ছদ্ম-এলিমেন্ট) সাধারণত কাস্টম এলিমেন্টের চেয়ে বেশি পছন্দনীয়, কারণ আপনি প্ল্যাটফর্মের অ্যাক্সেসিবিলিটি এবং আচরণ বিনামূল্যে পান। ওয়ার্কঅ্যারাউন্ড আর বজায় রাখা না গেলে, কাস্টম এলিমেন্টে চলে যান — যখন আপনাকে এলিমেন্টের বিল্ট-ইন আচরণের সাথে লড়াই করতে হবে অথবা অথরিং অভিজ্ঞতা ক্লিন কম্পোনেন্ট API-এর থেকে খারাপ হয়ে যাবে। বিল্ট-ইন এলিমেন্টে সামান্য JS প্রয়োজন হলে, শুধু সেই কারণে সেটি পরিবর্তন করার প্রয়োজন নেই।

ক্রস-কাটিং নিয়ম

নিচে উল্লেখ করা প্রতিটি গাইডের ক্ষেত্রে এগুলি প্রযোজ্য:

• বাধ্যতামূলক: ট্যাগের নাম অবশ্যই কাবাব কেস হতে হবে এবং কমপক্ষে একটি হাইফেন (যেমন my-element) থাকতে হবে। এটি বর্তমান এবং ভবিষ্যতের বিল্ট-ইন থেকে কাস্টম এলিমেন্টকে আলাদা করে।
• বাধ্যতামূলক: this-কে স্পর্শ করার আগে, কনস্ট্রাক্টরে প্রথমে super()-কে কল করুন; this থ্রো রিড বা রাইট করে এমন যেকোনও স্টেটমেন্টের পরে এটিকে কল করা।
• বাধ্যতামূলক: শ্যাডো টেমপ্লেটের মধ্যে সিম্যান্টিক এলিমেন্ট (<button>, <nav>, <ul>) ব্যবহার করুন। শ্যাডো ট্রিতে বেশিরভাগ অ্যাক্সেসিবিলিটি সংক্রান্ত সমস্যা নন-সিম্যান্টিক মার্ক-আপের কারণে হয়; কোনও স্লট তার প্রোজেক্টের ভূমিকা পরিবর্তন করে না।
• বাধ্যতামূলক: ARIA id রেফারেন্স (aria-labelledby, aria-describedby, aria-controls) শ্যাডো বাউন্ডারি ক্রস করতে পারে না; রেফারেন্সিং এলিমেন্ট এবং এটি যে id-কে পয়েন্ট করে তা একই ট্রিতে থাকতে হবে।
• attachShadow({ mode: 'open' })-কে অগ্রাধিকার দিন যাতে ডেভ টুল, পৃষ্ঠা স্ক্রিপ্ট এবং সার্ভার হাইড্রেশন element.shadowRoot-এ পৌঁছাতে পারে। পৃষ্ঠার স্ক্রিপ্ট থেকে ইন্টার্নাল স্ট্রাকচার লুকানোর প্রয়োজন হলে তবেই 'closed' ব্যবহার করুন।
• কাস্টমাইজ করা বিল্ট-ইন এলিমেন্ট (is="…" সহ extends HTMLButtonElement) এড়িয়ে চলুন; Safari এগুলি শিপ করার জন্য স্থায়ীভাবে প্রত্যাখ্যান করেছে।

ব্যবহারের উদাহরণ সংক্রান্ত নির্দেশিকা ম্যাট্রিক্স

টাস্ক শনাক্ত করে এর নির্দেশিকা ফিরিয়ে আনুন: