Problem

When using BTable/BTableLite with row-details, if the items array is replaced with new object references (even with the same data), the row-details would be hidden. This commonly happens in "Load more" scenarios where the entire items array is recreated with new objects.

Root Cause: The detailsMap used a WeakMap with object references as keys. When items were replaced with new objects, the WeakMap lost track of which rows had details open because the object references changed.

Solution

Updated BTableLite to use primary keys for tracking row-details state when the primary-key prop is provided:

• Changed detailsMap from WeakMap<object> to Map<object | string> to support both primary key strings and object references
• Modified generateDetailsItem to return the primary key string when primaryKey prop is provided and the item contains that key
• Added getDetailsMapKey helper function for consistent map key generation throughout the component
• Updated watcher logic to preserve existing details state when items are replaced with the same primary key value
• Updated all template usages to use getDetailsMapKey(item) for map lookups
• Falls back to object reference tracking when no primaryKey is provided (maintains full backward compatibility)

Usage

To enable row-details persistence across item updates, provide a primary-key prop:

<BTable :items="items" :fields="fields" primary-key="id">
  <template #cell(actions)="row">
    <BButton @click="row.toggleDetails">
      {{ row.detailsShowing ? 'Hide' : 'Show' }} Details
    </BButton>
  </template>
  <template #row-details="row">
    <BCard>Details for {{ row.item.name }}</BCard>
  </template>
</BTable>

When items are updated (e.g., in a "Load more" scenario):

// Items are replaced with new object references but same IDs
items.value = [
  { id: 1, name: 'Alice', age: 30 },  // New object but id: 1 remains
  { id: 2, name: 'Bob', age: 25 },    // New object but id: 2 remains
  { id: 3, name: 'Charlie', age: 35 } // New item added
]
// Row-details for items with id 1 and 2 will persist if they were open

Demo

The fix is demonstrated with two tables - one with primary-key and one without:

• Top table (with primary-key): Alice's details remain open after clicking "Load More" ✅
• Bottom table (without primary-key): Alice's details are closed after clicking "Load More" (expected behavior for backward compatibility)

Changes

Core Implementation (BTableLite.vue):

• detailsMap: WeakMap<object> → Map<object | string> to support string keys
• generateDetailsItem: Returns primary key string when primaryKey prop is provided
• getDetailsMapKey: New helper function for consistent key generation
• Template: Updated to use getDetailsMapKey(item) instead of direct item references
• Watcher: Preserves toggled state across item replacements when primary keys match

Tests (table-lite.spec.ts):

• Added test: "persists details when items are replaced with new object references but same primary key"
• Added test: "falls back to object reference when primaryKey is not provided"
• All existing tests continue to pass (1632 tests)

Backward Compatibility

✅ Fully backward compatible - when no primaryKey is provided, the component uses object references as before. This is a progressive enhancement that only activates when the primary-key prop is used.

Testing

• ✅ All unit tests pass (1632 tests)
• ✅ Linting passes
• ✅ Build succeeds
• ✅ Manual testing confirms fix works as expected

Fixes #[issue-number]

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.