Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

IHttpConnectionOptions and IHubConnectionOptions aren't exposed #875

Closed
BrennanConroy opened this issue Sep 13, 2017 · 9 comments
Closed

Comments

@BrennanConroy
Copy link
Member

BrennanConroy commented Sep 13, 2017

There is no way to new up a class that implements either IHttpConnectionOptions or IHubConnectionOptions 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.

@BrennanConroy
Copy link
Member Author

Also IConnection and IHubProtocol aren't exposed.

@moozzyk
Copy link
Contributor

moozzyk commented Sep 13, 2017

I am not sure if IConnection and IHubProtocol need to be exposed.

@BrennanConroy
Copy link
Member Author

How do you write your own BetterMessagePack protocol then? Or implement SuperFastUDP connection?

@moozzyk
Copy link
Contributor

moozzyk commented Sep 13, 2017

For now we treat protocols as an internal thing (that's why IHubProtocol is in the Internal namespace)

@moozzyk
Copy link
Contributor

moozzyk commented Sep 13, 2017

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.

@moozzyk moozzyk self-assigned this Sep 15, 2017
@muratg muratg added this to the 2.1.0-preview1 milestone Sep 21, 2017
@andreimcristof
Copy link

andreimcristof commented Oct 1, 2017

+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()

@moozzyk
Copy link
Contributor

moozzyk commented Oct 1, 2017

@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

@andreimcristof
Copy link

@moozzyk thank you for the detailed explanation. cheers

@BrennanConroy
Copy link
Member Author

This was done in @anurse's refactor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants