-
Notifications
You must be signed in to change notification settings - Fork 47
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
sse syntax update concept #311
base: master
Are you sure you want to change the base?
Conversation
pkieltyka
commented
Sep 30, 2024
- AbortController will automatically be created if one is not passed in
- Stream call returns the abort function on the controller, and also a .wait in case someone wants to block until the connection is done..? maybe we think of another name, and perhaps this isn't very useful or we should modify this to a fan out thing, as I imagine if its called multiple times, it won't work very well..
- the primary reason for this change though is to simplify how developers need to think about the AbortController and instead return it as part of the API as the default option while preserving previous functionality / capability
const stream = api.subscribeMessages( | ||
{ username }, | ||
{ onMessage, onError, onOpen, onClose }//, signal: controller } | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how the returned stream.abort()
reads if you don't provide your own 👍
const resp = _fetch(); | ||
return { | ||
abort: abortController.abort.bind(abortController), | ||
wait: resp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we have onClose()
, perhaps we don't need this wait
return argument
or is there a use-case for awaiting stream right away and blocking on the operation? is it idiomatic?
await stream.closed
this would have to raise exception, that you can normally get through onError()
@AlexanderKolberg thoughts?
export interface WebrpcOptions { | ||
headers?: HeadersInit; | ||
signal?: AbortSignal; | ||
controller?: AbortController; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed from signal
to controller
here. Let me know if you guys think this is fine or if it breaks any functionality / uses from before?
4ca8d74
to
1be7c9f
Compare