Replies: 2 comments 2 replies
-
Consider following changes. Usage: import { App } from "uWebSockets.js";
interface UserData {
id: number;
name: string;
}
const app = App<UserData>();
app.ws("/*", {
open: (ws) => {
ws.userData = {
id: 0,
name: "Owl",
};
},
message: (ws) => {
ws.userData.id; // number
ws.userData.name; // string
ws.userData.id = "Hello"; // TypeScript compilation error because `id` supposed to be `number`, not `string`
},
}); I think this is a neat feature, temporary work around (that I use) is to create a import "uWebSockets.js";
interface UserData {
id: number;
name: string;
}
declare module "uWebSockets.js" {
interface WebSocket {
userData: UserData;
}
} then you can use it just like the example above (without the generic type when calling |
Beta Was this translation helpful? Give feedback.
-
It's a known problem. TS is a separate layer above JS -> whatever happens in TS, we can't know about or control. We only know about and can change V8/JS. So making template functions that take type UserData is impossible since that information only exists in TS (which is not part of V8/JS). So you can't really implement a typed interface like that. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
In C++ version, uWebSockets has getUserData() while uWebSockets .js has
[key: string]: any;
But their types are any & is not recommended in Typescript. What about this:
We will have the consistent API between C++ & js versions as well as maintain the static type definition for Typescript.
We can also keep the
[key: string]: any;
for who want the convenience of weak typingBeta Was this translation helpful? Give feedback.
All reactions