You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 29, 2021. It is now read-only.
The functionality that reloads the page in the browser after rebuilds is implemented in the hot-code-push, autoupdate, and reload packages and uses a DDP WebSocket. Since these packages are always included in the client and server bundles, they can be used during development and in production. However, some apps only need them during development, for example if they use Apollo instead of Meteor pub/sub or if they don't use Cordova. If DDP and auto-reloading aren't used in production, this results in up to 90 kB of unused code in the client bundle and an unused DDP WebSocket connection for each active client.
Solution
We can implement development-only auto-reloading directly in the Meteor Tool by creating a WebSocket server for this functionality in Meteor's development proxy (similar to what other tools like webpack-dev-server are doing). I've started to implement a simple version of this concept as part of meteor/meteor#10505 (see the "Technical Details" and "Future Work" sections for details). This solution can be backwards-compatible and opt in: If autoupdate is included in an app, the Meteor Tool would continue to use the current system; otherwise, it would use the development proxy for auto-reloading.
Advantages
Smaller bundles for apps that don't use DDP
No unused WebSocket connections for apps that don't use DDP
There are already three packages related to auto-reloading (hot-code-push, autoupdate, and reload). Implementing this FR would add another package and increase the complexity of the Meteor Tool.
The text was updated successfully, but these errors were encountered:
Also interesting is that this might decrease latency for hot-reload. If client is just in the process of sending a large chunk of data, hot-reload could happen in parallel instead over a parallel connection.
Problem
The functionality that reloads the page in the browser after rebuilds is implemented in the
hot-code-push
,autoupdate
, andreload
packages and uses a DDP WebSocket. Since these packages are always included in the client and server bundles, they can be used during development and in production. However, some apps only need them during development, for example if they use Apollo instead of Meteor pub/sub or if they don't use Cordova. If DDP and auto-reloading aren't used in production, this results in up to 90 kB of unused code in the client bundle and an unused DDP WebSocket connection for each active client.Solution
We can implement development-only auto-reloading directly in the Meteor Tool by creating a WebSocket server for this functionality in Meteor's development proxy (similar to what other tools like
webpack-dev-server
are doing). I've started to implement a simple version of this concept as part of meteor/meteor#10505 (see the "Technical Details" and "Future Work" sections for details). This solution can be backwards-compatible and opt in: Ifautoupdate
is included in an app, the Meteor Tool would continue to use the current system; otherwise, it would use the development proxy for auto-reloading.Advantages
Disadvantages
hot-code-push
,autoupdate
, andreload
). Implementing this FR would add another package and increase the complexity of the Meteor Tool.The text was updated successfully, but these errors were encountered: