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.
-
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