Introduce context and request options for Durable Objects and modules #67
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introducing 2 new options:
context
andrequest
.context
: Any object that containswaitUntil
and (optionally)request
. This option is the most universal way to instantiatetoucan-js
in any kind of Cloudflare Worker. It can beFetchEvent
,ScheduledEvent
,DurableObjectState
, orcontext
in modular Workers.request
: Because DurableObjectState and .mjs worker's context don't includerequest
, you need to use this option to set it separately. You don't need to use this withFetchEvent
orScheduledEvent
, asrequest
is already included in these.Durable Objects DOs and DON'Ts
It might be tempting to instantiate
toucan-js
in Durable Object's class constructor and set it as a class property. This is not recommended, as it will introduce race conditions and so you'd risk sending metadata of interleavedfetch
events to Sentry. The strategy also wouldn't let you setrequest
, which is not available in the constructor (and I intentionally didn't expose a setter :)).toucan-js
is lightweight and it's fine to instantiate it infetch
handler.DON'T
DO