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.

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(ws): expose on / off for server.ws #5273

Merged
merged 1 commit into from
Oct 13, 2021
Merged

Conversation

antfu
Copy link
Member

@antfu antfu commented Oct 12, 2021

Description

Expose on / off listeners for server.ws for plugins to leverage the events.

Additional context

The main motivation it that the current interface of server.ws is too limited. Let's say if we have a virtual module that needs HMR frequently, I usually mock the ws events by sending (since the virtual module will not have the fs event):

server.moduleGraph.invalidateModule(mod)
server.ws.send({
  type: 'update',
  updates: [{
    acceptedPath: VIRTUAL_ENTRY,
    path: VIRTUAL_ENTRY,
    timestamp: +Date.now(),
    type: 'js-update',
  }],
})

The problem is that it will only be received by clients that already established connections. The first client might get the initial content of the virtual module by the load hook and processed to load other modules, and then after a while the was connect gets established. This means the ws events during the period won't be received by the client and resulting in the old virtual module get served. This requires users to manually refresh the page to get the latest or having an inaccurate timeout to do the hard refresh.

load ---> hmr event (lost) ---> ws connected ---> page ready (the old content is served)

Having the listeners exposed allowing plugins to pending the events and send them as soon as the client is ready (e.g. on('connection') to make the HMR experience seamless.


What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

Before submitting the PR, please make sure you do the following

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines and follow the Commit Convention.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.

@Shinigami92 Shinigami92 added the p2-nice-to-have Not breaking anything but nice to have (priority) label Oct 13, 2021
@antfu antfu merged commit 6f696be into vitejs:main Oct 13, 2021
@antfu antfu deleted the feat/ws-on-off branch October 13, 2021 13:33
aleclarson pushed a commit to aleclarson/vite that referenced this pull request Feb 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p2-nice-to-have Not breaking anything but nice to have (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants