-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable clients #624
Comments
perhaps the contructor should just accept a transport instance instead of configurations? either/or? |
Yeah I think you're leaning the right way on that . I think RequestManager should stay encapsulated because we don't want to leak those internals, and we should have a request option. createTransport(...)=>Transport
/* Takes all the transport config data that gets handle in the constructor and instead is handled by createTransport. This is exported but not the underlying transports, so outside of the generic interface,
there shouldn't be transport construction going on outside of the method.
So we can keep tweaking the internal representation
*/ const transport = [createTransport({host,port,type,path},options)]
new Client(transports,{nextId: ()=> string | int}) Curious on what you think or is this what you're think as well ? |
yep, I think thats the idea. As an addition to that, we would probably be able to add configurability from the generator config file (in here: https://github.com/open-rpc/generator/blob/master/test-generator-config.json#L6). This would allow users to produce a generated result that has some preset headers (so that the end-user doesn't need to muck around with passing in the same options every time) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Generated clients lack the ability to configure the various components of the client (RequestManager, Transport, Client itself).
An example of this issue is that there is no ability to set the http transport headers.
The solution should allow for runtime, as well as generate-time configuration of these items.
at runtime, the options should be allowed via constructor params.
at generate time, the options should be pulled from the generator config for the component.
The text was updated successfully, but these errors were encountered: