Skip to content
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.

Sign up for GitHub

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

Jump to bottom

feat(client): add WebSocket connections events #13334

Merged
merged 2 commits into from
Jun 15, 2023
Merged

feat(client): add WebSocket connections events #13334

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
00a98f8
feat(client): add WebSocket connections events
antfu May 24, 2023
a356e4d
docs: update
antfu Jun 15, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/guide/api-hmr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -176,6 +176,8 @@ The following HMR events are dispatched by Vite automatically:
- `'vite:beforePrune'` when modules that are no longer needed are about to be pruned
- `'vite:invalidate'` when a module is invalidated with `import.meta.hot.invalidate()`
- `'vite:error'` when an error occurs (e.g. syntax error)
- `'vite:ws:disconnect'` when the WebSocket connection is lost
- `'vite:ws:connect'` when the WebSocket connection is (re-)established

Custom HMR events can also be sent from plugins. See [handleHotUpdate](./api-plugin#handlehotupdate) for more details.

Expand Down
3 changes: 3 additions & 0 deletions packages/vite/src/client/client.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,7 @@ function setupWebSocket(
'open',
() => {
isOpened = true
notifyListeners('vite:ws:connect', socket)
},
{ once: true },
)
Expand All @@ -99,6 +100,8 @@ function setupWebSocket(
return
}

notifyListeners('vite:ws:disconnect', socket)

console.log(`[vite] server connection lost. polling for restart...`)
await waitForSuccessfulPing(protocol, hostAndPath)
location.reload()
Expand Down
2 changes: 2 additions & 0 deletions packages/vite/types/customEvent.d.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@ export interface CustomEventMap {
'vite:beforeFullReload': FullReloadPayload
'vite:error': ErrorPayload
'vite:invalidate': InvalidatePayload
'vite:ws:connect': WebSocket
'vite:ws:disconnect': WebSocket
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you need the WebSocket instance? It concerns me a bit that WebSocket instance has a broad interface. (e.g. socket.send())

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't required for the original request. @antfu maybe we should add this param once we have a real use case? And once we go there, it could be a Payload object like the others so we could extend it in the future if needed.

Copy link
Member Author

@antfu antfu Jun 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a strong opinion either on having it or not. I was just thinking why not, since we have that information.

A few notes added to the consideration:

  • WebSocket it's a web standard so I don't need to worry about the API been changed
  • If we say web socket is an implementation detail, vite:ws already indicates it's web socket. Later if we really find an alternative way of making the connection, those hooks won't be called so there will be no conflicts like the general vite:connect
  • On the node side, plugins already have logics with WebSocket. It's not really an implementation detail we can't reveal.

I don't expect this will be changed and won't add much maintenance interface to us.

I do see one downside is that ppl might start using it and mess it around to break Vite - and then send requests to support very niche usages. But that could happen everywhere and we need to prevent that for sure.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good points, I think we can talk about this in the next team meeting 👍🏼
I assume you also don't think it is a good idea to have a Payload object here.

}

export interface InvalidatePayload {
Expand Down