Bug: fix for Undefined behaviour for unnamed chips (pun intended)

[codecraft26]

Fix: Undefined Behavior for Unnamed Chips (#1467)

Problem Description

When creating chips without explicit names, the system would randomly assign either "unnamed_chip1" or "undefined" as the component name. This undefined behavior caused inconsistent naming and potential runtime errors.

Root Cause

The issue was in the name getter of PrimitiveComponent class:

get name() {
  return (this._parsedProps as any).name ?? this.fallbackUnassignedName
}

When both this._parsedProps.name and this.fallbackUnassignedName were undefined, the getter would return undefined, leading to inconsistent behavior.

Solution

1. Enhanced Name Getter

Modified the name getter in /lib/components/base-components/PrimitiveComponent/PrimitiveComponent.ts:

get name() {
  const explicitName = (this._parsedProps as any).name
  if (explicitName && typeof explicitName === 'string' && explicitName.trim() !== '') {
    return explicitName
  }
  
  // If we have a fallback name, use it
  if (this.fallbackUnassignedName) {
    return this.fallbackUnassignedName
  }
  
  // Last resort fallback - should never happen in normal operation
  // This prevents undefined from being returned
  return `unnamed_${this.lowercaseComponentName}`
}

2. Improved Name Generation

Enhanced the getNextAvailableName method in /lib/components/primitive-components/Group/Group.ts:

getNextAvailableName(elm: PrimitiveComponent): string {
  const componentType = elm.lowercaseComponentName || 'component'
  
  // Ensure the counter exists and is a valid number
  if (typeof this.unnamedElementCounter[componentType] !== 'number') {
    this.unnamedElementCounter[componentType] = 1
  }
  
  // Generate the name and increment the counter
  const name = `unnamed_${componentType}${this.unnamedElementCounter[componentType]++}`
  
  return name
}

Key Improvements

✅ Robust Name Validation

• Handles undefined, empty strings, and whitespace-only names
• Always returns a valid string (never undefined)
• Preserves explicit names when provided

✅ Consistent Fallback Behavior

• Components without names get predictable fallback names
• Format: unnamed_{componentType} or unnamed_{componentType}{number}
• Examples: unnamed_chip, unnamed_chip1, unnamed_resistor2

✅ Backward Compatibility

• Existing explicit names continue to work unchanged
• No breaking changes to existing functionality

Testing

Created comprehensive tests in /tests/components/normal-components/unnamed-component-naming.test.tsx:

1. Explicit names preserved: name="U1" → "U1"
2. Undefined names handled: name={undefined} → "unnamed_chip1"
3. Empty string names handled: name="" → "unnamed_chip1"
4. Whitespace names handled: name=" " → "unnamed_chip1"

Results

Before Fix

// Inconsistent behavior
chip.name // Could be "unnamed_chip1" OR "undefined"

After Fix

// Consistent behavior
chip.name // Always a valid string: "unnamed_chip1", "unnamed_chip2", etc.

Files Modified

1. /lib/components/base-components/PrimitiveComponent/PrimitiveComponent.ts

   • Enhanced name getter with robust fallback logic

2. /lib/components/primitive-components/Group/Group.ts

   • Improved getNextAvailableName method with better type safety

3. /tests/components/normal-components/unnamed-component-naming.test.tsx

   • Added comprehensive test coverage for naming edge cases

4. /tests/components/normal-components/chip.test.tsx

   • Updated existing tests to handle new naming behavior

Impact

• ✅ Eliminates undefined behavior: No more random "undefined" names
• ✅ Improves reliability: Consistent naming across all components
• ✅ Better debugging: Predictable component names for troubleshooting
• ✅ Type safety: All component names are guaranteed to be strings

This fix resolves issue #1467 and ensures that all components have valid, predictable names regardless of how they are created.

[vercel]

@codecraft26 is attempting to deploy a commit to the tscircuit Team on Vercel.

A member of the Team first needs to authorize it.

[graphite-app]

This test file violates the established rule that a *.test.ts file may contain at most one test(...) function. When additional tests are needed, they must be split into separate numbered files (e.g., add1.test.ts, add2.test.ts). The current file already contains one test before line 91, and this modification adds two additional test functions: should assign consistent names to unnamed chips (lines 91-153) and should handle chips with empty string names (lines 155-203). These additional tests must be moved to separate numbered files such as chip2.test.tsx and chip3.test.tsx.

Spotted by Graphite Agent (based on custom rule: Custom rule)



Is this helpful? React 👍 or 👎 to let us know.