-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
feat: native support for Websockets #12973
base: main
Are you sure you want to change the base?
Conversation
…ionality for different handlers at different URLs, added example use cases to options-2 test app, added upgrade function for supporting additional adapters, and much more.
|
preview: https://svelte-dev-git-preview-kit-12973-svelte.vercel.app/ this is an automated message |
@@ -685,8 +686,8 @@ export interface KitConfig { | |||
*/ | |||
export type Handle = (input: { | |||
event: RequestEvent; | |||
resolve(event: RequestEvent, opts?: ResolveOptions): MaybePromise<Response>; | |||
}) => MaybePromise<Response>; | |||
resolve(event: RequestEvent, opts?: ResolveOptions): MaybePromise<void | ResponseInit | Response>; |
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.
Is returning void
or a ResponseInit
important to cancel the websocket connection? This would be a breaking change.
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.
Its as I mentioned on Discord, returning a Response
aborts the Websocket upgrade, and returning a headers
object (or maybe more?) accepts the upgrade request, I'm not certain on the void
bit here but that was their typing.
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 do think there is a path to improving the dev experience here, we have an issue logged on the crossws repo to discuss further.
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.
Related to unjs/crossws#88
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.
Same, would love to keep this as is
unjs/crossws#90
@@ -0,0 +1,39 @@ | |||
let sockets = []; | |||
|
|||
export const socket = { |
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.
export const socket = { | |
/** @type {import("crossws").Hooks} */ | |
export const socket = { |
Should we re-export the Hooks
type provided by crossws
? So it becomes something like
/** @type {import("@sveltejs/kit").Socket} */
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 was hoping we could actually type it automatically the same way the GET functions are automatically typed when exported from the same file, I would love to handle that for the users.
I think Ben mentioned that @dummdidumm was the typing expert here, they maybe be able to provide some insight on the best way to get this the last mile here.
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 think the automatic typing is part of the Svelte language tools VS Code extension so we would still need the manual typing available here.
This PR is a replacement to #12961 with a completely different Websocket implementation using
crossws
that should be fully compatible with all major runtimes.Functionality has been validated locally using basic tests in a test app.
Here is the new usage experience.
+server.js
The newest implementation allows different sets of handlers to be implemented on a per-route basis. I have tested some basic uses of websockets locally to much success.
This PR is intended to:
Resolve #12358
Resolve #1491
Steps left
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.Edits