new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Vite · Guide · all subjects

hmr and client api

9 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

server.ws fallback avoidance strategies

To avoid the WebSocket fallback error, you could either: (1) configure the reverse proxy to proxy WebSocket too, (2) set 'server.strictPort = true' and set 'server.ws.clientPort' to the same value with 'server.port', or (3) set 'server.ws.port' to a different value from 'server.port'.

server.ws example configuration

Example of server.ws configuration: ```js export default defineConfig({ server: { ws: { protocol: 'wss', host: 'localhost', port: 3001, }, }, }) ```

server.ws WebSocket fallback behavior with reverse proxies

With the default configuration, reverse proxies in front of Vite are expected to support proxying WebSocket. If the Vite HMR client fails to connect WebSocket, the client will fall back to connecting the WebSocket directly to the Vite HMR server bypassing the reverse proxies, showing the message 'Direct websocket connection fallback. Check out https://vite.dev/config/server-options.html#server-ws to remove the previous connection error.'

server.hmr HMR behavior configuration

server.hmr is of type 'boolean | { overlay?: boolean }'. It can be used to disable or configure HMR behavior. Set 'server.hmr.overlay' to 'false' to disable the server error overlay.

server.hmr WebSocket options deprecated

The WebSocket-related options in server.hmr ('protocol', 'host', 'port', 'path', 'clientPort', 'timeout', 'server') are deprecated. Use 'server.ws' instead. These options are automatically synced, so existing configurations will continue to work.

server.ws WebSocket connection configuration

server.ws is of type 'false | { protocol?: string, host?: string, port?: number, path?: string, timeout?: number, clientPort?: number, server?: Server }'. It configures WebSocket connection options. Set to 'false' to disable the WebSocket connection entirely. Fields: 'protocol' (WebSocket protocol: 'ws' or 'wss'), 'host' (WebSocket server host), 'port' (WebSocket server port), 'path' (WebSocket path), 'clientPort' (override the port on the client side), 'timeout' (connection timeout in milliseconds, default: 30000), 'server' (use a custom HTTP server for WebSocket connections).

server.ws custom HTTP server for WebSocket

When 'server.ws.server' is defined, Vite will process the WebSocket connection requests through the provided server. If not in middleware mode, Vite will attempt to process WebSocket connection requests through the existing server. This can be helpful when using self-signed certificates or when you want to expose Vite over a network on a single port.

Using external Svelte stores to preserve state across HMR

To preserve component state across HMR updates in Vite + Svelte, create an external store using Svelte's writable store. This store will not be replaced by HMR and can retain important state data. Example: import { writable } from 'svelte/store'; export default writable(0)

HMR state preservation disabled in Svelte by default

HMR state preservation is disabled by default in both svelte-hmr and @sveltejs/vite-plugin-svelte due to its often surprising behavior. If you have state that is important to retain within a component, consider creating an external store which would not be replaced by HMR.

Give your agent this brain