Expirer le cache sur require.js data-main

Question

Je suis à l'aide d'require.js et r.js pour emballer mon AMD modules. J'utilise jquery & requirejs via la syntaxe suivante:

<script data-main="/js/client" src="/js/external/require-jquery.js"></script>

Tout cela fonctionne très bien pré & post de l'emballage, mais je rencontre des problèmes beaucoup où chrome & safari mobile tenir à la version en cache d'client.js. Je voudrais ajouter un contournement du cache de client.js mais je n'arrive pas à comprendre comment le faire en utilisant la syntaxe ci-dessus.

J'ai essayé quelques variantes de:

<script data-main="js/client.js?b=busted" src="/js/external/require-jquery.js"></script>

mais maintenant exiger essaie d'obtenir client.js d' /, pas /js, donc une erreur 404.

J'ai aussi essayé d'ajouter

urlArgs : "bust="+new Date().getTime()

d' require.config, mais il semble avoir aucun effet.

J'ai aussi essayé d'ajouter la même valeur de app.build.js, mais quand c'est y, r.js n'est plus concatène mes fichiers js, juste uglifies eux.

Quelle est la bonne syntaxe pour un buste require.js de données principale du script de cache?

Answer 1

Comment êtes-vous de la définition de votre besoin.config? Je pense que pour qu'il prenne effet avant de les importer require.js, vous avez besoin de code comme ceci:

<script type="text/javascript">
    var require = {
        baseUrl: "/scripts/",
        waitSeconds: 15,
        urlArgs : "bust="+new Date().getTime()
    };
</script>
<script data-main="app/main" src="/scripts/require.js"></script>

Plus précisément, un objet nommé "requiert" doit être construit avant de les importer require.js.

Mise à JOUR

Comme Jesse points dans les commentaires ci-dessous, il y a quelques améliorations, vous devriez demander à votre besoin de{} objet pour une utilisation en production. L'exemple ci-dessus est chipé par le RequireJS documentation et modifié aussi peu que possible de répondre à cette question.

Voici quelques choses à considérer pour une utilisation en production:

• Au lieu d'utiliser la date du jour-le temps que votre cache-busting variable, vous devez utiliser un numéro de build de votre environnement de développement. Cela permet à vos clients de mettre en cache le code Javascript entre les versions, mais leur cause pour rafraîchir leur cache chaque fois que vous faites une mise à jour du logiciel.
• Jesse utilise également le besoin{}'s la capacité de spécifier les dépendances au lieu d'utiliser les données attribut principal du script. Je ne sais pas si c'est strictement mieux, mais je pense qu'il est plus propre à la recherche.
• Ajuster la waitSeconds en fonction de vos besoins. J'ai utilisé l'exemple de la valeur de la RequireJS de la documentation, mais vous devez ajuster la valeur ou de les omettre, en fonction de vos besoins.

Donc si vous appliquez ces techniques, votre code pourrait ressembler à:

<script type="text/javascript">
    var require = {
        baseUrl: "/scripts/",
        waitSeconds: 15,
        urlArgs : "bust="+{{buildNumber}},
        deps : ['app/main']
    };
</script>
<script src="/scripts/require.js?bust={{buildNumber}}"></script>

Remarque, dans ce cas, {{buildNumber}} est une valeur fournie par le serveur.

Mise à JOUR 2

Le urlArgs cache buste solution a des problèmes. Malheureusement, vous ne pouvez pas contrôler tous les serveurs proxy qui peut être fait entre vous et votre navigateur web de l'utilisateur. Certains de ces serveurs proxy peuvent être malheureusement configuré pour ignorer les paramètres d'URL lors de la mise en cache de fichiers. Si cela se produit, la mauvaise version de votre fichier JS sera livré à votre utilisateur.

Je vous conseille d'utiliser un buildNumber dans l'option Javascript de votre nom de fichier de la demande, comme buildNumber.myModule.js (préfixe) ou myModule.buildNumber.js (postfix). Vous pouvez utiliser le préfixe de style en modifiant la baseUrl:

baseUrl: "/scripts/buildNumber",

Note de l'absence d'un '/' à la fin de la baseUrl.

Vous aurez besoin d'utiliser une version modifiée de require.js pour utiliser le suffixe solution. Vous pouvez en lire plus à ce sujet ici: http://stackoverflow.com/a/21619359/1017787

Évidemment, dans les deux cas, vous souhaitez utiliser une solution pour remplacer buildNumber avec un certain type de numéro de version qui change à chaque version.