ನೀವು React ನಲ್ಲಿ ಸ್ವಲ್ಪ ಸಮಯ ಕಳೆದಿದ್ದರೆ, ನಿಮ್ಮ ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಈ ಹಳದಿ ಎಚ್ಚರಿಕೆಯನ್ನು ನೋಡಿರಬಹುದು: “Each child in a list should have a unique ‘key’ prop.” ಇದು ಕೇವಲ ಒಂದು ಸೌಜನ್ಯದ ಸಲಹೆಯಂತೆ ಕೇಳಿಸಬಹುದು, ಆದರೆ ನಿಮ್ಮ ಲಿಸ್ಟ್ ಐಟಂಗಳನ್ನು (list items) ಗುರುತಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತಿಲ್ಲ ಎಂದು React ವಾಸ್ತವವಾಗಿ ನಿಮಗೆ ಎಚ್ಚರಿಸುತ್ತಿದೆ. ಇದನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ನೀವು ಅಂತಿಮವಾಗಿ ಒಂದು ಬಗ್ ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತೀರಿ, ಅದನ್ನು ಸರಿಪಡಿಸುವುದು ತುಂಬಾ ಕಷ್ಟವಾಗಬಹುದು—ಉದಾಹರಣೆಗೆ ಸ್ಟೇಟ್ (state) ತಪ್ಪಾದ ಸಾಲಿಗೆ ಹೋಗುವುದು, ಟೆಕ್ಸ್ಟ್ ಇನ್‌ಪುಟ್‌ಗಳು ಫೋಕಸ್ ಕಳೆದುಕೊಳ್ಳುವುದು ಅಥವಾ ಅನಿಮೇಷನ್‌ಗಳು ತಪ್ಪಾದ ಎಲಿಮೆಂಟ್‌ನಲ್ಲಿ ಚಲಿಸುವುದು.

React ನ ರೆಂಡರಿಂಗ್ ಇಂಜಿನ್ (rendering engine) ನಿಮ್ಮ UI ಅನ್ನು ಪಿಕ್ಸೆಲ್ ಬೈ ಪಿಕ್ಸೆಲ್ ಹೋಲಿಸುವುದಿಲ್ಲ. ಇದು ವರ್ಚುವಲ್ DOM (virtual DOM) ಎಂದು ಕರೆಯಲ್ಪಡುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಹಗುರವಾದ ಮರವನ್ನು (tree) ನಿರ್ಮಿಸುತ್ತದೆ, ಹೊಸ ಮರವನ್ನು ಹಿಂದಿನ ಮ всегоೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ ಮತ್ತು ರಿಯಲ್ DOM ಗಾಗಿ ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಬದಲಾವಣೆಗಳನ್ನು ಲೆಕ್ಕಹಾಕುತ್ತದೆ. ನೀವು ಒಂದು ಲಿಸ್ಟ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡಿದಾಗ, React ಸಹೋದರ ಎಲಿಮೆಂಟ್‌ಗಳ (sibling elements) ಅರೇ ಅನ್ನು ನೋಡುತ್ತದೆ. ಕೀಗಳು (keys) ಇಲ್ಲದಿದ್ದರೆ, ಯಾವುದಾದರೂ ಐಟಂ ಚಲಿಸಿದೆಯೇ, ಬದಲಾಯಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ತೆಗೆದುಹಾಕಲಾಗಿದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಅದಕ್ಕೆ ಯಾವುದೇ ವಿಶ್ವಾಸಾರ್ಹ ಮಾರ್ಗವಿಲ್ಲ. ಅದು ಸ್ಥಾನದ (position) ಆಧಾರದ ಮೇಲೆ ಹೊಂದಾಣಿಕೆ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಇದು ಅಸ್ಥಿರವಾದುದು. ಕೀಗಳು ಸ್ಥಿರವಾದ ಗುರುತಿನಂತೆ (stable identities) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಅವು React ಗೆ, “ಈ ಎಲಿಮೆಂಟ್ ಈಗ ಬೇರೆ ಸ್ಲಾಟ್‌ನಲ್ಲಿದ್ದರೂ ಸಹ, ಇದು ಮೊದಲಿನಂತೆಯೇ ಇದೆ” ಎಂದು ತಿಳಿಸುತ್ತವೆ. ಇದನ್ನು ತಪ್ಪಾದ ರೀತಿಯಲ್ಲಿ ಮಾಡಿದರೆ, ನೀವು ನಿಖರವಾದ ಅಪ್‌ಡೇಟ್‌ಗಳ ಬದಲಿಗೆ ಅಂದಾಜಿನ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಬೇಕಾಗುತ್ತದೆ.

ಕನಿಷ್ಠ ಪರಿಹಾರ

ಈ ಎಚ್ಚರಿಕೆಯು ಸಾಮಾನ್ಯವಾಗಿ map ಕಾಲ್‌ನ ಒಳಗೆ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನೀವು ಇಟರೇಟರ್‌ನಿಂದ (iterator) ಮರಳುವ ಟಾಪ್-ಲೆವೆಲ್ ಎಲಿಮೆಂಟ್‌ನಲ್ಲಿ key ಅಟ್ರಿಬ್ಯೂಟ್‌ಗೆ ವಿಶಿಷ್ಟ ಮೌಲ್ಯವನ್ನು (unique value) ನೀಡಲೇಬೇಕು.

ಎಚ್ಚರಿಕೆಯನ್ನು ಪ್ರಚೋದಿಸುವ ಪ್ರತಿಯೊಂದು ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ನೀವು ಕಾಣುವ ಮಾದರಿ ಇಲ್ಲಿದೆ:

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

React ಮೂರು <li ಟ್ಯಾಗ್‌ಗಳನ್ನು ನೋಡುತ್ತದೆ ಮತ್ತು ಯಾವುದು ಯಾವುದು ಎಂಬುದು ಅದಕ್ಕೆ ತಿಳಿಯುವುದಿಲ್ಲ. ಇದಕ್ಕೆ ತಿದ್ದುಪಡಿ ಕೇವಲ ಒಂದು ಅಟ್ರಿಬ್ಯೂಟ್:

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

key ಅನ್ನು map ಕಾಲ್‌ಬ್ಯಾಕ್‌ನ ಒಳಗಿರುವ ಎಲಿಮೆಂಟ್‌ಗೆ ನೇರವಾಗಿ ನೀಡಬೇಕು. ನೀವು <li ಅನ್ನು ಪ್ರತ್ಯೇಕ UserItem ಕಂಪೊನೆಂಟ್‌ಗೆ ಹೊರತೆಗೆದರೂ ಸಹ, ಕೀಯು ಕಾಲ್ ಸೈಟ್‌ನಲ್ಲಿ (call site) ಆ ಕಂಪೊನೆಂಟ್‌ಗೆ ಸೇರಿದ್ದೇ ಆಗಿರುತ್ತದೆ:

{users.map((user) => (
  <UserItem key={user.id} user={user} />
))}

UserItem ನ ಒಳಗಿರುವ <div> ನಲ್ಲಿ ಕೀಯನ್ನು ಇರಿಸುವುದರಿಂದ ಎಚ್ಚರಿಕೆಯು ನಿಲ್ಲುವುದಿಲ್ಲ ಮತ್ತು ರೆಕನ್ಸಿಲಿಯೇಶನ್ (reconciliation) ವರ್ತನೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. React ಇಟರೇಟರ್‌ನಿಂದ ಮರಳುವ ಎಲಿಮೆಂಟ್‌ನಲ್ಲಿ ಕೀಯನ್ನು ಹುಡುಕುತ್ತದೆ.

ಕೀಯಾಗಿ ಇಂಡೆಕ್ಸ್ (Index) ಬಳಸುವುದು ಏಕೆ ಅಪಾಯಕಾರಿ

map ನ ಎರಡನೇ ಆರ್ಗ್ಯುಮೆಂಟ್ ಅನ್ನು ಬಳಸಿ ಎಚ್ಚರಿಕೆಯನ್ನು ನಿಲ್ಲಿಸುವುದು ಸುಲಭವೆನಿಸಬಹುದು:

{users.map((user, index) => (
  <li key={index}>{user.name}</li>
))}

ಇದು ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಎಚ್ಚರಿಕೆಯನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದರೆ ಮೂಲ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ. ಅರೇ ಇಂಡೆಸ್‌ಗಳು (Array indices) ಗುರುತುಗಳಲ್ಲ (identities). ಅವು ಕೇವಲ ಸ್ಥಾನಗಳು (positions), ಮತ್ತು ಸ್ಥಾನಗಳು ಬದಲಾಗುತ್ತವೆ.

ಈ ಕೆಳಗಿನ ಕ್ರಮದಲ್ಲಿ ರೆಂಡರ್ ಆಗುತ್ತಿರುವ ಮೂವರು ಬಳಕೆದಾರರ ಲಿಸ್ಟ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:

  1. Alice (index 0)
  2. Bob (index 1)
  3. Charlie (index 2)

ನೀವು Alice ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡಿದರೆ, Bob ಇಂಡೆಕ್ಸ್ 0 ಕ್ಕೆ ಮತ್ತು Charlie ಇಂಡೆಕ್ಸ್ 1 ಕ್ಕೆ ಬದಲಾಗುತ್ತಾರೆ. React ಹೊಸ ಮರವನ್ನು ಹಳೆಯ ಮ всегоೊಂದಿಗೆ ಹೋಲಿಸುತ್ತದೆ. ಇಂಡೆಕ್ಸ್ 0 ಈಗ Bob ನ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ ಎಂದು ಅದು ನೋಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ಮೊದಲು Alice ಅನ್ನು ತೋರಿಸುತ್ತಿದ್ದ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ DOM ನೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ (mutate). ಆ ನೋಡ್ ಫೋಕಸ್ ಹೊಂದಿದ್ದರೆ, ಕರ್ಸರ್ ಮೊದಲ ಸಾಲಿನಲ್ಲಿಯೇ ಇರುತ್ತದೆ, ಆದರೆ ಪಠ್ಯವು Bob ಗೆ ಬದಲಾಗುತ್ತದೆ. ಆ ಸಾಲಿನಲ್ಲಿ ಲೋಕಲ್ ಸ್ಟೇಟ್ (local state) ಹೊಂದಿರುವ <input> ಇದ್ದರೆ, ಆ ಸ್ಟೇಟ್ ಇಂಡೆಕ್ಸ್ 0 ಕ್ಕೆ ಅಂಟಿಕೊಂಡೇ ಇರುತ್ತದೆ. ಬಳಕೆದಾರರು Bob ನ ಸಾಲು ಎಂದು ಭಾವಿಸಿ ಟೈಪ್ ಮಾಡುತ್ತಾರೆ, ಆದರೆ ಸ್ಟೇಟ್ Alice ಗೆ ಸೇರಿದ್ದಾಗಿರುತ್ತದೆ. ನೀವು ಐಟಂಗಳನ್ನು ಸಾರ್ಟ್ (sort), ಫಿಲ್ಟರ್ (filter) ಅಥವಾ ಪ್ರೆಪೆಂಡ್ (prepend) ಮಾಡಿದಾಗಲೂ ಇದೇ ರೀತಿಯ ಗೊಂದಲ ಉಂಟಾಗುತ್ತದೆ. ಇಂಡೆಕ್ಸ್ ಕೀಯನ್ನು ಬಳಸಲು ಸುರಕ್ಷಿತವಾದ ಏಕೈಕ ಸ್ಥಳವೆಂದರೆ ಅದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಟ್ಯಾಟಿಕ್ (static) ಆಗಿರುವ ಲಿಸ್ಟ್: ಅಂದರೆ ಯಾವುದೇ ಮರು-ಕ್ರಮೀಕರಣ (reordering), ಫಿಲ್ಟರಿಂಗ್, ಇನ್ಸರ್ಟಿಂಗ್ ಅಥವಾ ಡಿಲೀಟಿಂಗ್ ಇಲ್ಲದ ಲಿಸ್ಟ್. ಎಂದಿಗೂ ಬದಲಾಗದ ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾದ ನ್ಯಾವಿಗೇಷನ್ ಲಿಂಕ್‌ಗಳು ಇದಕ್ಕೆ ಉತ್ತಮ ಉದಾಹರಣೆ. ಉಳಿದೆಲ್ಲವುಗಳಿಗೆ ನೈಜ ಐಡೆಂಟಿಫೈಯರ್ (identifier) ಅಗತ್ಯವಿದೆ.

ಸ್ಥಿರವಾದ ಕೀಯನ್ನು ಎಲ್ಲಿ ಹುಡುಕಬೇಕು

ಅತ್ಯುತ್ತಮ ಕೀಯೆಂದರೆ ನಿಮ್ಮ ಡೇಟಾ ಮಾಡೆಲ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಇರುವ ವಿಶಿಷ್ಟ ಐಡೆಂಟಿಫೈಯರ್. ಡೇಟಾಬೇಸ್ ಪ್ರೈಮರಿ ಕೀಗಳಾದ id ಅತ್ಯುತ್ತಮವಾಗಿವೆ ಏಕೆಂದರೆ ಅವು ವಿಶಿಷ್ಟವಾಗಿರುತ್ತವೆ ಮತ್ತು ರೆಂಡರ್‌ಗಳ ನಡುವೆಯೂ ಉಳಿಯುತ್ತವೆ. ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ uuid, slug ಅಥವಾ ಇತರ ಯಾವುದಾದರೂ ನೈಸರ್ಗಿಕವಾಗಿ ವಿಶಿಷ್ಟವಾದ ಫೀಲ್ಡ್ ಅನ್ನು ನೀಡಿದರೆ, ಅದನ್ನು ಬಳಸಿ.

ನಿಮ್ಮ API ರೆಸ್ಪಾನ್ಸ್‌ನಲ್ಲಿ ಯಾವುದೇ ವಿಶಿಷ್ಟ ಫೀಲ್ಡ್ ಇಲ್ಲದಿದ್ದಾಗ, ನಿಮ್ಮ ಮುಂದೆ ಎರಡು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗಗಳಿವೆ. ಮೊದಲನೆಯದಾಗಿ, ನಿಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ತಂಡದೊಂದಿಗೆ ಮಾತನಾಡಿ id ಅನ್ನು ಸೇರಿಸಲು ಕೇಳಿ. ಪ್ರೈಮರಿ ಕೀ ಇಲ್ಲದೆ ರಿಲೇಶನಲ್ ಡೇಟಾವನ್ನು (relational data) ಕಳುಹಿಸುವುದು ಸರಿಯಲ್ಲ, ಮತ್ತು ಮೂಲದಲ್ಲೇ ಇದನ್ನು ಸರಿಪಡಿಸುವುದರಿಂದ ನಿಮ್ಮ ಇಡೀ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಅಸ್ಪಷ್ಟತೆ ನಿವಾರಣೆಯಾಗುತ್ತದೆ. ಎರಡನೆಯದಾಗಿ, ನೀವು ಐಟಂಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕ್ಲೈಂಟ್ ಸೈಡ್‌ನಲ್ಲಿ (client side) ತಯಾರಿಸುತ್ತಿದ್ದರೆ—ಉದಾಹರಣೆಗೆ ಬಳಕೆದಾರರು ಸರ್ವರ್‌ಗೆ ತಲುಪುವ ಮೊದಲು ಕಾರ್ಯಗಳನ್ನು ರಚಿಸುವ ಟೊಡೋ ಲಿಸ್ಟ್ (todo list)—ಸೃಷ್ಟಿಸುವ ಸಮಯದಲ್ಲಿಯೇ ಒಂದು ID ಅನ್ನು ತಯಾರಿಸಿ. uuid ಅಥವಾ nanoid ನಂತಹ ಲೈಬ್ರರಿಗಳು ಇದಕ್ಕಾಗಿම ನಿರ್ಮಿಸಲಾಗಿದೆ. ಬಳಕೆದಾರರು ಫಾರ್ಮ್ ಸಬ್ಮಿಟ್ ಮಾಡಿದಾಗ ID ಅನ್ನು ತಯಾರಿಸಿ, ಅದನ್ನು ಆಬ್ಜೆಕ್ಟ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ಕೀಯಾಗಿ ಯಾವಾಗಲೂ ಬಳಸಿ.

ರೆಂಡರ್ ಪಾತ್‌ನ (render path) ಒಳಗೆ ಎಂದಿಗೂ ಕೀಯನ್ನು ತಯಾರಿಸಬೇಡಿ. ಕಂಪೊನೆಂಟ್ ರೆಂಡರ್ ಆಗುವಾಗ Math.random() ಅಥವಾ Date.now() ಅನ್ನು ಕರೆಯುವುದು ಪ್ರತಿ ಬಾರಿ ಹೊಸ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. React ಹೊಸ ಕೀಯನ್ನು ನೋಡಿ, ಅದು ಹೊಸ ಎಲಿಮೆಂಟ್ ಎಂದು ಭಾವಿಸುತ್ತದೆ, ಹಳೆಯ DOM ನೋಡ್ ಅನ್ನು ನಾಶಪಡಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸದನ್ನು ರಚಿಸುತ್ತದೆ. ಆ ಎಲಿಮೆಂಟ್‌ನ ಒಳಗಿರುವ ಯಾವುದೇ ಸ್ಟೇಟ್ ರಿಸೆಟ್ ಆಗುತ್ತದೆ. ಫೋಕಸ್ ಕಳೆ//ಹೋಗುತ್ತದೆ. React ಅನಗತ್ಯವಾದ DOM ಕೆಲಸಗಳನ್ನು ಮಾಡುವುದರಿಂದ ಪರ್ಫಾರ್ಮೆನ್ಸ್ (performance) ಕುಸಿಯುತ್ತದೆ. ಯಾದೃಚ್ಛಿಕವಾಗಿ (randomly) ತಯಾರಿಸಿದ ಕೀಯು ಕೀ ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತಲೂ ಕೆಟ್ಟದ್ದಾಗಿದೆ.

Fragments, Components, and Scope

ಒಂದು ಕಡಿಮೆ ಗಮನಕ್ಕೆ ಬರುವ ತೊಂದರೆಯೆಂದರೆ React Fragments. ನೀವು ಡೇಟಾವನ್ನು map ಮಾಡುವಾಗ ಮತ್ತು ಒಂದು wrapper <div> ಇಲ್ಲದೆ ಹಲವಾರು sibling elements ಅನ್ನು return ಮಾಡಬೇಕಾದಾಗ, ನೀವು ಈ ಸಂಕ್ಷಿಪ್ತ (short) syntax ಅನ್ನು ಬಳಸಬಹುದು:

{items.map((item) => (
  <>
    <dt>{item.term}</dt>
    <dd>{item.definition}</dd>
  </>
))}

ಈ shorthand <>...</> syntaxವು props ಅನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ, ಅಂದರೆ ನೀವು ಇದಕ್ಕೆ key ಅನ್ನು ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪೂರ್ಣ ಪ್ರಮಾಣದ explicit syntax ಅನ್ನು ಬಳಸಿ:

{items.map((item) => (
  <React.Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.definition}</dd>
  </React.Fragment>
))}

React ಗೆ ಆ Fragment ಮೇಲೆ key ಅಗತ್ಯವಿದೆ, ಇದರಿಂದ ಅದು renders ಗಳ ನಡುವೆ ಆ ಜೋಡಿಯನ್ನು (pair) ಒಂದು ಏಕೈಕ ಘಟಕವಾಗಿ (single unit) ಟ್ರ್ಯಾಕ್ ಮಾಡಬಹುದು.

ಇನ್ನೊಂದು ಸೂಕ್ಷ್ಮ ಅಂಶವೆಂದರೆ: keys ಎಂಬುದು ಸಾಮಾನ್ಯ ಅರ್ಥದಲ್ಲಿ props ಅಲ್ಲ. ನೀವು <ListItem key={item.id} /> ಎಂದು ಬರೆದರೆ, ListItem component ಗೆ props.key ಅನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. React ಇದನ್ನು ತನ್ನ ಆಂತರಿಕ ವ್ಯವಸ್ಥೆಗಾಗಿ (bookkeeping) ಬಳಸಿಕೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ component ಗೆ ತನ್ನದೇ ಆದ ಲಾಜಿಕ್ ಉದ್ದೇಶಕ್ಕಾಗಿ ಆ identifier ಅಗತ್ಯವಿದ್ದರೆ, ಅದನ್ನು itemId ನಂತಹ ಬೇರೆ ಹೆಸರಿನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಕಳುಹಿಸಿ.

ನಿಮ್ಮನ್ನು ಸುರಕ್ಷಿತವಾಗಿಡಲು ಪ್ರಾಯೋಗಿಕ ನಿಯಮಗಳು

  • Database IDs ಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ. ಅವು ವಿಶಿಷ್ಟವಾಗಿರುತ್ತವೆ (unique), ಸಂಖ್ಯೆ ಅಥವಾ ಸ್ಟ್ರಿಂಗ್ ಆಧಾರಿತವಾಗಿರುತ್ತವೆ ಮತ್ತು ಸ್ಥಿರವಾಗಿರುತ್ತವೆ (stable).
  • Client-only ಡೇಟಾಕ್ಕಾಗಿ uuid ಅಥವಾ nanoid ಬಳಸಿ. ರೆಕಾರ್ಡ್ ರಚನೆಯಾದಾಗ ಒಮ್ಮೆ ಮಾತ್ರ ID ಅನ್ನು ರಚಿಸಿ, component render ಒಳಗಡೆ ಮಾಡಬೇಡಿ.
  • ಪಟ್ಟಿ (list) ಬದಲಾಗುವ ಸಾಧ್ಯತೆಯಿದ್ದರೆ, ಎಂದಿಗೂ array index ನಿಂದ key ಅನ್ನು ಪಡೆಯಬೇಡಿ. Sorting, filtering ಮತ್ತು deleting ಮಾಡುವುದರಿಂದ ದೃಶ್ಯ (visual) ಮತ್ತು state ದೋಷಗಳು (bugs) ಉಂಟಾಗಬಹುದು.
  • ಎಂದಿಗೂ Math.random(), Date.now(), ಅಥವಾ renders ಗಳ ನಡುವೆ ಬದಲಾಗುವ ಯಾವುದೇ ಮೌಲ್ಯವನ್ನು ಬಳಸಬೇಡಿ. ಇದು ಅನಗತ್ಯವಾಗಿ unmounting ಮತ್ತು remounting ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
  • Fragments ಒಂದು map ಒಳಗಿದ್ದರೆ ಮತ್ತು ಅದಕ್ಕೆ key ಅಗತ್ಯವಿದ್ದರೆ, ಅವುಗಳಿಗೆ long form ಅಗತ್ಯ ಎಂಬುದನ್ನು ನೆನಪಿಡಿ.
  • Key ಅನ್ನು map ನಿಂದ return ಆಗುವ element ಮೇಲೆ ಇರಿಸಿ, child component ಒಳಗಡೆ ಇರಿಸಬೇಡಿ.

ಮುಖ್ಯವಾದ ಅಂಶ

key prop ಎಂಬುದು ಕೇವಲ ಅಲಂಕಾರಿಕ lint ನಿಯಮವಲ್ಲ. renders ಗಳ ನಡುವೆ React ತನ್ನ ಗುರುತನ್ನು (identity) ಕಾಪಾಡಿಕೊಳ್ಳುವ ವಿಧಾನ ಇದಾಗಿದೆ. ಇದನ್ನು ಡೇಟಾಬೇಸ್ ಟೇಬಲ್‌ನಲ್ಲಿರುವ primary key ನಂತೆ ಭಾವಿಸಿ. ಆ identity ಸ್ಥಿರವಾಗಿದ್ದಾಗ, React ಅಂಶಗಳನ್ನು (elements) ನಿಖರವಾಗಿ ಚಲಾಯಿಸಲು, ಅಪ್‌ಡೇಟ್ ಮಾಡಲು ಮತ್ತು ತೆಗೆದುಹಾಕಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಅದು ಇಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಅಸ್ಥಿರವಾಗಿದ್ದರೆ, ದೋಷಪೂರಿತ UI state ಮತ್ತು ನಿಧಾನಗತಿಯ reconciliation ಎಂಬ ಬೆಲೆಯನ್ನು ನೀವು ತೆರಬೇಕಾಗುತ್ತದೆ. ಇದನ್ನು ಒಮ್ಮೆ ಡೇಟಾ ಲೇಯರ್‌ನಲ್ಲಿಯೇ ಸರಿಪಡಿಸಿ, ಆಗ ನಿಮ್ಮ ಪಟ್ಟಿಗಳು ಎಷ್ಟೇ ಬೆಳೆದರೂ ಅಥವಾ ಬದಲಾದರೂ ಅವು ನಿರೀಕ್ಷಿತ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.