reason
Offers a simple mechanism to allow extremely long expire-headers on scripts whilst still being able to switch to newer versions on the fly.
implementation
A js file defined with data-main attribute on the script tag of require.js, will always be loaded with current timestamp to always force a fresh load.
// main.js?cacheKey=TIMESTAMP-123412312321
<script data-main="main" src="require.js"></script>
Inside main.js you can define a cacheKey that will be appended to all loaded scripts from that point on.
// results in [root]/module.js?cacheKey=v1.0.0
require.cacheKey( "v1.0.0" );
require( "module" , function( module ){
/* code*/}
);
or using RequireJS config mechanism:
// results in [root]/module.js?cacheKey=v1.0.0
require( {
cacheKey: "v1.0.0"
} , "module" , function( module ){
/* code*/}
);
Set extreme long expire headers on .js files and you get optimal browser caching whilst able to update an entire dependency tree by setting one value.
As an alternative to setting the cacheKey variable in javascript, it could also be passed by another data- attribute. (from Smith, see comments)
<script data-main="main" data-cacheKey="v1.0.0" src="require.js"></script>
This allows both development teams (backend/frontend) to be able to control the cacheKey. However a question of what overrides what remains.
As a bonus, you could opt to override cacheKey usage with a path-expression plugin (see path-expression gist).
// not a pretty path-expression I admit.
require( "module !nocachekey" , function( module ){
/* code*/}
);
urlArgs fills the bill 90%, but is rather obscure and low level (you have to explain in detail what you can do with it).
So thought defining a standard and clear way to utilise long expire-headers and make it an obvious part of the API would be a good idea.
Utilising long expire-headers+urlArgs for cache controle adds enormous value, you can tell people to handcode it like this or simply make it part of your API/documentation. Afterall, adding convenience (however minute) methods to reduce handcoding is exactly what made jQuery so succesful as well.
ps. perhaps I think too much about API clarity and design, it's also the reason I never released any of my module loaders, I kept tinkering with the API and mechanics =P
Most people will use main.js to kickstart their other js implementations, so generally this file should not cache (which has a low impact) since it will see the most changes. "main.js" is also the most logical place to bust caching throughout the dependency trees. It's a small tweak, but oh so convenient and clear.