perf: optimize collection selection with indexed lookups

[Copilot]

Description

Addresses O(n × m) performance bottleneck in collection widget rendering. With 20 visible collections and 1000 components, the previous implementation performed ~20,000 array scans. This replaces linear searches with Map-based indexes, reducing per-widget complexity to O(1).

Impact: Course Authors using bulk collection selection in large libraries (100+ components, 10+ collections).

Changes

1. Added useCollectionIndexing hook (ComponentPickerContext.tsx)

• Builds collectionToComponents and componentToCollections maps once per search update
• Amortizes indexing cost across all widgets (O(n) once vs O(n × m) per widget)

2. Refactored AddComponentWidget.tsx

• Replaced buildCollectionComponents() and countCollectionHits() helper functions
• Uses Map.get() for O(1) lookups instead of Array.filter()

3. Optimized findCommonCollectionKey (ComponentPickerContext.tsx)

• Converts array to Set for O(1) membership checks
• Reduces from O(n*m) to O(n)

Example

Before:

// O(n) filter per widget
const components = hits.filter(hit => 
  hit.collections?.key?.includes(collectionKey)
);

After:

// O(1) lookup using pre-built index
const { collectionToComponents } = useCollectionIndexing(hits);
const components = collectionToComponents.get(collectionKey) ?? [];

Performance

Scenario	Before	After	Improvement
20 collections, 1000 components	~20,000 ops	~1,020 ops	95% reduction
Per widget	O(n × m)	O(1)	10-100x faster

Supporting information

Implements performance optimization discussed in PR #2 code review for bulk collection selection feature.

Testing instructions

1. Create a library with 50+ components across multiple collections
2. Open component picker in multiple selection mode
3. Verify collection checkboxes reflect correct state (empty/indeterminate/checked)
4. Select entire collection - all components should be selected
5. Deselect individual components - collection should show indeterminate state
6. Verify selection/deselection remains responsive with large datasets

Existing test coverage validates correctness (298 library-authoring tests, 13 ComponentPicker tests, 39 Collection tests).

Other information

• Backward compatible - no API changes
• No migrations or configuration changes required
• All existing tests pass without modification

Original prompt

Performance Optimization for Collection Selection

Problem

The current implementation in PR #2 has performance bottlenecks when rendering multiple collection widgets:

1. buildCollectionComponents runs O(n × m) for each widget - With 20 collections visible, the entire hits array is scanned 20 times
2. No caching across widgets - Each AddComponentWidget rebuilds the same collection→component mappings
3. Array.includes() is O(m) - Linear search for collection key matching

This becomes problematic with:

• Thousands of components in library
• Dozens of collections rendered simultaneously
• Frequent re-renders from search updates

Solution

Implement indexed collection lookups at the context level to amortize the cost across all widgets.

---

Changes Required

1. Add useCollectionIndexing hook to ComponentPickerContext.tsx

After line 102 (after the selectedCollections state declaration), add this new exported hook:

/**
 * Builds indexed maps for efficient collection lookups.
 * This creates two maps:
 * 1. collectionToComponents: Maps collection keys to their component arrays
 * 2. componentToCollections: Maps component usage keys to their collection keys
 * 
 * Complexity: O(n) once per hits update instead of O(n × m) per widget
 */
export const useCollectionIndexing = (
  hits: any[], // Type should match ReturnType<typeof useSearchContext>['hits']
) => useMemo(() => {
  const collectionToComponents = new Map<string, SelectedComponent[]>();
  const componentToCollections = new Map<string, string[]>();
  
  hits.forEach((hit) => {
    if (hit.type === 'library_block') {
      const collectionKeys = (hit as any).collections?.key ?? [];
      
      // Index component → collections mapping
      if (hit.usageKey) {
        componentToCollections.set(hit.usageKey, collectionKeys);
      }
      
      // Index collection → components mapping
      collectionKeys.forEach((collectionKey: string) => {
        if (!collectionToComponents.has(collectionKey)) {
          collectionToComponents.set(collectionKey, []);
        }
        collectionToComponents.get(collectionKey)!.push({
          usageKey: hit.usageKey,
          blockType: hit.blockType,
          collectionKeys,
        });
      });
    }
  });
  
  return { collectionToComponents, componentToCollections };
}, [hits]);

---

2. Update AddComponentWidget.tsx to use indexed lookups

Step 2a: Update imports

Add useCollectionIndexing to the import from ComponentPickerContext:

import { 
  SelectedComponent, 
  useComponentPickerContext,
  useCollectionIndexing, // <- ADD THIS
} from '../common/context/ComponentPickerContext';

Step 2b: Remove the old helper functions

Delete these functions (lines 25-49):

• buildCollectionComponents
• countCollectionHits

Step 2c: Replace the collectionData useMemo logic

Replace the existing collectionData useMemo (around lines 67-76) with this optimized version:

  const { hits } = useSearchContext();
  
  // Use indexed lookup for O(1) performance instead of O(n) filtering
  const { collectionToComponents, componentToCollections } = useCollectionIndexing(hits);
  
  const collectionData = useMemo(() => {
    // When selecting a collection: O(1) lookup instead of O(n) filter
    if (isCollection) {
      return collectionToComponents.get(usageKey) ?? [];
    }
    
    // When selecting an individual component: O(1) lookup + O(m) count
    const componentCollectionKeys = componentToCollections.get(usageKey);
    if (!componentCollectionKeys?.length) {
      return 0;
    }
    
    // Count total components across all collections this component belongs to
    const componentSet = new Set<string>();
    componentCollectionKeys.forEach((collectionKey) => {
      const components = collectionToComponents.get(collectionKey) ?? [];
      components.forEach((comp) => componentSet.add(comp.usageKey));
    });
    
    return componentSet.size;
  }, [collectionToComponents, componentToCollections, usageKey, isCollection]);

---

3. Optional: Optimize findCommonCollectionKey in ComponentPickerContext.tsx

Replace the findCommonCollectionKey function (lines 133-149) with this Set-based version:

/**
 * Finds the common collection key between a component and selected components.
 * Optimized with Set for O(n) instead of O(n*m) complexity.
 */
const findCommonCollectionKey = useCallback((
  componentKeys: string[] | undefined,
  components: SelectedComponent[],
): string | undefined => {
  if (!componentKeys?.length || !components.length) {
    return undefined;
  }

  // Convert to Set for O(1) lookups instead of O(m) for each includes()
  const componentKeySet = new Set(componentKeys);

  for (const component of components) {
    const commonKey = component.collectionKeys?.find((key) => componentKeySet.has(key));
    if (commonKey) {
      return commonKey;
    }
  }

  return und...

</details>



<!-- START COPILOT CODING AGENT SUFFIX -->

*This pull request was created from Copilot chat.*
>

<!-- START COPILOT CODING AGENT TIPS -->
---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey).