You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working with this SDK and noticed an inconsistency between the SignalQuality interface definition and the actual data structure returned by the Neurosity API.
According to the SDK, the SignalQuality interface is defined as follows:
This definition suggests that the object keys should be channel names (e.g., CP3, C3, etc.). However, the actual data I received
from the Neurosity API is indexed by numbers, as shown below:
[ChannelQuality, ChannelQuality, ...]
This discrepancy leads to type errors when trying to access the signal quality data in a Typescript project. To resolve this issue, I propose updating the SignalQuality interface to match the actual data structure returned by the API. Here's a possible revision:
Alternatively, if the API is supposed to return channel names as keys and the current numeric indexing is a bug, it would be great to have that fixed on the API side.
I believe aligning the SDK's type definitions with the actual data structure is crucial for providing a seamless development experience. I'm looking forward to your thoughts on this matter.
Reproduction
The device type: CROWN 3
The text was updated successfully, but these errors were encountered:
iharuya
changed the title
API Error: Signal Quality
Align SignalQuality Interface with Actual API Data Structure
Mar 24, 2024
Hello Neurosity team,
I've been working with this SDK and noticed an inconsistency between the SignalQuality interface definition and the actual data structure returned by the Neurosity API.
According to the SDK, the SignalQuality interface is defined as follows:
This definition suggests that the object keys should be channel names (e.g., CP3, C3, etc.). However, the actual data I received
from the Neurosity API is indexed by numbers, as shown below:
[ChannelQuality, ChannelQuality, ...]
This discrepancy leads to type errors when trying to access the signal quality data in a Typescript project. To resolve this issue, I propose updating the SignalQuality interface to match the actual data structure returned by the API. Here's a possible revision:
Alternatively, if the API is supposed to return channel names as keys and the current numeric indexing is a bug, it would be great to have that fixed on the API side.
I believe aligning the SDK's type definitions with the actual data structure is crucial for providing a seamless development experience. I'm looking forward to your thoughts on this matter.
Reproduction
The device type: CROWN 3
The text was updated successfully, but these errors were encountered: