Disable Sencha script loader cache busting but only while developing/debugging
Asked Answered
I

2

1

I'm working with ExtJS 4.x and Sencha Architect 2.2 but this should be relevant to later versions and any application that uses the Ext.Loader class to dynamically load scripts, including Sencha Touch.

By default Ext.Loader adds a ?_dc=... cache busting parameter to make sure that the latest version of each script is loaded into the browser. When deploying to a production or beta-test environment this is a good thing as it ensures the user/tester gets the latest script each time you deploy and update, but for a development environment this is not really necessary because developers know to use browser techniques like ctrl+F5 to force a reload of all the scripts. What's more the cache busting gets in the way of debugging as breakpoints etc are lost whenever you reload the app in the browser.

Cache busting is disabled by setting disableCaching to false in the Ext.Loader configuration. For example:

Ext.Loader.setConfig({
    enabled: true,
    disableCaching: false
});

In this snippet the dynamic loading is enabled and cache busting is disabled. There are however other config options as described in the API docs here.

In Sencha Architect this code is generated for you in app.js and you can't edit it. Architect has a "Project Setting" to enable caching but in version 2.2 it doesn't work for ExtJS 4. I assume it works fine in later versions but it seems to be all-or-nothing so you have to remember to switch it off and rebuild for deploying to a non-dev environment.

What I want is to be able to:

  1. Workaround the settings bug in version 2.2 of Architect
  2. Enable cache busting in "production" but not in dev without having to rebuild my app
Isolating answered 23/6, 2015 at 1:2 Comment(0)
I
1

Ext.Loader.setConfig() can be called multiple times with different settings and the settings are "merged" together. For me this was unclear in the documentation but fortunately it was more obvious in the source code.

The source code also shows that there is an undocumented form of setConfig where it takes a name and value instead of a config object, but as it's undocumented I'll stick with passing in an object like this:

Ext.Loader.setConfig({disableCaching: false});

Knowing that this won't affect other Ext.Loader configs that are set elsewhere in your app you can put this code anywhere after Ext is loaded, but before the Ext.onReady() is called. In Sencha Architect this can be achieved by putting it in a "JS Resource" as described here.

That solves the first part of my question, but what I also want is to be able to turn cache busting off without rebuilding, so I modified the code to check for a "debug" URL parameter like this:

if (Ext.Object.fromQueryString(document.location.search).debug) {
    Ext.Loader.setConfig({disableCaching: false});
}

Now when I want to debug my app I can use a URL that looks like:

http://myhost/.../app.html?debug=true

and the cache busting is turned off. I just omit the debug parameter for it to be turned back on.

Isolating answered 23/6, 2015 at 1:2 Comment(0)
P
1

If you are using Sencha Command you can wrap the line to disable cache busting in a debug block, somewhere at the beginning of your app.js

// <debug>
Ext.Loader.setConfig({disableCaching: true});
// </debug>

Now the code will be removed when built for production. If you wanted (or needed) to, you can also configure the build properties for the testing builds to keep the debug code as well.

Paramecium answered 23/6, 2015 at 14:40 Comment(1)
Good idea @cpastore84. However it's sometimes handy to be able to use debug mode in production too.Isolating

© 2022 - 2024 — McMap. All rights reserved.