เจาะลึก useId Hook ของ React: วิธีการสร้าง Identifier ที่เสถียรและไม่ซ้ำใคร

ในโลกของการพัฒนาเว็บที่มีการเปลี่ยนแปลงอยู่เสมอ การทำให้เนื้อหาที่เรนเดอร์ฝั่งเซิร์ฟเวอร์กับแอปพลิเคชันฝั่งไคลเอนต์มีความสอดคล้องกันนั้นเป็นสิ่งสำคัญอย่างยิ่ง หนึ่งในความท้าทายที่พบบ่อยและจัดการได้ยากคือการสร้าง identifier ที่ไม่ซ้ำใครและมีความเสถียร ID เหล่านี้มีความสำคัญอย่างยิ่งในการเชื่อมโยง label กับ input, การจัดการ ARIA attributes เพื่อการเข้าถึง (accessibility) และงานอื่นๆ ที่เกี่ยวข้องกับ DOM เป็นเวลาหลายปีที่นักพัฒนาต้องใช้วิธีแก้ปัญหาที่ไม่เหมาะสม ซึ่งมักนำไปสู่ปัญหา hydration mismatch และบั๊กที่น่าหงุดหงิด ขอแนะนำ `useId` hook ของ React 18—ซึ่งเป็นโซลูชันที่เรียบง่ายแต่ทรงพลัง ออกแบบมาเพื่อแก้ปัญหานี้อย่างสง่างามและเด็ดขาด

คู่มือฉบับสมบูรณ์นี้จัดทำขึ้นสำหรับนักพัฒนา React ทั่วโลก ไม่ว่าคุณจะกำลังสร้างแอปพลิเคชันที่เรนเดอร์ฝั่งไคลเอนต์แบบง่ายๆ, ประสบการณ์ Server-Side Rendered (SSR) ที่ซับซ้อนด้วยเฟรมเวิร์กอย่าง Next.js หรือสร้าง component library สำหรับให้คนทั่วโลกใช้งาน การทำความเข้าใจ `useId` ไม่ใช่ทางเลือกอีกต่อไป แต่มันคือเครื่องมือพื้นฐานสำหรับการสร้างแอปพลิเคชัน React ที่ทันสมัย แข็งแกร่ง และเข้าถึงได้

ปัญหาก่อนที่จะมี `useId`: โลกแห่ง Hydration Mismatches

เพื่อให้เข้าใจคุณค่าของ `useId` อย่างแท้จริง เราต้องเข้าใจโลกที่ไม่มีมันเสียก่อน ปัญหาหลักคือความต้องการ ID ที่ไม่ซ้ำกันภายในหน้าเว็บที่เรนเดอร์ แต่ในขณะเดียวกันก็ต้องสอดคล้องกันระหว่างเซิร์ฟเวอร์และไคลเอนต์

ลองพิจารณาคอมโพเนนต์ฟอร์ม input แบบง่ายๆ:

function LabeledInput({ label, ...props }) {
  // เราจะสร้าง ID ที่ไม่ซ้ำกันตรงนี้ได้อย่างไร?
  const inputId = 'some-unique-id';

  return (
    

      {label}
      
    
  );
}

attribute `htmlFor` บน `` ต้องตรงกับ `id` ของ `` เพื่อให้เป็น HTML ที่ถูกต้องตามความหมายและเพื่อการเข้าถึง (accessibility) หากเราใช้คอมโพเนนต์ `LabeledInput` นี้หลายครั้งในหน้าเว็บ เราก็ต้องการ ID ที่แตกต่างกันสำหรับแต่ละ instance

วิธีที่ 1: การใช้ `Math.random()`

ความคิดแรกที่มักจะนึกถึงในการสร้าง ID ที่ไม่ซ้ำกันคือการใช้ค่าสุ่ม

// รูปแบบที่ไม่ควรทำ: อย่าทำแบบนี้!
const inputId = `input-${Math.random()}`;

เหตุผลที่วิธีนี้ล้มเหลว:

• SSR Mismatch: เซิร์ฟเวอร์จะสร้างตัวเลขสุ่มขึ้นมาหนึ่งตัว (เช่น `input-0.12345`) เมื่อไคลเอนต์ทำการ hydrate แอปพลิเคชัน มันจะรัน JavaScript ใหม่อีกครั้งและสร้างตัวเลขสุ่มที่แตกต่างออกไป (เช่น `input-0.67890`) React จะเห็นความแตกต่างระหว่าง HTML ของเซิร์ฟเวอร์กับ HTML ที่เรนเดอร์ฝั่งไคลเอนต์ และจะแสดงข้อผิดพลาด hydration error
• การ Re-render: ID นี้จะเปลี่ยนไปทุกครั้งที่คอมโพเนนต์ re-render ซึ่งอาจนำไปสู่พฤติกรรมที่ไม่คาดคิดและปัญหาด้านประสิทธิภาพ

วิธีที่ 2: การใช้ตัวนับแบบ Global

วิธีที่ซับซ้อนขึ้นมาเล็กน้อยคือการใช้ตัวนับที่เพิ่มค่าขึ้นเรื่อยๆ

// รูปแบบที่ไม่ควรทำ: มีปัญหาเช่นกัน
let globalCounter = 0;
function generateId() {
  globalCounter++;
  return `component-${globalCounter}`;
}

เหตุผลที่วิธีนี้ล้มเหลว:

• ขึ้นอยู่กับลำดับการเรนเดอร์ของ SSR: วิธีนี้อาจดูเหมือนใช้งานได้ในตอนแรก เซิร์ฟเวอร์เรนเดอร์คอมโพเนนต์ตามลำดับที่แน่นอน และไคลเอนต์ก็ hydrate ตามนั้น แต่จะเกิดอะไรขึ้นถ้าลำดับการเรนเดอร์ของคอมโพเนนต์แตกต่างกันเล็กน้อยระหว่างเซิร์ฟเวอร์และไคลเอนต์? ซึ่งอาจเกิดขึ้นได้จากการทำ code splitting หรือ out-of-order streaming หากคอมโพเนนต์หนึ่งเรนเดอร์บนเซิร์ฟเวอร์แต่โหลดช้าบนไคลเอนต์ ลำดับของ ID ที่สร้างขึ้นอาจไม่ตรงกัน และนำไปสู่ hydration mismatches อีกครั้ง
• ปัญหาน่าปวดหัวสำหรับ Component Library: หากคุณเป็นผู้สร้างไลบรารี คุณจะไม่สามารถควบคุมได้เลยว่ามีคอมโพเนนต์อื่นๆ ในหน้าเว็บที่อาจใช้ตัวนับแบบ global ของตัวเองอยู่กี่ตัว ซึ่งอาจนำไปสู่การชนกันของ ID ระหว่างไลบรารีของคุณกับแอปพลิเคชันหลัก

ความท้าทายเหล่านี้ชี้ให้เห็นถึงความจำเป็นในการมีโซลูชันที่เป็นของ React เองและทำงานอย่างคาดเดาได้ (deterministic) ซึ่งเข้าใจโครงสร้างของ component tree และนั่นคือสิ่งที่ `useId` มอบให้

ขอแนะนำ `useId`: โซลูชันอย่างเป็นทางการ

`useId` hook จะสร้าง ID ที่เป็นสตริงที่ไม่ซ้ำกันและมีความเสถียรทั้งในการเรนเดอร์ฝั่งเซิร์ฟเวอร์และฝั่งไคลเอนต์ มันถูกออกแบบมาให้เรียกใช้งานที่ระดับบนสุดของคอมโพเนนต์ของคุณเพื่อสร้าง ID สำหรับส่งต่อไปยัง accessibility attributes

Syntax หลักและการใช้งาน

Syntax ของมันเรียบง่ายที่สุดเท่าที่จะเป็นไปได้ โดยไม่รับ arguments ใดๆ และคืนค่าเป็น ID ที่เป็นสตริง

import { useId } from 'react';

function LabeledInput({ label, ...props }) {
  // useId() สร้าง ID ที่ไม่ซ้ำและเสถียร เช่น ":r0:"
  const id = useId();

  return (
    

      {label}
      
    
  );
}

// ตัวอย่างการใช้งาน
function App() {
  return (
    

      
Sign Up Form
      
      
    
  );
}

ในตัวอย่างนี้ `LabeledInput` ตัวแรกอาจได้ ID เป็น `":r0:"` และตัวที่สองอาจได้เป็น `":r1:"` รูปแบบที่แน่นอนของ ID เป็นรายละเอียดการทำงานภายใน (implementation detail) ของ React และไม่ควรยึดติดกับรูปแบบนั้น สิ่งเดียวที่รับประกันได้คือมันจะไม่ซ้ำกันและมีความเสถียร

ประเด็นสำคัญคือ React รับประกันว่าลำดับของ ID ที่สร้างขึ้นบนเซิร์ฟเวอร์และไคลเอนต์จะเหมือนกัน ซึ่งช่วยขจัดปัญหา hydration errors ที่เกี่ยวข้องกับ ID ที่สร้างขึ้นได้อย่างสมบูรณ์

แนวคิดการทำงานเป็นอย่างไร?

ความมหัศจรรย์ของ `useId` อยู่ที่การทำงานที่คาดเดาผลลัพธ์ได้ (deterministic) มันไม่ได้ใช้การสุ่ม แต่จะสร้าง ID ตามเส้นทางของคอมโพเนนต์ภายใน React component tree เนื่องจากโครงสร้างของ component tree จะเหมือนกันทั้งบนเซิร์ฟเวอร์และไคลเอนต์ จึงรับประกันได้ว่า ID ที่สร้างขึ้นจะตรงกัน วิธีการนี้ทนทานต่อลำดับการเรนเดอร์ของคอมโพเนนต์ ซึ่งเป็นจุดอ่อนของวิธีการใช้ตัวนับแบบ global

การสร้าง ID ที่เกี่ยวข้องกันหลายตัวจากการเรียก Hook เพียงครั้งเดียว

ความต้องการทั่วไปคือการสร้าง ID ที่เกี่ยวข้องกันหลายตัวภายในคอมโพเนนต์เดียว ตัวอย่างเช่น input อาจต้องการ ID สำหรับตัวมันเอง และอีก ID หนึ่งสำหรับองค์ประกอบคำอธิบายที่เชื่อมโยงผ่าน `aria-describedby`

คุณอาจอยากที่จะเรียก `useId` หลายครั้ง:

// ไม่ใช่รูปแบบที่แนะนำ
const inputId = useId();
const descriptionId = useId();

แม้ว่าวิธีนี้จะใช้งานได้ แต่รูปแบบที่แนะนำคือการเรียก `useId` เพียงครั้งเดียวต่อคอมโพเนนต์ และใช้ ID พื้นฐานที่ได้มาเป็นคำนำหน้า (prefix) สำหรับ ID อื่นๆ ที่คุณต้องการ

import { useId } from 'react';

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

  return (
    

      {label}
      
      

        {description}
      
    
  );
}

ทำไมรูปแบบนี้ถึงดีกว่า?

• ประสิทธิภาพ: ทำให้มั่นใจได้ว่า React จำเป็นต้องสร้างและติดตาม ID ที่ไม่ซ้ำกันเพียงตัวเดียวสำหรับ instance ของคอมโพเนนต์นี้
• ความชัดเจนและความหมาย: ทำให้ความสัมพันธ์ระหว่างองค์ประกอบต่างๆ ชัดเจน ใครก็ตามที่อ่านโค้ดจะเห็นได้ว่า `form-field-:r2:-input` และ `form-field-:r2:-description` นั้นเกี่ยวข้องกัน
• รับประกันความไม่ซ้ำกัน: เนื่องจาก `baseId` ได้รับการรับประกันว่าจะไม่ซ้ำกันทั่วทั้งแอปพลิเคชัน ดังนั้นสตริงใดๆ ที่นำมาต่อท้ายก็จะยังคงไม่ซ้ำกันเช่นกัน

ฟีเจอร์เด็ด: Server-Side Rendering (SSR) ที่ไร้ที่ติ

ลองกลับมาดูปัญหาหลักที่ `useId` ถูกสร้างขึ้นมาเพื่อแก้ไข นั่นคือ hydration mismatches ในสภาพแวดล้อม SSR เช่น Next.js, Remix หรือ Gatsby

สถานการณ์: ข้อผิดพลาด Hydration Mismatch

ลองจินตนาการถึงคอมโพเนนต์ที่ใช้วิธี `Math.random()` แบบเก่าในแอปพลิเคชัน Next.js

1. การเรนเดอร์ฝั่งเซิร์ฟเวอร์: เซิร์ฟเวอร์รันโค้ดของคอมโพเนนต์ `Math.random()` ให้ผลลัพธ์เป็น `0.5` เซิร์ฟเวอร์ส่ง HTML ไปยังเบราว์เซอร์พร้อมกับ ``
2. การเรนเดอร์ฝั่งไคลเอนต์ (Hydration): เบราว์เซอร์ได้รับ HTML และ JavaScript bundle React เริ่มทำงานบนไคลเอนต์และเรนเดอร์คอมโพเนนต์ใหม่อีกครั้งเพื่อผูก event listeners (กระบวนการนี้เรียกว่า hydration) ในระหว่างการเรนเดอร์นี้ `Math.random()` ให้ผลลัพธ์เป็น `0.9` React สร้าง Virtual DOM ที่มี ``
3. ความไม่ตรงกัน: React เปรียบเทียบ HTML ที่สร้างจากเซิร์ฟเวอร์ (`id="input-0.5"`) กับ Virtual DOM ที่สร้างจากไคลเอนต์ (`id="input-0.9"`) เมื่อเห็นความแตกต่าง ก็จะแสดงคำเตือน: "Warning: Prop `id` did not match. Server: "input-0.5" Client: "input-0.9""

นี่ไม่ใช่แค่คำเตือนธรรมดาๆ มันสามารถนำไปสู่ UI ที่พัง, การจัดการ event ที่ไม่ถูกต้อง และประสบการณ์ผู้ใช้ที่แย่ React อาจต้องทิ้ง HTML ที่เรนเดอร์จากเซิร์ฟเวอร์และทำการเรนเดอร์ใหม่ทั้งหมดฝั่งไคลเอนต์ ซึ่งเป็นการทำลายประโยชน์ด้านประสิทธิภาพของ SSR

สถานการณ์: การแก้ปัญหาด้วย `useId`

ทีนี้ เรามาดูกันว่า `useId` แก้ปัญหานี้ได้อย่างไร

1. การเรนเดอร์ฝั่งเซิร์ฟเวอร์: เซิร์ฟเวอร์เรนเดอร์คอมโพเนนต์ มีการเรียกใช้ `useId` โดยอิงจากตำแหน่งของคอมโพเนนต์ใน tree มันจะสร้าง ID ที่เสถียรขึ้นมา สมมติว่าเป็น `":r5:"` เซิร์ฟเวอร์ส่ง HTML พร้อมกับ ``
2. การเรนเดอร์ฝั่งไคลเอนต์ (Hydration): เบราว์เซอร์ได้รับ HTML และ JavaScript React เริ่มกระบวนการ hydrate โดยจะเรนเดอร์คอมโพเนนต์เดียวกันในตำแหน่งเดียวกันใน tree `useId` hook ก็จะทำงานอีกครั้ง และเนื่องจากผลลัพธ์ของมันคาดเดาได้โดยอิงตามโครงสร้างของ tree มันจึงสร้าง ID เดิมเป๊ะๆ คือ `":r5:"`
3. ตรงกันอย่างสมบูรณ์: React เปรียบเทียบ HTML ที่สร้างจากเซิร์ฟเวอร์ (`id=":r5:"`) กับ Virtual DOM ที่สร้างจากไคลเอนต์ (`id=":r5:"`) ทั้งสองตรงกันอย่างสมบูรณ์แบบ กระบวนการ Hydration จึงเสร็จสิ้นโดยไม่มีข้อผิดพลาดใดๆ

ความเสถียรนี้เป็นรากฐานสำคัญของคุณค่าของ `useId` มันนำความน่าเชื่อถือและความสามารถในการคาดการณ์มาสู่กระบวนการที่เคยเปราะบาง

พลังพิเศษด้าน Accessibility (a11y) ด้วย `useId`

แม้ว่า `useId` จะมีความสำคัญสำหรับ SSR แต่การใช้งานหลักในชีวิตประจำวันคือการปรับปรุงการเข้าถึง (accessibility) การเชื่อมโยงองค์ประกอบต่างๆ อย่างถูกต้องเป็นพื้นฐานสำหรับผู้ใช้เทคโนโลยีช่วยเหลือ เช่น โปรแกรมอ่านหน้าจอ (screen readers)

`useId` เป็นเครื่องมือที่สมบูรณ์แบบสำหรับการเชื่อมโยง ARIA (Accessible Rich Internet Applications) attributes ต่างๆ

ตัวอย่าง: Modal Dialog ที่เข้าถึงได้

Modal dialog จำเป็นต้องเชื่อมโยงคอนเทนเนอร์หลักกับหัวข้อและคำอธิบายเพื่อให้โปรแกรมอ่านหน้าจอสามารถประกาศได้อย่างถูกต้อง

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` นี้จะถูกนำไปใช้ที่ไหน attributes `aria-labelledby` และ `aria-describedby` จะชี้ไปยัง ID ที่ถูกต้องและไม่ซ้ำกันขององค์ประกอบหัวข้อและเนื้อหาเสมอ ซึ่งมอบประสบการณ์ที่ราบรื่นสำหรับผู้ใช้โปรแกรมอ่านหน้าจอ

ตัวอย่าง: การเชื่อมโยง Radio Buttons ในกลุ่มเดียวกัน

การควบคุมฟอร์มที่ซับซ้อนมักต้องการการจัดการ ID อย่างระมัดระวัง กลุ่มของ radio buttons ควรถูกเชื่อมโยงกับ label กลางเดียวกัน

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` สำหรับ List Keys

นี่เป็นข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนาทำ React keys จำเป็นต้องเป็น identifier ที่เสถียรและไม่ซ้ำกันสำหรับข้อมูลชิ้นนั้นๆ ไม่ใช่สำหรับ instance ของคอมโพเนนต์

การใช้งานที่ไม่ถูกต้อง:

function TodoList({ todos }) {
  // รูปแบบที่ไม่ควรทำ: ห้ามใช้ useId สำหรับ keys เด็ดขาด!
  return (
    

      {todos.map(todo => {
        const key = useId(); // แบบนี้ผิด!
        return 
{todo.text}
;
      })}
    
  );
}

โค้ดนี้ละเมิดกฎของ Hooks (คุณไม่สามารถเรียก hook ภายใน loop ได้) แต่ถึงแม้คุณจะปรับโครงสร้างให้แตกต่างออกไป ตรรกะก็ยังคงผิดพลาด `key` ควรผูกอยู่กับไอเท็ม `todo` เอง เช่น `todo.id` ซึ่งจะช่วยให้ React สามารถติดตามไอเท็มได้อย่างถูกต้องเมื่อมีการเพิ่ม, ลบ หรือจัดลำดับใหม่

การใช้ `useId` สำหรับ key จะสร้าง ID ที่ผูกกับตำแหน่งในการเรนเดอร์ (เช่น `

function TodoList({ todos }) {
  return (
    

      {todos.map(todo => (
        // ถูกต้อง: ใช้ ID จากข้อมูลของคุณ
        
{todo.text}
      ))}
    
  );
}