Comment faire pour actualiser / invalider $cache des ressources en AngularJS

J'ai un simple Utilisateur $ressource qui utilise la valeur par défaut $cache http mise en œuvre comme suit:

factory('User', function($resource){
    return $resource(endpoint + '/user/current/:projectId', {},
        {get: 
            {
                cache: true,
                method: 'GET'
            }
        }
    );
})

Cela fonctionne très bien, c'est à dire mon serveur n'est appelée qu'une fois dans ma demande, alors la valeur est récupérée à partir de la mémoire cache.

Mais j'ai besoin d'actualiser la valeur du serveur après une certaine opération. Est-il un moyen facile de faire cela?

Grâce.

  • Je suis l'aide de la distribution instable (1.1.5 mais je pense que c'est là depuis 1.1.2) cache – {boolean|Cache} – Si la valeur est true, la valeur par défaut $cache http sera utilisé pour le cache de la requête GET, sinon, si une instance de cache intégré avec
  • je vais avoir le même problème, mais seulement lors de l'essai. comment puis-je le buste de cette chose au niveau du navigateur?
InformationsquelleAutor Alexandre Bulté | 2013-06-12
  1. 115

    Garder le booléen et obtenir le $http cache:

    var $httpDefaultCache = $cacheFactory.get('$http');

    Alors vous pouvez contrôler comme n'importe quel autre cache fait avec $cacheFactory, une utilisation de l'exemple fourni ci-dessous:

    $httpDefaultCache.remove(key);
//Where key is the relative URL of your resource (eg: /api/user/current/51a9020d91799f1e9b8db12f)
    • Parfait, merci! Exactement ce que je cherchais. Pour ceux qui se demandent, vous pouvez appeler $cacheFactory.get('$http').remove(clé), avec les principaux étant l'URL relative de vos ressources (ex: /api/utilisateur/actuel/51a9020d91799f1e9b8db12f).
    • En fait j'ai trouvé que j'avais besoin de spécifier l'url complète, avec tous les paramètres de la requête lors de l'appel de supprimer(). Suis-je manqué quelque chose?
    • Si l'URL de la mise en cache contient les paramètres de la requête, alors oui, vous aurez à spécifier dans la remove() clé. Les Url relatives pour faire le travail, bien que, au moins dans 1.2.9.
    • J'ai dynamiques des paramètres de requête. Est-il un moyen d'accéder à l'url de $resource usine?
    • Bien que cela fonctionne. Il peut être plus complexe que nécessaire. Une meilleure solution serait, si cela a été implémentée: github.com/angular/angular.js/issues/9064
    • Pour moi, $cacheFactory.get('$http').removeAll() a fait le tour, comme je le nécessaire pour effacer toutes les données mises en cache.

    InformationsquelleAutor Anthonny
  2. 17

    Au lieu d'utiliser un argument booléen dans le cache de la propriété de chaque action vous pouvez passer sur une instance de cache créé avec $cacheFactory qui vous pouvez avoir plus de contrôle sur (c'est à dire vider le cache).

    Exemple d'utilisation:

    app.factory('Todos', function($resource, $cacheFactory) {
    var cache = $cacheFactory('todo');
    return $resource(apiBaseUrl + '/todos/:id', { id: '@id' }, {
        'get': { method: 'GET', cache: cache  },
        'query': { method: 'GET', cache: cache, isArray: true }
    });
});
    • Merci. J'ai vu ça aussi, mais je cherchais une façon "standard" de le faire avant d'aller en bas de ce chemin...
    • semble être une très "standard" approche conforme à la "angulaire chemin" 🙂
    • Vous avez raison. Je voulais dire une approche à la norme $cache des ressources.
    InformationsquelleAutor Variant
  3. 6

    Je suis tombé sur ce thread à la recherche de quelque chose de similaire, mais a constaté que $ressource de gérer le cache automatiquement pour vous, il n'ya donc pas besoin de forcer le cache est effacé.

    L'idée est que si vous disposez d'une ressource que vous pouvez faire une requête, que la réponse à la requête va être mis en cache, mais si vous enregistrez quelque chose pour que la même ressource, précédemment mis en cache les données doivent être invalide, il est nettoyé pour vous. Il est logique que cela fonctionnerait de cette façon.

    Voici un code que j'utilise pour ce faire (vous pouvez ignorer la peut-être bizarre usine de création et de prêter attention à la "classe" du corps).

    'use strict';

sampleApp.players.$ng.factory('sampleApp.players.PlayerService', [
    '$log',
    '$resource',
    sampleApp.players.PlayerService = function ($log, $resource) {
        var service = {};

        $log.info('Creating player resource.');
        var Player = $resource('/api/players', {}, {query: {
            isArray: true,
            cache: true,
            method: 'GET'
        }});

        service.addPlayer = function(playerName) {
            $log.info('Saving a new player.');
            return new Player({name: playerName}).$save();
        };

        service.listPlayers = function () {
            $log.info('Fetching players.');
            return Player.query();
        };

        return service;
    }]);

    Si vous appelez la listPlayers de fonction à plusieurs reprises, le premier appel fait une demande http get et tous les appels suivants sont mis en cache. Si vous appelez addPlayer cependant, un http post est effectuée comme prévu, et puis le prochain appel à listPlayers va effectuer un http get (pas de mise en cache).

    Cela vous maintient de l'activité de gestion de quelqu'un d'autre ($http) cache et en essayant de garder en place avec l'url qui ont été utilisés pour les demandes et qui sont à la compensation des caches au bon moment.

    Je suppose que la morale de l'histoire ici est de travailler avec la bibliothèque et tout ira bien... sauf pour les bugs ou incomplète de fonctionnalités, mais Angulaire de ne pas avoir l'un de ceux-ci 😉

    p.s. Tout ceci est en cours d'exécution sur AngularJS 1.2.0.

    • Oui, je comprends et reconnais que dans des conditions "normales" de l'Angulaire de la ressource sait comment et quand, pour invalider le cache, et il fonctionne parfaitement. Mais mon cas d'utilisation était légèrement différent: j'ai voulu forcer un rafraîchissement car Angulaire avait aucun moyen de savoir qu'un rafraîchissement est nécessaire, l'utilisateur de l'objet en cours de modification à l'extérieur de l'angle d'application.
    • Quelqu'un peut-il point à l'endroit où il est documenté? J'ai lu à ce sujet avant sur un Débordement de Pile, mais ne trouve aucune mention de cela dans la documentation. Je l'ai essayé aussi bien dans mon application, mais peut-être avez fait quelque chose de mal le long du chemin...
    • Il ne semble pas cependant de travailler avec $supprimer. Le prochain appel sera de tirer à partir du cache de nouveau et que les éléments supprimés réapparaissent. Quelqu'un peut confirmer?
    • Cela ne fonctionnera pas ngResource NE MANIPULEZ PAS l'invalidation du cache de passer ici par exemple : stackoverflow.com/questions/25117388/...
    InformationsquelleAutor user605331