zwave-js / zwave-js-ui / 31114491226

12%

push

github

perf(api): call `getDefinedValueIDs` once per node ready (#4778)

## Problem

`_onNodeReady` calls `zwaveNode.getDefinedValueIDs()` once, then runs
`_addValue` for every value. `_addValue` → `_parseValue`, and
`_parseValue` called `getDefinedValueIDs()` *again* for every value
whose `propertyName` matches `/current/i`, purely to pass the list to
`_findTargetValue`.

On large multi-endpoint nodes that makes node-ready handling O(n²) and
blocks the driver's event loop for seconds. See zwave-js/zwave-js#9024.

## Change

Thread the already-computed array from `_onNodeReady` through
`_addValue` into `_parseValue` as an optional parameter:

```ts
this._findTargetValue(valueId, definedValueIds ?? zwaveNode.getDefinedValueIDs())
```

The other entry points don't have the array and fall back to a single
lazy call, unchanged in behavior:

- `_onNodeValueAdded` → `_addValue(zwaveNode, args)`
- `_updateValue` → `_addValue(zwaveNode, args)`
- `_onNodeMetadataUpdated` → `_parseValue(zwaveNode, args,
args.metadata)`

The fallback stays inside the `_isCurrentValue` branch, so nodes with no
current values still never call it.

## Behavior

None intended. `_findTargetValue` is untouched, and the array passed on
the ready path is the same one `getDefinedValueIDs()` would have
returned a moment later, so target-value resolution produces identical
results.

## Testing

`npx tsc --noEmit` and eslint on the changed file are clean. `test/lib/`
has no `ZwaveClient` test, so there was no `_parseValue` harness to
extend.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

493 of 4533 branches covered (10.88%)

Branch coverage included in aggregate %.

938 of 7002 relevant lines covered (13.4%)

2.08 hits per line