• Meteor

How the Autoupdate Package Works

A new package on the development branch of Meteor, called Auto Update, is what's responsible for automatically having our browser reload itself if the client side code has changed. It uses the Reload package to do this. In this opposable, we'll look at how Auto Update works. Let me give you a quick tour of the Auto Update source code, and then we'll jump over to an application and see it actually working.

On the left, I have the server side code for Auto Update, and on the right, I've got the client side code. So there's really only two files for this package. Over in the right in the client, you can see where the Auto Update package calls the reload method of the Reload package. This is what causes the browser to reload, and to get a hint as to what's going on, you can see that it's searching a private collection called Client Versions. And it's searching for a record where the current property is true and where the Auto Update version is different from the one that we currently have stored in the browser. I'll show you that in action in a little while.

Over on left, you can see that the server side publishes out a Meteor underscore Auto Update underscore client versions publication. And it's responsible for publishing out the latest client version to all of the connected clients. You can see how it does this up at the top when your server starts up, it looks for Auto Update version as an environment variable, and if that's not available, it looks for the server ID as an environment variable. Otherwise, it uses the SHA hash of your web application. And then it sets that value as the Auto Update version property on the media runtime config and then publishes out the value to connected clients using the Meteor Auto Update client versions publication.

I fired up the standard application with Hello World. The first thing I want to do is to right click in the browser and look at the page source. At the top, you can see inside of a script tag that there's a property added to media runtime config called Auto Update version, and its value is this Shaw hashtag. Now let's go into the HTML file and make a change. I'll just add an H2 tag and type in "changed" and save the file. Now back in the browser, If I right click you can see the change method at the top, but if I right click and I say "view page source," we can look at the Auto Update version now and see that it's changed. So the first few digits are five six two, and if I look over at the old version, it's eight eight a. Eight a eight.

I've opened up the client side JavaScript file for the Auto Update package so that we can see how this is working. When we update a code file on the server that affects the client, the server gets restarted, and so at first the web browser is unable to connect. And so it just goes into a waiting state. When the web browser reconnects, it gets an updated client version from subscribing to the Meteor Auto Update client versions subscription.

And you can see it in the on ready callback of that subscription inside of Adepts Auto Run. This package searches the client versions collection for the current version, and if it's different than the one that we have, it calls the package Reload reload method. And this is what causes the browser to reload and before it does that, just like in the previous video, each package has a chance to say whether it's ready to reload or not by using the on migrate method of the Reload package.

In this video, we looked at how the Auto Update package works hand in hand with the Reload package. The Auto Update package will publish out a new Shaw hash if the client code changed and needs to be reloaded. On the client side, if it detects that the client code has changed, or the Auto Update version has changed , it calls the reload method the Reload package. And then the normal migration process continues.