URI generics default to Uri; ConfigBuilder accepts string | Uri where possible#81
URI generics default to Uri; ConfigBuilder accepts string | Uri where possible#81krisbitney wants to merge 5 commits intoorigin-devfrom
Uri; ConfigBuilder accepts string | Uri where possible#81Conversation
…ccepts Uri | string when possible
krisbitney
requested review from
dOrgJelli,
namesty and
nerfZael
as code owners
krisbitney
changed the title
Uri; ConfigBuilder accepts string | Uri wherepossibleUri; ConfigBuilder accepts string | Uri where possible
…nference # Conflicts: # yarn.lock
|
|
||
| @Tracer.traceMethod("PolywrapClient: invoke") | ||
| public async invoke<TData = unknown, TUri extends Uri | string = string>( | ||
| public async invoke<TData = unknown, TUri extends Uri | string = Uri>( |
There was a problem hiding this comment.
Changing the default to Uri doesn't fix #79 , it just flips the coin and requires you to have a Uri instance if you specify a return type.
The problem is that if you specialize the generic with the first template argument, the second one appears to be required. Instead of using a template argument for TUri maybe we should just make the actual argument type options: InvokerOptions<Uri | string> and we can determine the type within the function's body. This way if you specialize the first template argument, there isn't a second one that needs to be specified as well.
There was a problem hiding this comment.
Okay, my mistake. I misunderstood. I read "...instead of String we should support that the default is Uri" and thought we just wanted to modify the generic type. I changed everything to use union types instead, so we should be good to go.
…nference # Conflicts: # yarn.lock
2 participants
Generic URI types in client are now a union type
Uri | stringCloses #79