Ant Design Table vs. Data Items: Ensuring Unique rowKey Without Public Exposure?

Answer

To guarantee a stable rowKey without exposing sensitive data, generate a deterministic identifier that is derived only from non‑sensitive fields or maintain an internal map of stable IDs.

Recommended patterns

1. Use an existing public identifier – If each record already has a UUID, slug, or any field that is safe to expose, pass it directly:

   <Table rowKey={(record) => record.id} />
   

2. Hash a combination of non‑sensitive attributes – When no suitable public field exists, create a hash from a stable subset of the data (e.g., name + createdAt). The hash must be deterministic and collision‑resistant for your dataset size:

   import { createHash } from 'crypto';
   
   function makeKey(record) {
     const source = JSON.stringify({ name: record.name, createdAt: record.createdAt });
     return createHash('sha256').update(source).digest('hex').slice(0, 8);
   }
   
   <Table rowKey={makeKey} />
   

3. Internal map‑based ID – On first render, assign each record a unique internal ID stored in a Map (or a WeakMap if you prefer automatic cleanup). Return that ID via rowKey. This keeps the key completely internal and stable across reorders, additions, or removals as long as the map persists:

   const internalIdMap = new Map();
   let nextId = 1;
   
   function getInternalId(record) {
     if (!internalIdMap.has(record)) {
       internalIdMap.set(record, nextId++);
     }
     return internalIdMap.get(record);
   }
   
   <Table rowKey={getInternalId} />
   

What to avoid

• Array index – Breaks selection, sorting, and inline editing when the list mutates and triggers React duplicate‑key warnings.
• Random UUIDs or timestamps – Cause a new key on every render, forcing remount of rows and losing internal state.
• Direct exposure of private fields – May leak identifiers in the DOM or React DevTools.

How Ant Design could improve

• Emit a warning in development when rowKey is missing or when duplicate keys are detected.
• Introduce an optional keyGenerator prop that defaults to a safe internal‑map strategy, removing the need for developers to implement their own fallback.
• Provide a utility function (e.g., stableHash(record, fields)) in the docs to help teams create deterministic, non‑exposed keys.