Make MicroBlocks(browser versions) automatically upgrade

[Wenjie Wu]

I like to use the browser version of MicroBlocks and encourage newbies to use it as well.

One of the great advantages of browser version is always kept up to date. But I've found that for newbies, getting this benefit is not free, because it often requires clearing the browser cache. And many newbies don't know how to clear the cache, even though I prompted that “shift + refresh your browser“. I have observed that some newbies will press the shift key, release it, and then refresh the browser, which leads them to say, "Your suggestion didn't work for me"

I find that one of the great sources of difficulty for many novice programmers is their unfamiliarity with computers, these common sense to experienced users often cause unexpected difficulties.

So I suggest that the browser version should be updated automatically (MakeCode does it and it is very helpful)

These resources may be helpful:

• Web_Workers_API
• Service_Worker_API

@John Maloney @Bernat Romagosa

[John Maloney]

Thanks for the suggesting a service worker. (Service workers can actually make this problem much worse, as I discovered! However, I think careful use of a service worker can make things better.) I'll look into this.

[Wenjie Wu]

Service workers can actually make this problem much worse

I don't know enough about this, but your judgments are usually far-sighted, I think I should learn more.

‌

[John Maloney]

I wasn't saying I wouldn't use a service worker, just that we need to be careful to get it right the first time.

What happened last time I tried using a service worker was that the service worker never updated its cache. In that case, even clearing the browser cache would not force an update. The only way to get out of that situation was to dig into the developer tools and manually clear the service worker's cache, something that I doubt many people know about. (I certainly didn't until I ran into the problem.) On top of that, I'm not quite sure if one can force an update of the service worker itself once it has been deployed. They seem to be be pretty sticky.

In short, when creating a service worker, if we don't get it right the first time users can be semi-permanently stuck running an out-of-date version of MicroBlocks and force-reloading or even clearing their browser cache wouldn't help. And I think very few people other than web developers know how to clear the service worker's data store or delete a misbehaving service worker. I would hate to have to tell people how to do those things...

However,, you're correct that a well-designed service worker will allow us to make sure that users get the latest version if they are online. Once I get a stable release out (soon, I hope), I will explore this option. Thanks for suggesting it.

[John Maloney]

Will look into this later...

[Wenjie Wu]

hmm, It looks like that service worker is stickier than I expected .

a well-designed service worker will allow us to make sure that users get the latest version if they are online.

yes , it may be useful. I am glad you're willing to explore it.

‌

‌

[John Maloney]

I've updated the service worker for MicroBlocks and reenabled it. However, I don't think that is enough because the service worker will still use file from the browser cache if they are available. I think the correct way to solve this problem is to configure our Nginx server to add a cache control header the an appropriate "max-age". I will look into that.

[Dariusz Dorożalski]

The cache must be explicitly maintained, and the name should be tied to the version ID.

[John Maloney]

You're suggesting using a cache-busting technique to force immediate updates. We can certainly do that. However, I think we still need to set a max-age for the base .html file, don't we?

[Dariusz Dorożalski]

Based on developer.chrome.com- caching-strategies-overview , Service Worker Cache and HTTP Cache are separate entities

[

• The Cache interface is a caching mechanism entirely separate from the HTTP cache.
• Whatever Cache-Control configuration you use to influence the HTTP cache has no influence on what assets get stored in the Cache interface.

]

So something like this can be used

var appVersion = 1224
var cacheName = 'MicroBlocks-'+appVersion;

App version can be read, if provided, from "manifest.json" with the API "chrome.runtime.getManifest().version"

For completeness

• Deleting old/obsolete caches
• Caching strategies

[John Maloney]

Thanks for clarifying and for the links. MicroBlocks is using the "Stale-while-revalidate" caching strategy.

I understand how versioning the cache name updates the entire service worker cache by creating a new cache. That's useful.

However, my understanding is that when the service worker does a "fetch" operation to update that new cache, it first looks in the regular HTTP cache. If it finds the file there, it will install that file in the service worker cache.

If that's the case, we want to make sure that files in the HTTP cache are not too much out of date. It's okay if they are a few days or even a week out of date, but I wouldn't want them to be many weeks old. That's why it's useful to set the max-age in the server.

[John Maloney]

Things are now set up so that, in the future, users should automatically see new versions of MicroBlocks a day or two after they appear, even if they don't flush their browser cache. Note that this change will not automatically flush previously cached files. Users who do not manually reload the page or flush their browser cache will not see this new behavior until the currently cached files get replaced.