feat: cable data model and schema (#261) #355
Conversation
Add data model and schema for cable connections between device interfaces, supporting network visualization and connectivity tracking. New types and schemas: - Cable interface with A/B side terminations - CableType enum (cat5e-cat8, DAC, fiber OM3/OM4/OS2, AOC, power, serial) - CableStatus enum (connected, planned, decommissioning) - LengthUnit enum (m, cm, ft, in) - CableSchema with Zod validation Cable store (cables.svelte.ts): - CRUD operations: addCable, updateCable, removeCable - Query helpers: getCableById, getCablesByDevice, getCablesByInterface - Validation: device existence, interface existence, duplicate detection - Auto-cleanup: removeCablesByDevice for cascading deletes Layout integration: - cables array added to Layout type - LayoutSchema updated with cables validation - YAML serialization with proper field ordering Test coverage (42 tests): - Schema validation for all enums and Cable structure - Validation rules for endpoints and duplicates - Full CRUD operation testing - Edge cases for self-referential and reverse connections Closes #261 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughAdds a NetBox-compatible cable data model and Zod schemas, YAML serialization support for cables, a Svelte cable store with validation and CRUD (including raw undo/redo hooks), layout-store raw cable mutators, and comprehensive tests for schema, validation, and store behavior. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant UI
participant Store as Cable Store
participant Schema as Zod Schema
participant Validator as validateCable()
participant Layout as Layout Store
rect rgb(40,42,54)
Note over User,UI: User submits cable input
User->>UI: submit cable payload
UI->>Store: addCable(input)
end
Store->>Schema: parse & basic validation
Schema-->>Store: parsed cable or errors
alt Schema OK
Store->>Validator: validateCable(cable, layout)
Validator->>Layout: read devices & device types
Layout-->>Validator: device/interface data
Validator-->>Store: validation result
alt Validation passes
Store->>Layout: addCableRaw(cable)
Layout-->>Store: layout updated
Store->>UI: success (marks layout dirty)
else Validation fails
Store->>UI: error details
end
else Schema errors
Store->>UI: schema error details
end
sequenceDiagram
participant CLI
participant YAML as serializeLayoutToYaml()
participant Order as orderCableFields()
participant Disk
CLI->>YAML: serializeLayoutToYaml(layout)
YAML->>Order: orderCableFields() per cable
Order-->>YAML: ordered objects
YAML->>Disk: write YAML with `cables` section
Disk-->>CLI: persisted file
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
✨ Finishing touches
📜 Recent review detailsConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (2)
🧰 Additional context used📓 Path-based instructions (2)**/*.{ts,tsx,js,svelte}📄 CodeRabbit inference engine (CLAUDE.md)
Files:
**/*.{ts,tsx}📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧬 Code graph analysis (1)src/lib/stores/cables.svelte.ts (2)
🔇 Additional comments (10)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
src/lib/schemas/index.tssrc/lib/stores/cables.svelte.tssrc/lib/types/index.tssrc/lib/utils/yaml.tssrc/tests/cables.test.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js,svelte}
📄 CodeRabbit inference engine (CLAUDE.md)
Use TypeScript strict mode
Files:
src/tests/cables.test.tssrc/lib/utils/yaml.tssrc/lib/stores/cables.svelte.tssrc/lib/types/index.tssrc/lib/schemas/index.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
NetBox-compatible field naming: use snake_case for field names (e.g.,
u_height,device_type,form_factor) in data models
Files:
src/tests/cables.test.tssrc/lib/utils/yaml.tssrc/lib/stores/cables.svelte.tssrc/lib/types/index.tssrc/lib/schemas/index.ts
🧬 Code graph analysis (3)
src/lib/utils/yaml.ts (1)
src/lib/types/index.ts (2)
Cable(299-328)Layout(500-513)
src/lib/types/index.ts (1)
src/lib/schemas/index.ts (3)
CableType(547-547)CableStatus(548-548)LengthUnit(549-549)
src/lib/schemas/index.ts (1)
src/lib/types/index.ts (3)
CableType(158-177)CableStatus(182-182)LengthUnit(187-187)
🔇 Additional comments (17)
src/lib/stores/cables.svelte.ts (3)
13-24: LGTM! Ze interface follows NetBox-compatible snake_case convention.Ah, vonderful! Ze
CreateCableInputinterface uses proper snake_case field naming (a_device_id,b_device_id, etc.) as required by ze coding guidelines. Zis is consistent vith ze Cable type definition and ensures proper data model compatibility.
41-138: Excellent validation logic, my friend!Ze
validateCablefunction is like a vell-guarded castle! It checks for:
- Device existence on both sides of ze connection
- Interface existence on device types
- Duplicate cables (including reversed endpoints - very clever!)
- Self-referential cables
Ze documentation at lines 81-82 explaining vhy any interface name is allowed vhen device type has no interfaces defined is particularly vise - it supports user-defined cables vithout explicit interface templates.
341-368: LGTM! Ze store API is vell-organized.Ze returned object provides a clean API vith clear separation between:
- Getters for querying cables
- High-level CRUD operations (vith validation and dirty tracking)
- Raw operations for undo/redo flows
- Validation helper
Zis is exactly how a vell-designed store should look, like a perfectly organized coffin!
src/lib/utils/yaml.ts (4)
10-10: LGTM! Ze Cable type import is properly added.Ze import statement now includes ze
Cabletype, vhich is needed for ze neworderCableFieldsfunction. Very good, my friend!
166-193: LGTM! Ze field ordering function follows established patterns.Ah, very consistent vith ze existing
orderDeviceTypeFields,orderPlacedDeviceFields, andorderRackFieldsfunctions! Ze core fields are alvays included, vhile optional properties liketype,color,label, etc., are only added vhen zey have a value. Zis ensures clean YAML output vithout unnecessaryundefinedvalues haunting ze file like restless spirits.
208-211: LGTM! Ze conditional serialization is proper.Vonderful! Ze cables array is only included in ze serialized output vhen it exists AND has at least vun cable. Zis keeps ze YAML files clean and avoids empty
cables: []entries vhen no cables are defined. Very tidy, like my castle before ze sun rises!
220-228: LGTM! Ze runtime layout now preserves cables.Ze
toRuntimeLayoutfunction now correctly passes zecablesproperty from ze parsed layout to ze runtime layout. Zis ensures cables loaded from YAML files are available at runtime for ze cable store to use. Simple and effective, like a stake through ze heart!src/tests/cables.test.ts (4)
17-72: LGTM! Vell-crafted test fixtures.Ah, ze test fixtures are nicely structured, my friend! Ze
createTestDeviceType,createTestPlacedDevice, andcreateTestLayouthelper functions provide clean vays to create test data vithout repetition. Ze test layout includes two devices vith interfaces defined, vhich enables comprehensive testing of ze cable validation logic.
74-255: Excellent schema validation test coverage!Ze schema validation tests are quite comprehensive, like a vell-documented grimoire:
- CableTypeSchema: Tests all 13 valid types and rejects invalid ones
- CableStatusSchema: Tests all 3 statuses and rejects invalid ones
- LengthUnitSchema: Tests all 4 units and correctly rejects 'mm'
- CableSchema: Tests required fields, hex color formats (including case variations), and length constraints (negative/zero/positive)
Particularly pleased to see ze test at line 176 checking for ze "hex color" error message - zis ensures ze user gets helpful feedback!
257-422: Superb validation test coverage!Ze validation tests are as thorough as my nighttime hunts! Zey cover:
- ✓ Valid cables between existing devices (line 265)
- ✓ Non-existent A-side device (line 277)
- ✓ Non-existent B-side device (line 289)
- ✓ Non-existent A-side interface (line 301)
- ✓ Non-existent B-side interface (line 315)
- ✓ Duplicate cable detection - same endpoints (line 329)
- ✓ Duplicate cable detection - reversed endpoints (line 352)
- ✓ Exclusion from duplicate check for updates (line 376)
- ✓ Self-connection rejection (line 397)
- ✓ Different interfaces on same device allowed (line 411)
Zis matches all ze validation rules specified in ze PR objectives. Vonderful vork!
424-723: LGTM! Ze store tests are comprehensive and vell-organized.Ze cable store tests cover all ze important CRUD scenarios:
- Getters:
getCables,getCableById,getCablesByDevice,getCablesByInterface- all tested vith both positive and negative cases- addCable: Tests valid addition, invalid rejection, and dirty state tracking
- updateCable: Tests property updates, invalid endpoint changes, and non-existent cables
- removeCable: Tests successful removal and non-existent cable handling
- removeCablesByDevice: Tests bulk removal and empty results
Ze use of nested
beforeEachhooks (e.g., lines 599-613, 653-667, 686-707) to set up specific test state is a good practice. It keeps ze tests isolated and readable, like separate chapters in my diary of ze night!src/lib/schemas/index.ts (3)
156-193: LGTM! Ze cable enum schemas are properly defined.Ze NetBox-compatible enum schemas are vell-documented vith comments grouping ze cable types by category:
- CableTypeSchema: Copper Ethernet, DAC, Multi-mode fiber, Single-mode fiber, AOC, Power & Serial
- CableStatusSchema: Three connection states
- LengthUnitSchema: Metric and imperial units
Ze values match ze TypeScript types in
src/lib/types/index.ts(lines 157-187), ensuring type safety across ze codebase.
500-500: LGTM! Ze Layout schema properly includes optional cables array.Ze
cablesfield is added as an optional array ofCableSchema, vhich is exactly vhat ve need for ze layout to support cable connections. Zis follovs ze same pattern as other optional arrays in ze codebase.
547-550: LGTM! Ze type exports complete ze schema module.Ze type exports inferred from ze Zod schemas (
CableType,CableStatus,LengthUnit,CableZod) provide type safety vhen vorking vith ze schemas. Zese complement ze handwritten types insrc/lib/types/index.ts- both must stay in sync, but zis is ze standard pattern in ze codebase.src/lib/types/index.ts (3)
154-188: LGTM! Ze cable type definitions follow NetBox conventions.Ze new type aliases are vell-documented vith comments grouping ze cable types by category, matching ze structure in
src/lib/schemas/index.ts. Ze snake_case naming convention is properly maintained for NetBox compatibility as per ze coding guidelines.
291-328: LGTM! Ze Cable interface is vell-documented and properly structured.Ah, a beautiful interface, like ze moon rising over my castle! Ze Cable interface:
- Uses proper snake_case field naming (
a_device_id,b_device_id,a_interface,b_interface) as required by ze coding guidelines for NetBox compatibility- Has comprehensive JSDoc comments explaining each field
- Properly marks optional fields vith
?- References ze type aliases defined earlier in ze file
Ze structure matches ze
CableSchemainsrc/lib/schemas/index.ts, ensuring consistency across ze codebase.
511-512: LGTM! Ze Layout interface now supports cable connections.Ze optional
cablesfield completes ze data model, allowing layouts to store cable connections between device interfaces. Zis matches zeLayoutSchemaBaseinsrc/lib/schemas/index.tsand enables ze full cable management functionality.Ze PR objectives are now complete - ve have ze data model, schemas, store vith CRUD operations, validation, serialization, and comprehensive tests. A magnificent achievement, vorthy of eternal life!
- Use HEX_COLOUR_PATTERN constant for cable color validation - Optimize removeCablesByDevice with batch removal (single loadLayout call) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Move cable mutations from cables.svelte.ts workarounds to proper layout store methods. This addresses CodeRabbit review feedback about the cables store rebuilding the entire layout object. Layout store additions: - addCableRaw: Add a cable with immutable update - updateCableRaw: Update cable properties - removeCableRaw: Remove single cable - removeCablesRaw: Batch remove cables by ID set Cables store changes: - Delegate to layout store methods instead of loadLayout workarounds - Simplified raw operation implementations - Clearer separation of concerns 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
src/lib/schemas/index.tssrc/lib/stores/cables.svelte.tssrc/lib/stores/layout.svelte.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js,svelte}
📄 CodeRabbit inference engine (CLAUDE.md)
Use TypeScript strict mode
Files:
src/lib/schemas/index.tssrc/lib/stores/cables.svelte.tssrc/lib/stores/layout.svelte.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
NetBox-compatible field naming: use snake_case for field names (e.g.,
u_height,device_type,form_factor) in data models
Files:
src/lib/schemas/index.tssrc/lib/stores/cables.svelte.tssrc/lib/stores/layout.svelte.ts
🧬 Code graph analysis (2)
src/lib/schemas/index.ts (1)
src/lib/types/index.ts (3)
CableType(158-177)CableStatus(182-182)LengthUnit(187-187)
src/lib/stores/layout.svelte.ts (1)
src/lib/types/index.ts (1)
Cable(299-328)
🔇 Additional comments (13)
src/lib/schemas/index.ts (4)
156-179: Excellent vork on ze CableTypeSchema, my friend!Ze enum values align perfectly vith ze
CableTypeunion defined insrc/lib/types/index.ts. Ze categorization vith comments for Copper Ethernet, DAC, Fiber types, and Power/Serial is quite... delightful for maintainability, yes?
181-193: Ze status and length unit schemas look impeccable!Both
CableStatusSchemaandLengthUnitSchemacorrectly mirror zeir TypeScript counterparts. Ze NetBox compatibility is preserved like a fine vintage from ze old country.
500-500: Ze cables integration into LayoutSchemaBase is correct.Making
cablesoptional preserves backward compatibility vith existing layouts zat do not have cables defined. Very vise, like an ancient vampire who has seen many schema migrations.
547-550: Type exports are complete and properly inferred.Ze inferred types from Zod schemas vill keep TypeScript happy and ensure runtime validation aligns vith compile-time types. A beautiful symphony of type safety!
src/lib/stores/cables.svelte.ts (5)
13-24: Ze CreateCableInput interface follows ze snake_case convention properly.All field names adhere to ze NetBox-compatible naming as specified in ze coding guidelines. Ze optional properties mirror ze Cable interface correctly.
189-220: Ze addCable function is vell-structured vith proper error handling.Ze discriminated union return type
{ cable: Cable; errors: null } | { cable: null; errors: string[] }is excellent for type-safe error handling. Ze validation-first approach ensures invalid cables never reach ze store.One small note: ze
generateId()call on line 202 happens after validation, vhich is correct - no vasted IDs on failed validations.
226-257: Ze updateCable function has sound conditional validation logic.I appreciate zat validation only triggers vhen endpoint fields are being modified (lines 240-250). Zis avoids unnecessary validation vhen only updating cable properties like color or label.
Ze use of
excludeCableIdin ze duplicate check correctly prevents ze cable from matching against itself during updates.
278-294: Ze batch removal optimization is implemented correctly.I see ze past review comment about performance vas addressed! Ze use of
Setfor efficient ID lookup and ze singleremoveCablesRawcall is much better zan iterating vith individual removals. Ze ESLint disable comment on line 287 is appropriate since zis is not reactive state.
324-351: Ze store API is comprehensive and vell-organized.Ze separation of:
- Getters (
cables,getCableById, etc.)- CRUD operations (
addCable,updateCable, etc.)- Raw operations for undo/redo (
addCableRaw, etc.)- Validation helper
...follows a clear pattern zat matches ze existing layout store architecture. Consistency is ze mark of a true immortal codebase!
src/lib/stores/layout.svelte.ts (4)
15-15: Ze Cable type import is correct.Ze import is properly placed vith ze ozher type imports from
$lib/types.
188-192: Ze cable raw actions are properly exposed in ze public API.Ze grouping under a comment
// Cable raw actionsmaintains ze organizational pattern used elsevhere in ze store. Zey are placed after ze existing raw actions, vhich is logical.
860-910: Ze Cable Raw Actions implementation is solid and consistent.Ze immutable update pattern using spread operators matches ze existing raw actions in zis file. Ze nullish coalescing
(layout.cables ?? [])correctly handles layouts vithout a cables array.A few observations:
updateCableRaw (lines 881-888): If ze cable ID doesn't exist, zis silently does nosing (ze map returns ze same array). Zis is consistent vith ozher raw operations like
updateDeviceTypeRaw, but somesing to be avare of.removeCableRaw and removeCablesRaw are complementary - single removal vs batch. Ze batch version correctly accepts a
Set<string>for O(1) lookups during filtering.All four functions bypass dirty tracking as documented, vhich is correct for undo/redo operations.
869-874: Ze safeguard against duplicate cable IDs already exists—it just vorks at ze proper layer.Ze system validates cables before calling
addCableRaw, not vithin it. ZevalidateCablefunction (in cables.svelte.ts) explicitly rejects duplicates by checking for cables vith identical or reversed endpoints. Raw operations likeaddCableRawandplaceDeviceRaware intentionally low-level and trust ze caller, vhich is correct for undo/redo. Adding validation to ze raw operation vould be redundant and defeat ze point of having raw operations—zey must remain lean for command replay. Ze current architecture is sound.Likely an incorrect or invalid review comment.
src/lib/schemas/index.ts
Outdated
| export const CableSchema = z | ||
| .object({ | ||
| // Unique identifier | ||
| id: z.string().min(1, "Cable ID is required"), | ||
|
|
||
| // A-side termination | ||
| a_device_id: z.string().min(1, "A-side device ID is required"), | ||
| a_interface: z.string().min(1, "A-side interface is required"), | ||
|
|
||
| // B-side termination | ||
| b_device_id: z.string().min(1, "B-side device ID is required"), | ||
| b_interface: z.string().min(1, "B-side interface is required"), | ||
|
|
||
| // Cable properties | ||
| type: CableTypeSchema.optional(), | ||
| color: z | ||
| .string() | ||
| .regex( | ||
| HEX_COLOUR_PATTERN, | ||
| "Color must be a valid hex color (e.g., #FF5500)", | ||
| ) | ||
| .optional(), | ||
| label: z.string().max(100).optional(), | ||
| length: z.number().positive().optional(), | ||
| length_unit: LengthUnitSchema.optional(), | ||
| status: CableStatusSchema.optional(), | ||
| }) | ||
| .passthrough(); |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Ze CableSchema is vell constructed, but I spy a minor concern.
Ze schema correctly validates all cable properties and uses HEX_COLOUR_PATTERN as previously suggested. However, I notice zat length and length_unit are validated independently. A cable vith length: 10 but no length_unit vould pass validation, leaving ze unit ambiguous.
Consider adding a refinement to ensure zey are provided together:
🔎 Proposed refinement for length/unit coupling
export const CableSchema = z
.object({
// ... existing fields ...
length: z.number().positive().optional(),
length_unit: LengthUnitSchema.optional(),
status: CableStatusSchema.optional(),
})
- .passthrough();
+ .passthrough()
+ .refine(
+ (data) => (data.length === undefined) === (data.length_unit === undefined),
+ {
+ message: "length and length_unit must be provided together",
+ path: ["length"],
+ }
+ );🤖 Prompt for AI Agents
In src/lib/schemas/index.ts around lines 318 to 345, the CableSchema allows
length and length_unit to be provided independently which can leave units
ambiguous; add a schema-level refinement after the .passthrough() (or before
finalizing) that enforces they are either both present or both absent (e.g.,
validate that (length === undefined && length_unit === undefined) || (length !==
undefined && length_unit !== undefined)), and return a clear validation message
(such as "Both length and length_unit must be provided together") with the error
path pointing to length_unit (or both) so invalid objects fail validation when
one field is missing.
- Add length/length_unit cross-field validation refinement to CableSchema - Expand validateCable JSDoc to explain export is for unit testing - Add test for length_unit required when length is specified Fixes CodeRabbit nitpick comments on PR #355 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
src/lib/stores/cables.svelte.ts (1)
46-143: Ze validation logic is thorough and correct, my friend!Ze
validateCablefunction properly validates:
- Device existence on both A and B sides
- Interface existence vhen device types define interfaces
- Duplicate cables in both directions (very important for data integrity!)
- Self-referential connections
Ze JSDoc documentation has been updated as previously suggested. Vell done!
Ze past review suggested adding debug logging vhen a cable references an interface on a device type vithout explicit interface definitions (lines 76-88 and 91-105). Zis remains a valid enhancement for debugging, but is optional.
src/lib/schemas/index.ts (1)
318-358: Ze CableSchema is vell-constructed vith proper cross-field validation!Ze refinement (lines 346-358) ensures
length_unitis required vhenlengthis specified—zis vas addressed from a previous review. Ze use ofHEX_COLOUR_PATTERNconstant is also correct.One observation, my nocturnal friend: ze refinement is asymmetric—it allows
length_unitvithoutlength, but not vice versa. Zis seems semantically odd (vhy specify a unit vith no measurement?). If zis is intentional for flexibility, consider documenting it; ozervise, you may vant to make ze validation bidirectional:🔎 Optional: Bidirectional length/length_unit validation
.refine( (data) => { - // If length is provided, length_unit must also be provided - if (data.length !== undefined && data.length_unit === undefined) { - return false; - } - return true; + // Both must be provided together or both omitted + return (data.length === undefined) === (data.length_unit === undefined); }, { - message: "length_unit is required when length is specified", - path: ["length_unit"], + message: "length and length_unit must be provided together", + path: ["length"], }, );
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
src/lib/schemas/index.tssrc/lib/stores/cables.svelte.tssrc/tests/cables.test.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js,svelte}
📄 CodeRabbit inference engine (CLAUDE.md)
Use TypeScript strict mode
Files:
src/lib/stores/cables.svelte.tssrc/lib/schemas/index.tssrc/tests/cables.test.ts
**/*.{ts,tsx}
📄 CodeRabbit inference engine (CLAUDE.md)
NetBox-compatible field naming: use snake_case for field names (e.g.,
u_height,device_type,form_factor) in data models
Files:
src/lib/stores/cables.svelte.tssrc/lib/schemas/index.tssrc/tests/cables.test.ts
🧬 Code graph analysis (3)
src/lib/stores/cables.svelte.ts (3)
src/lib/schemas/index.ts (3)
CableType(560-560)LengthUnit(562-562)CableStatus(561-561)src/lib/types/index.ts (4)
CableType(158-177)LengthUnit(187-187)CableStatus(182-182)Cable(299-328)src/lib/stores/layout.svelte.ts (3)
getLayoutStore(103-226)rack(112-114)device_types(115-117)
src/lib/schemas/index.ts (1)
src/lib/types/index.ts (3)
CableType(158-177)CableStatus(182-182)LengthUnit(187-187)
src/tests/cables.test.ts (3)
src/tests/factories.ts (1)
createTestDeviceType(81-115)src/lib/schemas/index.ts (4)
CableTypeSchema(159-179)CableStatusSchema(184-188)LengthUnitSchema(193-193)CableSchema(318-358)src/lib/stores/cables.svelte.ts (4)
validateCable(46-143)getCableStore(150-357)cables(331-333)CreateCableInput(13-24)
🔇 Additional comments (15)
src/lib/stores/cables.svelte.ts (7)
1-24: LGTM! Ze imports and interface are vell-structured, my friend.Ze
CreateCableInputinterface correctly mirrors zeCabletype vithout zeidfield, and uses snake_case for NetBox compatibility as required by ze coding guidelines. Ze imports are minimal and appropriate for ze module's responsibilities.
26-32: Ze validation result interface is simple and effective.A clean design, my nocturnal friend! Ze
CableValidationResultprovides exactly vhat is needed—a boolean flag and an array of error messages. Zis is ze vay.
145-159: LGTM! Ze store factory and getCables are properly implemented.Ze use of
layout.cables ?? []correctly handles ze case vhen cables array is undefined, returning an empty array. Zis is defensive programming at its finest, like a vampire's fortress!
194-225: Ze addCable function is vell-structured vith proper validation.I appreciate ze discriminated union return type
{ cable: Cable; errors: null } | { cable: null; errors: string[] }. Zis ensures type safety vhen consuming ze result—ze caller must check vhich variant zey received. Very elegant, like a moonlit castle!
231-262: Ze updateCable validation logic has a subtle consideration.Ze function only validates vhen endpoint fields are being changed (lines 245-255). Zis is correct for performance, but note zat partial endpoint updates could create invalid combinations. For example, changing only
a_device_idvhile keepinga_interfacecould result in an interface zat doesn't exist on ze new device.Ze current implementation handles zis correctly because
validateCablereceives ze fully mergedupdatedobject (line 251), so all endpoint fields are validated together. Vell done, my friend!
283-299: Ze batch removal optimization has been implemented as suggested.Ah, I see ze previous review vas heeded! Ze
removeCablesByDevicenow uses a singleremoveCablesRawcall vith a Set of IDs, instead of callingremoveCableRawin a loop. Zis is much more efficient for devices vith many cables—no more rebuilding ze entire layout for each removal!Ze ESLint disable comment (line 292-293) is appropriate since ze Set is used immediately for filtering, not as reactive state.
329-357: Ze store return object is comprehensive and vell-organized.Ze returned object provides:
- Reactive getter for cables
- Query methods (getCableById, getCablesByDevice, getCablesByInterface)
- CRUD operations vith validation
- Raw operations for undo/redo
- A validateCable vrapper zat automatically provides current cables
Ze validateCable vrapper (lines 350-355) is a nice touch—it encapsulates ze current cables list so consumers don't need to fetch it zemselves.
src/lib/schemas/index.ts (3)
156-193: Ze NetBox-compatible enum schemas are correctly defined, my friend!Ze
CableTypeSchema,CableStatusSchema, andLengthUnitSchemaall align perfectly vith ze types defined insrc/lib/types/index.ts. Ze cable types cover copper Ethernet, DAC, fiber, AOC, power, and serial—a comprehensive selection for datacenter cabling!
513-513: Ze layout schema extension is correct.Adding
cables: z.array(CableSchema).optional()properly integrates cable validation into ze layout vhile maintaining backward compatibility vith existing layouts zat don't have cables. Vell done!
560-563: Ze type exports follow ze established pattern.Ze inferred types are exported consistently vith ze rest of ze file.
CableZodfollows ze naming convention ofDeviceTypeZod,RackZod, etc. Perfect!src/tests/cables.test.ts (5)
1-72: Ze test fixtures are vell-designed for comprehensive testing.Ze helper functions create minimal but complete test data. Ze
createTestLayoutprovides two devices vith defined interfaces, enabling full validation testing. Ze type assertion on line 26 (as "1000base-t") is acceptable for test fixtures.One small note: ze test layout uses
cables: [](line 71), vhich is good for ensuring a clean state, but some tests later override zis. Zis is ze correct approach!
74-268: Excellent coverage of ze schema validation, my friend!Ze tests comprehensively cover:
- All valid enum values for cable types, statuses, and length units
- Invalid enum value rejection
- Required field validation (id)
- Hex colour format validation (both valid and invalid)
- Positive length requirement
- Ze critical cross-field validation for length/length_unit (lines 256-266)
Particularly good is ze test on line 265 zat verifies ze exact error message
"length_unit is required". Zis ensures ze error guidance is correct for users!
270-435: Ze validateCable tests are thorough and cover critical edge cases!I particularly appreciate:
- Ze reversed endpoint duplicate test (lines 365-387)—zis ensures cables cannot be duplicated by simply svapping A and B sides
- Ze self-connection test (lines 410-422) vs. ze loopback test (lines 424-433)—correctly distinguishing between connecting an interface to itself (invalid) and connecting two different interfaces on ze same device (valid)
- Ze excludeCableId test (lines 389-408) for update scenarios
Zese edge cases are often missed but are critical for data integrity!
437-557: Ze getter tests properly cover both positive and negative scenarios.Each getter is tested for:
- Ze happy path (data exists and is returned correctly)
- Ze edge case (no data or not found returns empty/undefined)
Ze test setup correctly manipulates ze layout store to create ze necessary test conditions. Vell structured!
698-735: Ze removeCablesByDevice tests complete ze test coverage.Zese tests verify ze batch removal functionality zat vas optimized per previous review feedback. Ze tests confirm:
- All cables connected to a device are removed
- Ze correct count is returned
- No errors vhen no cables are connected
Zis functionality is essential for maintaining data integrity vhen devices are removed from ze rack!
- Add debug.warn() logging when cable validation skips interface checks for device types without explicit interface definitions - Add dirty state tests for updateCable and removeCable operations 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary
Files Changed
src/lib/types/index.ts- Cable, CableType, CableStatus, LengthUnit typessrc/lib/schemas/index.ts- CableSchema, CableTypeSchema, CableStatusSchema, LengthUnitSchemasrc/lib/utils/yaml.ts- Cable serialization with field orderingsrc/lib/stores/cables.svelte.ts- Cable store with CRUD and validationsrc/tests/cables.test.ts- 42 tests covering schema and storeTest Plan
Closes #261
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Tests
✏️ Tip: You can customize this high-level summary in your review settings.