React-এর useId হুক: স্থিতিশীল এবং অনন্য শনাক্তকারী তৈরির একটি গভীর পর্যালোচনা

ওয়েব ডেভেলপমেন্টের সদা পরিবর্তনশীল জগতে, সার্ভার-রেন্ডার করা কন্টেন্ট এবং ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনের মধ্যে সামঞ্জস্য নিশ্চিত করা অত্যন্ত গুরুত্বপূর্ণ। ডেভেলপাররা বহু বছর ধরে যে সবচেয়ে স্থায়ী এবং সূক্ষ্ম চ্যালেঞ্জগুলোর মুখোমুখি হয়েছেন তার মধ্যে একটি হলো অনন্য, স্থিতিশীল শনাক্তকারী তৈরি করা। এই আইডিগুলো লেবেলকে ইনপুটের সাথে সংযুক্ত করতে, অ্যাক্সেসিবিলিটির জন্য ARIA অ্যাট্রিবিউট পরিচালনা করতে এবং অন্যান্য অনেক DOM-সম্পর্কিত কাজের জন্য অপরিহার্য। বছরের পর বছর ধরে, ডেভেলপাররা এমন কিছু সমাধান ব্যবহার করেছেন যা আদর্শ ছিল না, যার ফলে প্রায়শই হাইড্রেশন মিসম্যাচ এবং হতাশাজনক বাগ দেখা যেত। এই সমস্যার একটি চমৎকার এবং চূড়ান্ত সমাধান হিসেবে এসেছে React 18-এর `useId` হুক—একটি সহজ কিন্তু শক্তিশালী টুল।

এই বিশদ নির্দেশিকাটি বিশ্বব্যাপী React ডেভেলপারদের জন্য। আপনি একটি সাধারণ ক্লায়েন্ট-রেন্ডার করা অ্যাপ্লিকেশন তৈরি করুন, Next.js-এর মতো ফ্রেমওয়ার্ক দিয়ে একটি জটিল সার্ভার-সাইড রেন্ডারড (SSR) অভিজ্ঞতা তৈরি করুন, বা সারা বিশ্বের ব্যবহারের জন্য একটি কম্পোনেন্ট লাইব্রেরি লিখুন না কেন, `useId` বোঝা এখন আর ঐচ্ছিক নয়। এটি আধুনিক, শক্তিশালী এবং অ্যাক্সেসিবল React অ্যাপ্লিকেশন তৈরির একটি মৌলিক টুল।

`useId`-এর আগের সমস্যা: হাইড্রেশন মিসম্যাচের দুনিয়া

`useId`-কে সত্যিই উপলব্ধি করতে হলে, আমাদের প্রথমে এটি ছাড়া দুনিয়াটা কেমন ছিল তা বুঝতে হবে। মূল সমস্যাটি সবসময়ই ছিল এমন একটি আইডি-র প্রয়োজন যা রেন্ডার করা পেজের মধ্যে অনন্য এবং একই সাথে সার্ভার ও ক্লায়েন্টের মধ্যে সামঞ্জস্যপূর্ণ।

একটি সাধারণ ফর্ম ইনপুট কম্পোনেন্টের কথা ভাবুন:

function LabeledInput({ label, ...props }) {
  // আমরা এখানে কীভাবে একটি ইউনিক আইডি তৈরি করব?
  const inputId = 'some-unique-id';

  return (
    

      {label}
      
    
  );
}

সিমেন্টিক HTML এবং অ্যাক্সেসিবিলিটির জন্য ``-এর `htmlFor` অ্যাট্রিবিউটকে ``-এর `id`-এর সাথে মিলতে হবে। যদি আমরা এই `LabeledInput` কম্পোনেন্টটি একটি পেজে একাধিকবার ব্যবহার করি, তবে প্রতিটি ইনস্ট্যান্সের জন্য আমাদের একটি ভিন্ন আইডি প্রয়োজন।

প্রথম চেষ্টা: `Math.random()` ব্যবহার করা

একটি ইউনিক আইডি তৈরির জন্য প্রথম যে চিন্তাটি মাথায় আসে তা হলো র‍্যান্ডমনেস (randomness) ব্যবহার করা।

// অ্যান্টি-প্যাটার্ন: এটা করবেন না!
const inputId = `input-${Math.random()}`;

এটি কেন ব্যর্থ হয়:

• SSR মিসম্যাচ: সার্ভার একটি র‍্যান্ডম নম্বর তৈরি করবে (যেমন, `input-0.12345`)। যখন ক্লায়েন্ট অ্যাপ্লিকেশনটি হাইড্রেট করবে, তখন এটি জাভাস্ক্রিপ্ট পুনরায় চালাবে এবং একটি ভিন্ন র‍্যান্ডম নম্বর তৈরি করবে (যেমন, `input-0.67890`)। React সার্ভার HTML এবং ক্লায়েন্ট-রেন্ডার করা HTML-এর মধ্যে এই অমিলটি দেখবে এবং একটি হাইড্রেশন এরর দেবে।
• রি-রেন্ডার: কম্পোনেন্টের প্রতিটি রি-রেন্ডারে এই আইডি পরিবর্তন হবে, যা অপ্রত্যাশিত আচরণ এবং পারফরম্যান্স সমস্যা তৈরি করতে পারে।

দ্বিতীয় চেষ্টা: একটি গ্লোবাল কাউন্টার ব্যবহার করা

আরেকটু উন্নত পদ্ধতি হলো একটি সাধারণ ইনক্রিমেন্টিং কাউন্টার ব্যবহার করা।

// অ্যান্টি-প্যাটার্ন: এটিও সমস্যাজনক
let globalCounter = 0;
function generateId() {
  globalCounter++;
  return `component-${globalCounter}`;
}

এটি কেন ব্যর্থ হয়:

• SSR অর্ডার নির্ভরতা: প্রথমে এটি কাজ করছে বলে মনে হতে পারে। সার্ভার একটি নির্দিষ্ট ক্রমে কম্পোনেন্ট রেন্ডার করে এবং ক্লায়েন্ট সেগুলোকে হাইড্রেট করে। কিন্তু যদি সার্ভার এবং ক্লায়েন্টের মধ্যে কম্পোনেন্ট রেন্ডারিংয়ের ক্রম সামান্য ভিন্ন হয়? কোড স্প্লিটিং বা আউট-অফ-অর্ডার স্ট্রিমিংয়ের ক্ষেত্রে এটি ঘটতে পারে। যদি একটি কম্পোনেন্ট সার্ভারে রেন্ডার হয় কিন্তু ক্লায়েন্টে দেরিতে আসে, তাহলে জেনারেট করা আইডিগুলোর ক্রম অসামঞ্জস্যপূর্ণ হয়ে যেতে পারে, যা আবারও হাইড্রেশন মিসম্যাচের কারণ হয়।
• কম্পোনেন্ট লাইব্রেরির সমস্যা: আপনি যদি একজন লাইব্রেরি লেখক হন, তবে আপনার কোনো নিয়ন্ত্রণ নেই যে পেজের অন্যান্য কতগুলো কম্পোনেন্ট তাদের নিজস্ব গ্লোবাল কাউন্টার ব্যবহার করছে। এটি আপনার লাইব্রেরি এবং হোস্ট অ্যাপ্লিকেশনের মধ্যে আইডি সংঘর্ষের কারণ হতে পারে।

এই চ্যালেঞ্জগুলো একটি React-নেটিভ, ডিটারমিনিস্টিক সমাধানের প্রয়োজনীয়তা তুলে ধরেছিল যা কম্পোনেন্ট ট্রি-এর কাঠামো বুঝতে পারে। `useId` ঠিক সেটাই সরবরাহ করে।

`useId`-এর পরিচিতি: অফিসিয়াল সমাধান

`useId` হুক একটি অনন্য স্ট্রিং আইডি তৈরি করে যা সার্ভার এবং ক্লায়েন্ট উভয় রেন্ডারেই স্থিতিশীল থাকে। এটি আপনার কম্পোনেন্টের টপ লেভেলে কল করার জন্য ডিজাইন করা হয়েছে, যাতে অ্যাক্সেসিবিলিটি অ্যাট্রিবিউটে পাস করার জন্য আইডি তৈরি করা যায়।

মূল সিনট্যাক্স এবং ব্যবহার

এর সিনট্যাক্স খুবই সহজ। এটি কোনো আর্গুমেন্ট নেয় না এবং একটি স্ট্রিং আইডি রিটার্ন করে।

import { useId } from 'react';

function LabeledInput({ label, ...props }) {
  // useId() একটি ইউনিক, স্থিতিশীল আইডি তৈরি করে যেমন ":r0:"
  const id = useId();

  return (
    

      {label}
      
    
  );
}

// উদাহরণস্বরূপ ব্যবহার
function App() {
  return (
    

      
Sign Up Form
      
      
    
  );}

এই উদাহরণে, প্রথম `LabeledInput` হয়তো `":r0:"` এর মতো একটি আইডি পাবে, এবং দ্বিতীয়টি হয়তো `":r1:"` পাবে। আইডি-র সঠিক ফরম্যাটটি React-এর একটি অভ্যন্তরীণ বিষয় এবং এর উপর নির্ভর করা উচিত নয়। একমাত্র গ্যারান্টি হলো এটি অনন্য এবং স্থিতিশীল হবে।

মূল কথা হলো, React নিশ্চিত করে যে সার্ভার এবং ক্লায়েন্টে একই ক্রমের আইডি তৈরি হয়, যা জেনারেটেড আইডি-সম্পর্কিত হাইড্রেশন এরর সম্পূর্ণরূপে দূর করে।

এটি ধারণাগতভাবে কীভাবে কাজ করে?

`useId`-এর জাদু তার ডিটারমিনিস্টিক প্রকৃতির মধ্যে নিহিত। এটি র‍্যান্ডমনেস ব্যবহার করে না। পরিবর্তে, এটি React কম্পোনেন্ট ট্রি-এর মধ্যে কম্পোনেন্টের পাথ-এর উপর ভিত্তি করে আইডি তৈরি করে। যেহেতু সার্ভার এবং ক্লায়েন্টে কম্পোনেন্ট ট্রি-এর কাঠামো একই, তাই জেনারেট করা আইডিগুলো ম্যাচ করার গ্যারান্টি থাকে। এই পদ্ধতিটি কম্পোনেন্ট রেন্ডারিংয়ের ক্রমের প্রতি সহনশীল, যা গ্লোবাল কাউন্টার পদ্ধতির ব্যর্থতার কারণ ছিল।

একটি হুক কল থেকে একাধিক সম্পর্কিত আইডি তৈরি করা

একটি সাধারণ প্রয়োজনীয়তা হলো একটি কম্পোনেন্টের মধ্যে একাধিক সম্পর্কিত আইডি তৈরি করা। উদাহরণস্বরূপ, একটি ইনপুটের জন্য নিজের আইডি এবং `aria-describedby`-এর মাধ্যমে লিঙ্ক করা একটি বর্ণনা এলিমেন্টের জন্য আরেকটি আইডি প্রয়োজন হতে পারে।

আপনি হয়তো একাধিকবার `useId` কল করার কথা ভাবতে পারেন:

// এটি প্রস্তাবিত প্যাটার্ন নয়
const inputId = useId();
const descriptionId = useId();

যদিও এটি কাজ করে, প্রস্তাবিত প্যাটার্ন হলো প্রতি কম্পোনেন্টে একবার `useId` কল করা এবং রিটার্ন করা বেস আইডি-কে আপনার প্রয়োজনীয় অন্য যেকোনো আইডির জন্য প্রিফিক্স হিসেবে ব্যবহার করা।

import { useId } from 'react';

function FormFieldWithDescription({ label, description }) {
  const baseId = useId();
  const inputId = `${baseId}-input`;
  const descriptionId = `${baseId}-description`;

  return (
    

      {label}
      
      

        {description}
      
    
  );
}

এই প্যাটার্নটি কেন ভালো?

• দক্ষতা: এটি নিশ্চিত করে যে এই কম্পোনেন্ট ইনস্ট্যান্সের জন্য React-কে শুধুমাত্র একটি ইউনিক আইডি তৈরি এবং ট্র্যাক করতে হবে।
• স্বচ্ছতা এবং সিমেন্টিক্স: এটি এলিমেন্টগুলোর মধ্যে সম্পর্ককে স্পষ্ট করে। যে কেউ কোড পড়লেই দেখতে পাবে যে `form-field-:r2:-input` এবং `form-field-:r2:-description` একসাথে সম্পর্কিত।
• অনন্যতার গ্যারান্টি: যেহেতু `baseId` অ্যাপ্লিকেশন জুড়ে অনন্য হওয়ার গ্যারান্টিযুক্ত, তাই যেকোনো সাফিক্সযুক্ত স্ট্রিংও অনন্য হবে।

মূল বৈশিষ্ট্য: ত্রুটিহীন সার্ভার-সাইড রেন্ডারিং (SSR)

আসুন মূল সমস্যাটিতে ফিরে যাই যা সমাধান করার জন্য `useId` তৈরি করা হয়েছিল: Next.js, Remix, বা Gatsby-এর মতো SSR পরিবেশে হাইড্রেশন মিসম্যাচ।

দৃশ্যপট: হাইড্রেশন মিসম্যাচ এরর

ভাবুন একটি Next.js অ্যাপ্লিকেশনে আমাদের পুরনো `Math.random()` পদ্ধতি ব্যবহার করা একটি কম্পোনেন্ট।

1. সার্ভার রেন্ডার: সার্ভার কম্পোনেন্ট কোডটি চালায়। `Math.random()` থেকে `0.5` উৎপন্ন হয়। সার্ভার ব্রাউজারে `` সহ HTML পাঠায়।
2. ক্লায়েন্ট রেন্ডার (হাইড্রেশন): ব্রাউজার HTML এবং জাভাস্ক্রিপ্ট বান্ডেল গ্রহণ করে। React ক্লায়েন্টে চালু হয় এবং ইভেন্ট লিসেনার সংযুক্ত করার জন্য কম্পোনেন্টটি পুনরায় রেন্ডার করে (এই প্রক্রিয়াকে হাইড্রেশন বলা হয়)। এই রেন্ডারের সময়, `Math.random()` থেকে `0.9` উৎপন্ন হয়। React `` সহ একটি ভার্চুয়াল DOM তৈরি করে।
3. অমিল: React সার্ভার-জেনারেটেড HTML (`id="input-0.5"`) এবং ক্লায়েন্ট-জেনারেটেড ভার্চুয়াল DOM (`id="input-0.9"`) তুলনা করে। এটি একটি পার্থক্য দেখতে পায় এবং একটি সতর্কতা দেখায়: "Warning: Prop `id` did not match. Server: "input-0.5" Client: "input-0.9""।

এটি শুধু একটি কসমেটিক সতর্কতা নয়। এটি একটি ভাঙা UI, ভুল ইভেন্ট হ্যান্ডলিং এবং একটি খারাপ ব্যবহারকারীর অভিজ্ঞতার কারণ হতে পারে। React হয়তো সার্ভার-রেন্ডার করা HTML বাতিল করে একটি সম্পূর্ণ ক্লায়েন্ট-সাইড রেন্ডার করতে বাধ্য হতে পারে, যা SSR-এর পারফরম্যান্সের সুবিধাগুলোকে নষ্ট করে দেয়।

দৃশ্যপট: `useId` সমাধান

এখন, দেখা যাক `useId` কীভাবে এটি ঠিক করে।

1. সার্ভার রেন্ডার: সার্ভার কম্পোনেন্ট রেন্ডার করে। `useId` কল করা হয়। ট্রি-তে কম্পোনেন্টের অবস্থানের উপর ভিত্তি করে, এটি একটি স্থিতিশীল আইডি তৈরি করে, ধরা যাক `":r5:"`। সার্ভার `` সহ HTML পাঠায়।
2. ক্লায়েন্ট রেন্ডার (হাইড্রেশন): ব্রাউজার HTML এবং জাভাস্ক্রিপ্ট গ্রহণ করে। React হাইড্রেট করা শুরু করে। এটি ট্রি-তে একই অবস্থানে একই কম্পোনেন্ট রেন্ডার করে। `useId` হুক আবার চলে। যেহেতু এর ফলাফল ট্রি কাঠামোর উপর ভিত্তি করে ডিটারমিনিস্টিক, এটি ঠিক একই আইডি তৈরি করে: `":r5:"`।
3. নিখুঁত মিল: React সার্ভার-জেনারেটেড HTML (`id=":r5:"`) এবং ক্লায়েন্ট-জেনারেটেড ভার্চুয়াল DOM (`id=":r5:"`) তুলনা করে। তারা পুরোপুরি মিলে যায়। কোনো এরর ছাড়াই হাইড্রেশন সফলভাবে সম্পন্ন হয়।

এই স্থিতিশীলতাই `useId`-এর মূল্যের ভিত্তি। এটি একটি পূর্বে ভঙ্গুর প্রক্রিয়ায় নির্ভরযোগ্যতা এবং পূর্বাভাসযোগ্যতা নিয়ে আসে।

`useId`-এর মাধ্যমে অ্যাক্সেসিবিলিটি (a11y) সুপারপাওয়ার

যদিও `useId` SSR-এর জন্য অত্যন্ত গুরুত্বপূর্ণ, এর প্রধান দৈনন্দিন ব্যবহার হলো অ্যাক্সেসিবিলিটি উন্নত করা। স্ক্রিন রিডারের মতো সহায়ক প্রযুক্তি ব্যবহারকারীদের জন্য এলিমেন্টগুলোকে সঠিকভাবে সংযুক্ত করা মৌলিক।

`useId` বিভিন্ন ARIA (Accessible Rich Internet Applications) অ্যাট্রিবিউট সংযোগ করার জন্য নিখুঁত টুল।

উদাহরণ: অ্যাক্সেসিবল মোডাল ডায়ালগ

একটি মোডাল ডায়ালগের প্রধান কন্টেইনারকে তার শিরোনাম এবং বর্ণনার সাথে সংযুক্ত করতে হয় যাতে স্ক্রিন রিডাররা সেগুলোকে সঠিকভাবে ঘোষণা করতে পারে।

import { useId, useState } from 'react';

function AccessibleModal({ title, children }) {
  const id = useId();
  const titleId = `${id}-title`;
  const contentId = `${id}-content`;

  return (
    

      
{title}
      

        {children}
      
    
  );
}

function App() {
  return (
    
      
By using this service, you agree to our terms and conditions...
    
  );
}

এখানে, `useId` নিশ্চিত করে যে এই `AccessibleModal` যেখানেই ব্যবহার করা হোক না কেন, `aria-labelledby` এবং `aria-describedby` অ্যাট্রিবিউটগুলো শিরোনাম এবং কন্টেন্ট এলিমেন্টের সঠিক, অনন্য আইডিতে পয়েন্ট করবে। এটি স্ক্রিন রিডার ব্যবহারকারীদের জন্য একটি নির্বিঘ্ন অভিজ্ঞতা প্রদান করে।

উদাহরণ: একটি গ্রুপে রেডিও বাটন সংযোগ করা

জটিল ফর্ম কন্ট্রোলগুলোর জন্য প্রায়শই সতর্ক আইডি ব্যবস্থাপনার প্রয়োজন হয়। রেডিও বাটনের একটি গ্রুপকে একটি সাধারণ লেবেলের সাথে যুক্ত করা উচিত।

import { useId } from 'react';

function RadioGroup() {
  const id = useId();
  const headingId = `${id}-heading`;

  return (
    

      
Select your global shipping preference:
      

        
        Standard (5-10 business days)
      
      

        
        Express (2-3 business days)
      
    
  );
}

একটি একক `useId` কলকে প্রিফিক্স হিসেবে ব্যবহার করে, আমরা একটি সুসংগত, অ্যাক্সেসিবল এবং অনন্য কন্ট্রোলের সেট তৈরি করি যা সর্বত্র নির্ভরযোগ্যভাবে কাজ করে।

গুরুত্বপূর্ণ পার্থক্য: `useId` কীসের জন্য নয়

বড় ক্ষমতার সাথে বড় দায়িত্ব আসে। `useId` কোথায় ব্যবহার করা উচিত নয় তা বোঝাও সমান গুরুত্বপূর্ণ।

লিস্ট কী-এর জন্য `useId` ব্যবহার করবেন না

এটি ডেভেলপারদের করা সবচেয়ে সাধারণ ভুল। React কী-গুলোকে একটি নির্দিষ্ট ডেটার জন্য স্থিতিশীল এবং অনন্য শনাক্তকারী হতে হবে, কোনো কম্পোনেন্ট ইনস্ট্যান্সের জন্য নয়।

ভুল ব্যবহার:

function TodoList({ todos }) {
  // অ্যান্টি-প্যাটার্ন: key-এর জন্য কখনও useId ব্যবহার করবেন না!
  return (
    

      {todos.map(todo => {
        const key = useId(); // এটি ভুল!
        return 
{todo.text}
;
      })}
    
  );
}

এই কোডটি হুকের নিয়ম (আপনি লুপের ভিতরে হুক কল করতে পারবেন না) লঙ্ঘন করে। কিন্তু এমনকি যদি আপনি এটি ভিন্নভাবে গঠন করতেন, যুক্তিটি ত্রুটিপূর্ণ। `key`-কে `todo` আইটেমের সাথে বাঁধা উচিত, যেমন `todo.id`। এটি React-কে আইটেম যোগ, অপসারণ বা পুনর্বিন্যাস করার সময় সঠিকভাবে ট্র্যাক করতে দেয়।

একটি কী-এর জন্য `useId` ব্যবহার করলে এটি রেন্ডারিং অবস্থানের সাথে আবদ্ধ একটি আইডি তৈরি করবে (যেমন, প্রথম `

function TodoList({ todos }) {
  return (
    

      {todos.map(todo => (
        // সঠিক: আপনার ডেটা থেকে একটি আইডি ব্যবহার করুন।
        
{todo.text}
      ))}
    
  );
}