Mở khóa Hiệu suất: Phân tích Chuyên sâu về Key trong Quá trình Đối chiếu của React để Tối ưu hóa Danh sách

Trong thế giới phát triển web hiện đại, việc tạo ra các giao diện người dùng động, phản hồi nhanh chóng với những thay đổi dữ liệu là điều tối quan trọng. React, với kiến trúc dựa trên component và bản chất khai báo, đã trở thành một tiêu chuẩn toàn cầu để xây dựng những giao diện này. Cốt lõi của hiệu quả trong React là một quá trình được gọi là reconciliation (đối chiếu), liên quan đến Virtual DOM (DOM ảo). Tuy nhiên, ngay cả những công cụ mạnh mẽ nhất cũng có thể bị sử dụng một cách thiếu hiệu quả, và một lĩnh vực phổ biến mà các nhà phát triển, cả mới và có kinh nghiệm, thường gặp phải là trong việc render các danh sách.

Có lẽ bạn đã viết mã như data.map(item => <div>{item.name}</div>) vô số lần. Nó có vẻ đơn giản, gần như tầm thường. Tuy nhiên, bên dưới sự đơn giản này là một yếu tố hiệu suất quan trọng mà nếu bị bỏ qua, có thể dẫn đến các ứng dụng chậm chạp và những lỗi khó hiểu. Giải pháp? Một prop nhỏ nhưng mạnh mẽ: key.

Hướng dẫn toàn diện này sẽ đưa bạn đi sâu vào quá trình đối chiếu của React và vai trò không thể thiếu của các key trong việc render danh sách. Chúng ta sẽ không chỉ khám phá 'cái gì' mà còn là 'tại sao'—tại sao các key lại cần thiết, cách chọn chúng một cách chính xác, và những hậu quả đáng kể khi làm sai. Khi kết thúc, bạn sẽ có kiến thức để viết các ứng dụng React hiệu quả hơn, ổn định hơn và chuyên nghiệp hơn.

Chương 1: Tìm hiểu về Reconciliation (Đối chiếu) của React và Virtual DOM

Trước khi chúng ta có thể đánh giá đúng tầm quan trọng của các key, chúng ta phải hiểu cơ chế nền tảng giúp React hoạt động nhanh chóng: reconciliation, được cung cấp bởi Virtual DOM (VDOM).

Virtual DOM là gì?

Tương tác trực tiếp với Document Object Model (DOM) của trình duyệt là một việc tốn kém về mặt tính toán. Mỗi khi bạn thay đổi điều gì đó trong DOM—như thêm một node, cập nhật văn bản, hoặc thay đổi một style—trình duyệt phải thực hiện một khối lượng công việc đáng kể. Nó có thể cần phải tính toán lại các style và layout cho toàn bộ trang, một quá trình được gọi là reflow và repaint. Trong một ứng dụng phức tạp, dựa trên dữ liệu, việc thao tác trực tiếp và thường xuyên với DOM có thể nhanh chóng làm giảm hiệu suất xuống mức rất thấp.

React giới thiệu một lớp trừu tượng để giải quyết vấn đề này: Virtual DOM. VDOM là một bản sao nhẹ trong bộ nhớ của DOM thực. Hãy nghĩ về nó như một bản thiết kế cho giao diện người dùng của bạn. Khi bạn yêu cầu React cập nhật giao diện người dùng (ví dụ, bằng cách thay đổi state của một component), React không ngay lập tức chạm vào DOM thực. Thay vào đó, nó thực hiện các bước sau:

Một cây VDOM mới đại diện cho trạng thái đã cập nhật được tạo ra.
Cây VDOM mới này được so sánh với cây VDOM trước đó. Quá trình so sánh này được gọi là "diffing" (so sánh khác biệt).
React tìm ra tập hợp thay đổi tối thiểu cần thiết để biến đổi VDOM cũ thành VDOM mới.
Những thay đổi tối thiểu này sau đó được nhóm lại và áp dụng vào DOM thực trong một thao tác duy nhất, hiệu quả.

Quá trình này, được gọi là reconciliation, là điều làm cho React trở nên hiệu quả. Thay vì xây dựng lại toàn bộ ngôi nhà, React hoạt động như một nhà thầu chuyên nghiệp, xác định chính xác những viên gạch cụ thể nào cần được thay thế, giảm thiểu công việc và sự gián đoạn.

Chương 2: Vấn đề khi Render Danh sách mà không có Keys

Bây giờ, hãy xem hệ thống tinh vi này có thể gặp rắc rối ở đâu. Hãy xem xét một component đơn giản render một danh sách người dùng:


function UserList({ users }) {
  return (
    <ul>
      {users.map(user => (
        <li>{user.name}</li>
      ))}
    </ul>
  );
}

Khi component này render lần đầu, React xây dựng một cây VDOM. Nếu chúng ta thêm một người dùng mới vào *cuối* mảng `users`, thuật toán diffing của React xử lý nó một cách mượt mà. Nó so sánh danh sách cũ và mới, thấy một mục mới ở cuối, và chỉ cần thêm một `<li>` mới vào DOM thực. Hiệu quả và đơn giản.

Nhưng điều gì sẽ xảy ra nếu chúng ta thêm một người dùng mới vào đầu danh sách, hoặc sắp xếp lại các mục?

Giả sử danh sách ban đầu của chúng ta là:

Alice
Bob

Và sau khi cập nhật, nó trở thành:

Charlie
Alice
Bob

Không có bất kỳ định danh duy nhất nào, React so sánh hai danh sách dựa trên thứ tự của chúng (chỉ số). Đây là những gì nó thấy:

Vị trí 0: Mục cũ là "Alice". Mục mới là "Charlie". React kết luận rằng component ở vị trí này cần được cập nhật. Nó thay đổi node DOM hiện có để đổi nội dung từ "Alice" thành "Charlie".
Vị trí 1: Mục cũ là "Bob". Mục mới là "Alice". React thay đổi node DOM thứ hai để đổi nội dung từ "Bob" thành "Alice".
Vị trí 2: Trước đó không có mục nào ở đây. Mục mới là "Bob". React tạo và chèn một node DOM mới cho "Bob".

Điều này cực kỳ kém hiệu quả. Thay vì chỉ chèn một phần tử mới cho "Charlie" vào đầu, React đã thực hiện hai lần thay đổi và một lần chèn. Đối với một danh sách lớn, hoặc các mục trong danh sách là những component phức tạp có state riêng, công việc không cần thiết này dẫn đến suy giảm hiệu suất đáng kể và, quan trọng hơn, các lỗi tiềm ẩn với state của component.

Đây là lý do tại sao, nếu bạn chạy đoạn mã trên, console của nhà phát triển trong trình duyệt của bạn sẽ hiển thị một cảnh báo: "Warning: Each child in a list should have a unique 'key' prop." React đang nói rõ với bạn rằng nó cần sự giúp đỡ để thực hiện công việc của mình một cách hiệu quả.

Chương 3: Prop `key` - Vị cứu tinh

Prop `key` là gợi ý mà React cần. Đó là một thuộc tính chuỗi đặc biệt mà bạn cung cấp khi tạo danh sách các phần tử. Keys cung cấp cho mỗi phần tử một danh tính ổn định và duy nhất qua các lần re-render.

Hãy viết lại component `UserList` của chúng ta với các key:


function UserList({ users }) {
  return (
    <ul>
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

Ở đây, chúng ta giả định mỗi đối tượng `user` có một thuộc tính `id` duy nhất (ví dụ: từ cơ sở dữ liệu). Bây giờ, hãy xem lại kịch bản của chúng ta.

Dữ liệu ban đầu:


[{ id: 'u1', name: 'Alice' }, { id: 'u2', name: 'Bob' }]

Dữ liệu đã cập nhật:


[{ id: 'u3', name: 'Charlie' }, { id: 'u1', name: 'Alice' }, { id: 'u2', name: 'Bob' }]

Với các key, quá trình diffing của React thông minh hơn nhiều:

React nhìn vào các con của `<ul>` trong VDOM mới và kiểm tra các key của chúng. Nó thấy `u3`, `u1`, và `u2`.
Sau đó, nó kiểm tra các con của VDOM trước đó và các key của chúng. Nó thấy `u1` và `u2`.
React biết rằng các component với key `u1` và `u2` đã tồn tại. Nó không cần thay đổi chúng; nó chỉ cần di chuyển các node DOM tương ứng đến vị trí mới.
React thấy rằng key `u3` là mới. Nó tạo một component và node DOM mới cho "Charlie" và chèn nó vào đầu.

Kết quả là một lần chèn DOM duy nhất và một số sắp xếp lại, hiệu quả hơn nhiều so với nhiều lần thay đổi và một lần chèn mà chúng ta đã thấy trước đó. Các key cung cấp một danh tính ổn định, cho phép React theo dõi các phần tử qua các lần render, bất kể vị trí của chúng trong mảng.

Chương 4: Lựa chọn Key phù hợp - Những quy tắc vàng

Hiệu quả của prop `key` hoàn toàn phụ thuộc vào việc chọn giá trị phù hợp. Có những phương pháp hay nhất rõ ràng và các mẫu hình nguy hiểm cần phải nhận biết.

Key tốt nhất: ID duy nhất và ổn định

Key lý tưởng là một giá trị xác định duy nhất và vĩnh viễn một mục trong một danh sách. Điều này gần như luôn luôn là một ID duy nhất từ nguồn dữ liệu của bạn.

Nó phải là duy nhất giữa các phần tử anh em (siblings). Các key không cần phải là duy nhất trên toàn cầu, chỉ cần duy nhất trong danh sách các phần tử được render ở cấp độ đó. Hai danh sách khác nhau trên cùng một trang có thể có các mục với cùng một key.
Nó phải ổn định. Key cho một mục dữ liệu cụ thể không nên thay đổi giữa các lần render. Nếu bạn lấy lại dữ liệu cho Alice, cô ấy vẫn nên có cùng một `id`.

Các nguồn tuyệt vời cho các key bao gồm:

Khóa chính của cơ sở dữ liệu (ví dụ: `user.id`, `product.sku`)
Định danh duy nhất toàn cầu (UUID)
Một chuỗi duy nhất, không thay đổi từ dữ liệu của bạn (ví dụ: ISBN của một cuốn sách)


// TỐT: Sử dụng một ID ổn định và duy nhất từ dữ liệu.
<div>
  {products.map(product => (
    <ProductItem key={product.sku} product={product} />
  ))}
</div>

Mẫu hình cần tránh: Sử dụng chỉ số mảng làm Key

Một sai lầm phổ biến là sử dụng chỉ số mảng làm key:


// TỆ: Sử dụng chỉ số mảng làm key.
<div>
  {items.map((item, index) => (
    <ListItem key={index} item={item} />
  ))}
</div>

Mặc dù điều này sẽ làm im lặng cảnh báo của React, nó có thể dẫn đến các vấn đề nghiêm trọng và thường được coi là một mẫu hình cần tránh. Sử dụng chỉ số làm key cho React biết rằng danh tính của một mục được gắn với vị trí của nó trong danh sách. Về cơ bản, đây là vấn đề tương tự như không có key nào cả khi danh sách có thể được sắp xếp lại, lọc, hoặc có các mục được thêm/xóa khỏi đầu hoặc giữa.

Lỗi quản lý State:

Tác dụng phụ nguy hiểm nhất của việc sử dụng key chỉ số xuất hiện khi các mục trong danh sách của bạn quản lý state riêng. Hãy tưởng tượng một danh sách các trường nhập liệu:


function UnstableList() {
  const [items, setItems] = React.useState([{ id: 1, text: 'First' }, { id: 2, text: 'Second' }]);

  const handleAddItemToTop = () => {
    setItems([{ id: 3, text: 'New Top' }, ...items]);
  };

  return (
    <div>
      <button onClick={handleAddItemToTop}>Add to Top</button>
      {items.map((item, index) => (
        <div key={index}>
          <label>{item.text}: </label>
          <input type="text" />
        </div>
      ))}
    </div>
  );
}

Hãy thử bài tập tưởng tượng này:

Danh sách được render với "First" và "Second".
Bạn gõ "Hello" vào trường nhập liệu đầu tiên (cái cho "First").
Bạn nhấp vào nút "Add to Top".

Bạn mong đợi điều gì sẽ xảy ra? Bạn sẽ mong đợi một trường nhập liệu mới, trống cho "New Top" xuất hiện, và trường nhập liệu cho "First" (vẫn chứa "Hello") sẽ di chuyển xuống. Điều thực sự xảy ra là gì? Trường nhập liệu ở vị trí đầu tiên (chỉ số 0), vẫn chứa "Hello", vẫn còn đó. Nhưng bây giờ nó được liên kết với mục dữ liệu mới, "New Top". Trạng thái của component input (giá trị nội bộ của nó) được gắn với vị trí của nó (key=0), chứ không phải dữ liệu mà nó được cho là đại diện. Đây là một lỗi kinh điển và khó hiểu gây ra bởi các key chỉ số.

Nếu bạn chỉ cần thay đổi `key={index}` thành `key={item.id}`, vấn đề sẽ được giải quyết. React bây giờ sẽ liên kết chính xác state của component với ID ổn định của dữ liệu.

Khi nào có thể chấp nhận việc sử dụng chỉ số làm Key?

Có những tình huống hiếm hoi mà việc sử dụng chỉ số là an toàn, nhưng bạn phải đáp ứng tất cả các điều kiện sau:

Danh sách là tĩnh: Nó sẽ không bao giờ được sắp xếp lại, lọc, hoặc có các mục được thêm/xóa từ bất kỳ đâu ngoại trừ cuối danh sách.
Các mục trong danh sách không có ID ổn định.
Các component được render cho mỗi mục là đơn giản và không có state nội bộ.

Ngay cả khi đó, thường thì tốt hơn là tạo ra một ID tạm thời nhưng ổn định nếu có thể. Việc sử dụng chỉ số luôn phải là một lựa chọn có chủ ý, không phải là mặc định.

Thủ phạm tồi tệ nhất: `Math.random()`

Không bao giờ, không bao giờ sử dụng `Math.random()` hoặc bất kỳ giá trị không xác định nào khác cho một key:


// RẤT TỆ: Đừng bao giờ làm điều này!
<div>
  {items.map(item => (
    <ListItem key={Math.random()} item={item} />
  ))}
</div>

Một key được tạo bởi `Math.random()` được đảm bảo sẽ khác nhau trên mỗi lần render. Điều này cho React biết rằng toàn bộ danh sách các component từ lần render trước đã bị phá hủy và một danh sách hoàn toàn mới của các component hoàn toàn khác đã được tạo ra. Điều này buộc React phải unmount tất cả các component cũ (phá hủy state của chúng) và mount tất cả các component mới. Nó hoàn toàn đi ngược lại mục đích của reconciliation và là lựa chọn tồi tệ nhất có thể cho hiệu suất.

Chương 5: Các khái niệm nâng cao và câu hỏi thường gặp

Keys và `React.Fragment`

Đôi khi bạn cần trả về nhiều phần tử từ một hàm callback của `map`. Cách tiêu chuẩn để làm điều này là với `React.Fragment`. Khi bạn làm điều này, `key` phải được đặt trên chính component `Fragment`.


function Glossary({ terms }) {
  return (
    <dl>
      {terms.map(term => (
        // Key được đặt trên Fragment, không phải trên các phần tử con.
        <React.Fragment key={term.id}>
          <dt>{term.name}</dt>
          <dd>{term.definition}</dd>
        </React.Fragment>
      ))}
    </dl>
  );
}

Quan trọng: Cú pháp viết tắt `<>...</>` không hỗ trợ keys. Nếu danh sách của bạn yêu cầu fragments, bạn phải sử dụng cú pháp `<React.Fragment>` tường minh.

Keys chỉ cần là duy nhất giữa các phần tử anh em (Siblings)

Một quan niệm sai lầm phổ biến là các key phải là duy nhất trên toàn bộ ứng dụng của bạn. Điều này không đúng. Một key chỉ cần là duy nhất trong danh sách các phần tử anh em ngay lập tức của nó.


function CourseRoster({ courses }) {
  return (
    <div>
      {courses.map(course => (
        <div key={course.id}>  {/* Key cho khóa học */} 
          <h3>{course.title}</h3>
          <ul>
            {course.students.map(student => (
              // Key của sinh viên này chỉ cần là duy nhất trong danh sách sinh viên của khóa học cụ thể này.
              <li key={student.id}>{student.name}</li>
            ))}
          </ul>
        </div>
      ))}
    </div>
  );
}

Trong ví dụ trên, hai khóa học khác nhau có thể có một sinh viên với `id: 's1'`. Điều này hoàn toàn ổn vì các key đang được đánh giá trong các phần tử `<ul>` cha khác nhau.

Sử dụng Keys để chủ động Reset State của Component

Mặc dù các key chủ yếu dùng để tối ưu hóa danh sách, chúng còn phục vụ một mục đích sâu sắc hơn: chúng xác định danh tính của một component. Nếu key của một component thay đổi, React sẽ không cố gắng cập nhật component hiện có. Thay vào đó, nó sẽ phá hủy component cũ (và tất cả các con của nó) và tạo ra một component hoàn toàn mới từ đầu. Điều này sẽ unmount instance cũ và mount một instance mới, thực sự reset lại state của nó.

Đây có thể là một cách mạnh mẽ và có tính khai báo để reset một component. Ví dụ, hãy tưởng tượng một component `UserProfile` lấy dữ liệu dựa trên một `userId`.


function App() {
  const [userId, setUserId] = React.useState('user-1');

  return (
    <div>
      <button onClick={() => setUserId('user-1')}>View User 1</button>
      <button onClick={() => setUserId('user-2')}>View User 2</button>
      
      <UserProfile key={userId} id={userId} />
    </div>
  );
}

Bằng cách đặt `key={userId}` trên component `UserProfile`, chúng ta đảm bảo rằng bất cứ khi nào `userId` thay đổi, toàn bộ component `UserProfile` sẽ bị loại bỏ và một component mới sẽ được tạo ra. Điều này ngăn ngừa các lỗi tiềm ẩn nơi state từ hồ sơ của người dùng trước (như dữ liệu biểu mẫu hoặc nội dung đã lấy) có thể còn sót lại. Đó là một cách sạch sẽ và rõ ràng để quản lý danh tính và vòng đời của component.

Kết luận: Viết mã React tốt hơn

Prop `key` không chỉ là một cách để làm im lặng cảnh báo trên console. Nó là một chỉ dẫn cơ bản cho React, cung cấp thông tin quan trọng cần thiết để thuật toán đối chiếu của nó hoạt động hiệu quả và chính xác. Việc thành thạo cách sử dụng các key là một dấu hiệu của một nhà phát triển React chuyên nghiệp.

Hãy tóm tắt lại những điểm chính:

Keys là cần thiết cho hiệu suất: Chúng cho phép thuật toán diffing của React thêm, xóa và sắp xếp lại các phần tử trong danh sách một cách hiệu quả mà không cần các thay đổi DOM không cần thiết.
Luôn sử dụng ID ổn định và duy nhất: Key tốt nhất là một định danh duy nhất từ dữ liệu của bạn và không thay đổi qua các lần render.
Tránh dùng chỉ số mảng làm keys: Sử dụng chỉ số của một mục làm key có thể dẫn đến hiệu suất kém và các lỗi quản lý state tinh vi, khó chịu, đặc biệt là trong các danh sách động.
Không bao giờ sử dụng các key ngẫu nhiên hoặc không ổn định: Đây là trường hợp tồi tệ nhất, vì nó buộc React phải tạo lại toàn bộ danh sách các component trên mỗi lần render, phá hủy hiệu suất và state.
Keys xác định danh tính của component: Bạn có thể tận dụng hành vi này để chủ động reset state của một component bằng cách thay đổi key của nó.

Bằng cách nắm vững những nguyên tắc này, bạn không chỉ viết được các ứng dụng React nhanh hơn, đáng tin cậy hơn mà còn hiểu sâu hơn về cơ chế cốt lõi của thư viện. Lần tới khi bạn lặp qua một mảng để render một danh sách, hãy dành cho prop `key` sự chú ý mà nó xứng đáng. Hiệu suất của ứng dụng—và chính bạn trong tương lai—sẽ cảm ơn bạn vì điều đó.