Am I doing something wrong here? When I do
const obs = new OBSWebSocket(); // connect it, etc.
obs.addListener('CustomEvent', arg => {
// "arg" is claimed (by the types) to be:
//
// (parameter) arg: {
// eventData: JsonObject;
// }
};However, as far as I can tell that's patently not the case. You don't get {eventData: JsonValue}, you just get the JsonValue itself straight up. It's not wrapped in an object.
I'm sending my BroadcastCustomEvent properly, wrapped in {eventData: myData}, but I'm just getting myData.
I never noticed this before because all my CustomEvents are migrated from v4, which means they used to have "realm" and "data" values, and so I do an extra type check for it in my code path that listens for all CustomEvents (since ones that don't have that, I can always discard). And doing that silences the obvious type discrepancy, and then I pass it on to a handler that casts it to whatever type that handler expects anyway.
For what it's worth, I think the actual data is the best thing to pass in the callback, as-is. It's just that the type needs to be changed.
Am I doing something wrong here? When I do
However, as far as I can tell that's patently not the case. You don't get
{eventData: JsonValue}, you just get theJsonValueitself straight up. It's not wrapped in an object.I'm sending my BroadcastCustomEvent properly, wrapped in {eventData: myData}, but I'm just getting myData.
I never noticed this before because all my CustomEvents are migrated from v4, which means they used to have "realm" and "data" values, and so I do an extra type check for it in my code path that listens for all CustomEvents (since ones that don't have that, I can always discard). And doing that silences the obvious type discrepancy, and then I pass it on to a handler that casts it to whatever type that handler expects anyway.
For what it's worth, I think the actual data is the best thing to pass in the callback, as-is. It's just that the type needs to be changed.