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
In a worker, I commonly use a pattern of calling durable objects from an API worker - when the DOs respond, they either contain a response type (e.g. a serializable object) or a Response type. I use a utility method to split these types similar to a safe assignment operator. Ideally, my code looks like this:
conststub=ctx.DURABLE_OBJECT.get(ctx.DURABLE_OBJECT.idFromName("some-name"));const[response,fooInfo]=awaittryResponse(stub.method("foo"));if(response){returnresponse;}// fooInfo is guaranteed and typed
Note that the DO in the above example would be something like:
ctx.STUB does not appear to return typed stubs when I use wrangler types in a project with non-local DOs, even if I provide a path to the DO definition directly via script_name. This feels like a pretty obvious shortcoming, or is the expectation that you'd only use RPC via a single worker that exposes its own DOs? I've worked around this by using a shim for the type, not the end of the world.
tryResponse is typed similarly to this playground, and has a return type of (roughly) Awaited<[Response, undefined] | [undefined, T]> where T is Exclude<ReturnType<StubMethod>, Response>.
This should in theory allow me to pass a stub method result to it - and indeed, if I pass something typed as ReturnType<MyDOClass["method"]> to it, the types are correct. However, when I call with tryResponse(stub.method("foo")), I get a Type instantiation is excessively deep and possibly infinite error. I can workaround this as well by using this shim:
However, this results in the following code, which is bailing out of a lot of the type system:
constrepoStub=getStub<MyDOClass>(DURABLE_OBJECT,DURABLE_OBJECT.idFromName("some-name"));const[response,fooInfo]=awaittryResponse(stub.method("foo")asStubCall<MyDOClass,"method">);if(response){returnresponse;}// fooInfo is guaranteed and typed
There is some help here, but it's quite repetitive and ideally the first block of code has enough info to generate the correct types without TS failing due to complexity.
I'll try consolidating to a single project to fix issue #1 (is that really the recommended approach?), but I suspect that I'll still have issue #2 regardless, due to the complex type inference. What are my options here?
The text was updated successfully, but these errors were encountered:
In a worker, I commonly use a pattern of calling durable objects from an API worker - when the DOs respond, they either contain a response type (e.g. a serializable object) or a
Response
type. I use a utility method to split these types similar to a safe assignment operator. Ideally, my code looks like this:Note that the DO in the above example would be something like:
This has a number of issues. In order:
ctx.STUB
does not appear to return typed stubs when I usewrangler types
in a project with non-local DOs, even if I provide a path to the DO definition directly viascript_name
. This feels like a pretty obvious shortcoming, or is the expectation that you'd only use RPC via a single worker that exposes its own DOs? I've worked around this by using a shim for the type, not the end of the world.Awaited<[Response, undefined] | [undefined, T]>
whereT
isExclude<ReturnType<StubMethod>, Response>
.This should in theory allow me to pass a stub method result to it - and indeed, if I pass something typed as
ReturnType<MyDOClass["method"]>
to it, the types are correct. However, when I call withtryResponse(stub.method("foo"))
, I get aType instantiation is excessively deep and possibly infinite
error. I can workaround this as well by using this shim:However, this results in the following code, which is bailing out of a lot of the type system:
There is some help here, but it's quite repetitive and ideally the first block of code has enough info to generate the correct types without TS failing due to complexity.
I'll try consolidating to a single project to fix issue #1 (is that really the recommended approach?), but I suspect that I'll still have issue #2 regardless, due to the complex type inference. What are my options here?
The text was updated successfully, but these errors were encountered: