Add type definitions for Request and Response

[ComLock]

No description provided.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.55%. Comparing base (cda1144) to head (7b1f13b).
Report is 10 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master   #10724   +/-   ##
=========================================
  Coverage     84.55%   84.55%           
+ Complexity    19979    19978    -1     
=========================================
  Files          2633     2633           
  Lines         69316    69316           
  Branches       5596     5596           
=========================================
  Hits          58612    58612           
  Misses         8002     8002           
  Partials       2702     2702           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rymsha]

some experimental headers whe really never use. Why are they int default? Why they are different case BTW?

[ComLock]

Default optional, only for autocomplete. These are the ones in chrome.

Dunno what to use them for on the server-side, so probably can be removed.

Are they in the way though?

[edloidas]

I'm not sure that we need experimental headers in the default list. Most of them are not added automatically, and for some, like Sec-CH-UA-Mobile, I don’t even see the point in using them in XP.
My suggestion is as follows: drop them. If a developer really needs them, they can always add them at their own risk.

[ComLock]

I removed the experimental ones and added autocompletion to the Sec-Fetch ones.

I also added Priority since both Chrome and Firefox sends it.

There are tons of headers:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

Not really sure which ones should be part of DefaultRequestHeaders.

[edloidas]

Overall, outstanding work. Great job, Christian. Just a few things to improve there.

[edloidas]

I'm not sure that we need experimental headers in the default list. Most of them are not added automatically, and for some, like Sec-CH-UA-Mobile, I don’t even see the point in using them in XP.
My suggestion is as follows: drop them. If a developer really needs them, they can always add them at their own risk.

[tajakobsen]

Good job! I can see that there has gone in a ton of effort into this!

Is it possible for me to be able to test this in Beta, because I'm interested in seeing if there is a lot of friction when changing from "my" controller types to these.

I would also be interested in seeing how you use these types in your application projects. When you have a beta out, can you try to put them in, so that I can see an example of the intended use from your side?

[tajakobsen]

Looks good. I just have a suggestion around the shape of WebSocetEvent that might be interesting to you.

[tajakobsen]

This is my implementation of WebSocketEvent. It uses a discriminated union based on the type to ensure the shape of the object.

type AbstractWebSocketEvent<WebSocketData> = {
  session: {
    id: string;
    path: string;
    params: { [key: string]: string | undefined };
  };
  data: WebSocketData;
};

export type OpenWebSocketEvent<WebSocketData = {}> = AbstractWebSocketEvent<WebSocketData> & {
  type: "open";
};

export type MessageWebSocketEvent<WebSocketData = {}> = AbstractWebSocketEvent<WebSocketData> & {
  type: "message";
  message: string;
};

export type CloseWebSocketEvent<WebSocketData = {}> = AbstractWebSocketEvent<WebSocketData> & {
  type: "close";
  closeReason: number;
};

export type ErrorWebSocketEvent<WebSocketData = {}> = AbstractWebSocketEvent<WebSocketData> & {
  type: "error";
  error: string;
};

export type WebSocketEvent<WebSocketData = {}> =
  | OpenWebSocketEvent<WebSocketData>
  | MessageWebSocketEvent<WebSocketData>
  | CloseWebSocketEvent<WebSocketData>
  | ErrorWebSocketEvent<WebSocketData>;

Just consider if this pattern might be right for you too?

[ComLock]

My first implementation was similar to that, because it was based on the data I was able to generate in real life. I just simplified after looking at the Java class behind it.