-
Notifications
You must be signed in to change notification settings - Fork 446
IHttpConnectionOptions and IHubConnectionOptions aren't exposed #875
Comments
Also |
I am not sure if IConnection and IHubProtocol need to be exposed. |
How do you write your own |
For now we treat protocols as an internal thing (that's why IHubProtocol is in the Internal namespace) |
In general we need to rethink our exporting strategy. At the moment it is quite inconsistent. In some cases we export all types from a file/module while in other cases we re-export. We re-export if there are types in the file/module which should not exposed publicly but we should review if this is consistent and if there is a better way of doing this. |
+1, need this as well, I can't find a way without this to pass custom headers through the HubConnection for e.g. authorization header, when using .invoke() |
@andreimcristof - I don't think this issue is related to headers too much. Even if you created a custom IHttpClient it won't really work - it would basically work only for the OPTIONS request. Keep in mind the neither WebSocket nor EventSource allow passing headers. I think you will need to use querystring for passing authorization header. Also, see: #888 and #686 |
@moozzyk thank you for the detailed explanation. cheers |
This was done in @anurse's refactor |
There is no way to new up a class that implements either
IHttpConnectionOptions
orIHubConnectionOptions
because they aren't exported. Looks like we just need to add them to the index.ts file.In general we need to rethink our exporting strategy. At the moment it is quite inconsistent. In some cases we export all types from a file/module while in other cases we re-export. We re-export if there are types in the file/module which should not exposed publicly but we should review if this is consistent and if there is a better way of doing this.
The text was updated successfully, but these errors were encountered: