Typesafe userdata in typescript

[gunhaxxor]

Added possibility for the user to provide the shape of the user data with a type parameter when calling app.ws(). Like so:

type UserData = {
    info: string,
    token: string
}

uWebSockets.App().ws<UserData>(xxxx)

There has been a few attempts at this earlier that has been rejected for various reasons. Hopefully this PR checks all requirements. Let me know if/what is wrong or bad and I'll look into it 👍

Notes:

• From earlier discussions I've gathered that it's important that the provided userdata mustn't be constructible (I.E have some kind of constructors). Thus I have made it so that the provided user data interface/type is required to be a plain object with primitive javascript types.
• There was a wish from @uNetworkingAB to keep Websocket as an interface instead of a type alias. Unfortunately this isnt possible (I think), since interfaces don't support mapped types or can extend it's own generic type parameter. I guess the main reason for keeping Websocket an interface is to make it more clean in the generated documentation? If thats the case I personally believe this is worth the tradeoff.
• There have also been discussions on whether to have the type parameter optional or not. That is, if there should be a default type used if none is provided. I tried to not provide a default type and it seems to me that then typescript assumes the unknown type. To me this seems bad so I kept the default type as { [key:string]: any } which is the type used as of now in the Websocket interface

[uNetworkingAB]

export interface WebSocket { export type WebSocket = {

Why is WebSocket now a type? What's wrong with interface?

export interface HttpResponse { export interface HttpResponse<T = {}> {

This can't be correct. There is no T in HttpResponse.

[uNetworkingAB]

Also, for documentation T is a bad name please make it UserData like before. T is for brevity

[gunhaxxor]

As I've written above:

There was a wish from @uNetworkingAB to keep Websocket as an interface instead of a type alias. Unfortunately this isnt possible (I think), since interfaces don't support mapped types or can extend it's own generic type parameter. I guess the main reason for keeping Websocket an interface is to make it more clean in the generated documentation? If thats the case I personally believe this is worth the tradeoff.

Unfortunately I can't find a way to make the generic work while keeping the Websocket an interface. The problem boils down to interfaces in typescript being rather restrictive in how they can use/interact with the provided type parameter.

Regarding the generic on the httpResponse. There are to the best of my knowledge two options:

• Do what I've done here in this PR and make httpResponse a generic. Then it can pass the type from the ws function down to the upgradr function. This is the only way I'm aware of using typescript to align the userdata type for the ws function with the type inferred in the upgrade function.
• Avoid making httpResponse a generic. Instead let the upgrade function be a generic. This would require the users to manually align the types of the input side (upgrade function) and the consuming side (websocketbehaviour typed from the ws function). That is, the users would manually have to provide the same type to both the ws function and to the upgrade function.

[uNetworkingAB]

Avoid making httpResponse a generic

Yep. Look at the C++ example there are two places you specify PerSocketData

https://github.com/uNetworking/uWebSockets/blob/4821d090fed3385ff1c3a76789b1de3fe2491ca7/examples/UpgradeSync.cpp#L36

[uNetworkingAB]

I made some basic changes and added getUserData() and now the following works nicely:

import * as uWS from "uWebSockets.js";

let app = uWS.App();

interface UserData {
    myMember: number;
}

app.ws<UserData>("/", {
    open: (ws) => {
        ws.getUserData().myMember = 13;
    }
});

This is the same interface as C++ so that's great

[gunhaxxor]

This is great! I think the API is even cleaner with the getUserData() as the userdata is then not intermingled with the properties on the websocket instance 👍

I guess the upgrade examples should be updated? I could probably submit a PR for that when I get some time over, but right now I'm quite overloaded with work 😐