You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Streaming support currently seems broken. It generates a file with parse errors for me at least. It looks like there is partial support, going in the direction of using rxjs Observables.
Would it be valuable to agree on the interface of where we(/you) want to go?
Is there a plan for cancellation of streaming RPCs?
We could conditionally add those extra methods to the Rpc interface iff there is a single streaming RPC? Given that it currently doesn't compile if people have a streaming RPC defined, that shouldn't break anyone?
The text was updated successfully, but these errors were encountered:
Do we want to require all methods (serverStreamingRequest, clientStreamingRequest, bidirectionalStreamingRequest) if the user has a single streaming RPC, or do we want to expose all 4 methods iff they're used?
@Jille I like what you did in the PR, re conditionally including the additional methods. If anything it's nice for backwards compatibility (although I'm also fine with breaking changes if necessary, but yeah if we can avoid it). Thanks!
Streaming support currently seems broken. It generates a file with parse errors for me at least. It looks like there is partial support, going in the direction of using rxjs Observables.
Would it be valuable to agree on the interface of where we(/you) want to go?
Is there a plan for cancellation of streaming RPCs?
We could conditionally add those extra methods to the Rpc interface iff there is a single streaming RPC? Given that it currently doesn't compile if people have a streaming RPC defined, that shouldn't break anyone?
The text was updated successfully, but these errors were encountered: