218 votes

angular js - configuration pour différents environnements

comment avez-vous gérer les variables de configuration/constante pour les différents environnements?

Ce pourrait être un exemple:

mon api rest c'est accessible sur localhost:7080/myapi/, mais mon ami qui travaille sur le même code sous contrôle de version GIT avoir l'api déployé sur son tomcat sur localhost:8099/hisapi/.

En supposant que nous avons quelque chose comme ceci :

angular  
   .constant('API_END_POINT','<local_end_point>')
   .factory('User',['$resource','API_END_POINT'],function($resource,API_END_POINT){
       return $resource(API_END_POINT + 'user');
   });

Comment dynamiquement injecter la valeur correcte de l'api point de fin de l'url en fonction de l'environnement?

En php j'ai l'habitude de faire ce genre de trucs avec un config.username.xml fichier, la fusion de la base du fichier de configuration (config.xml) avec la section locale de l'environnement de fichier de configuration reconnu par le nom de l'utilisateur... mais je ne sais pas comment gérer ce genre de choses en javascript?

Merci.

209voto

André Dion Points 6428

Je suis un peu en retard pour le thread, mais si vous êtes en utilisant un Grognement , j'ai eu beaucoup de succès avec grunt-ng-constant.

La section de configuration pour ngconstant mon Gruntfile.js ressemble

ngconstant: {
  options: {
    name: 'config',
    wrap: '"use strict";\n\n{%= __ngModule %}',
    space: '  '
  },
  development: {
    options: {
      dest: '<%= yeoman.app %>/scripts/config.js',
    },
    constants: {
      ENV: 'development'
    }
  },
  production: {
    options: {
      dest: '<%= yeoman.dist %>/scripts/config.js',
    },
    constants: {
      ENV: 'production'
    }
  }
}

Les tâches qui utilisent ngconstant ressemblent

grunt.registerTask('server', function (target) {
  if (target === 'dist') {
    return grunt.task.run([
      'build',
      'open',
      'connect:dist:keepalive'
    ]);
  }

  grunt.task.run([
    'clean:server',
    'ngconstant:development',
    'concurrent:server',
    'connect:livereload',
    'open',
    'watch'
  ]);
});

grunt.registerTask('build', [
  'clean:dist',
  'ngconstant:production',
  'useminPrepare',
  'concurrent:dist',
  'concat',
  'copy',
  'cdnify',
  'ngmin',
  'cssmin',
  'uglify',
  'rev',
  'usemin'
]);

Le fait d'exécuter grunt server va générer un config.js fichier app/scripts/ qui ressemble à

"use strict";
angular.module("config", []).constant("ENV", "development");

Enfin, je déclare la dépendance sur tout les modules besoin:

// the 'config' dependency is generated via grunt
var app = angular.module('myApp', [ 'config' ]);

Maintenant, mon constantes peuvent être de dépendance injecté en cas de besoin. E. g.,

app.controller('MyController', ['ENV', function( ENV ) {
  if( ENV === 'production' ) {
    ...
  }
}]);

75voto

kfis Points 2826

Un cool solution pourrait être de séparer tous spécifiques à l'environnement des valeurs dans un module angulaire, que tous les autres modules dépendent de:

angular.module('configuration', [])
       .constant('API_END_POINT','123456')
       .constant('HOST','localhost');

Alors vos modules qui ont besoin de ces entrées peut déclarer une dépendance sur elle:

angular.module('services',['configuration'])
       .factory('User',['$resource','API_END_POINT'],function($resource,API_END_POINT){
           return $resource(API_END_POINT + 'user');
       });

Maintenant, on peut réfléchir à d'autres trucs cool:

Le module, qui contient la configuration peut être séparé en configuration.js qui sera inclus à votre page.

Ce script peut être facilement éditées par chacun de vous, tant que vous ne contrôlez pas ce fichier dans le dépôt git. Mais il est plus facile de ne pas cocher dans la configuration si c'est dans un fichier séparé. Aussi, vous pourriez branche locale.

Maintenant, si vous avez un build-système, comme ANT ou Maven, votre d'autres mesures qui pourraient être mise en œuvre de certaines des espaces réservés pour les valeurs API_END_POINT, qui sera remplacé au cours de la construction, avec vos valeurs.

Ou vous avez votre configuration_a.js et configuration_b.js et de décider à l'arrière-plan à inclure.

13voto

Jure Triglav Points 784

Vous pouvez utiliser lvh.me:9000 d'accéder à votre application AngularJS, (lvh.me seulement des points à l'adresse 127.0.0.1), puis spécifiez un autre point de terminaison si lvh.me est l'hôte:

app.service("Configuration", function() {
  if (window.location.host.match(/lvh\.me/)) {
    return this.API = 'http://localhost\\:7080/myapi/';
  } else {
    return this.API = 'http://localhost\\:8099/hisapi/';
  }
});

Et puis injecter le service de Configuration et d'utilisation Configuration.API où vous en avez besoin pour accéder à l'API:

$resource(Configuration.API + '/endpoint/:id', {
  id: '@id'
});

Un peu maladroit, mais fonctionne très bien pour moi, mais dans une situation légèrement différente (API points de terminaison diffèrent dans la production et le développement).

5voto

joakimbeng Points 654

Bonne question!

Une solution pourrait être de continuer à utiliser votre config.xml fichier, et de fournir des api d'extrémité de l'information depuis le backend de votre code html généré, comme ceci (exemple en php):

<script type="text/javascript">
angular.module('YourApp').constant('API_END_POINT', '<?php echo $apiEndPointFromBackend; ?>');
</script>

Peut-être pas une très jolie solution, mais il pourrait fonctionner.

Une autre solution pourrait être de maintenir l' API_END_POINT la valeur de la constante comme il se doit dans la production, et de ne modifier que vos hôtes-file à un point que l'adresse url de votre local plutôt l'api.

Ou peut-être une solution à l'aide d' localStorage pour les remplacements, comme ceci:

.factory('User',['$resource','API_END_POINT'],function($resource,API_END_POINT){
   var myApi = localStorage.get('myLocalApiOverride');
   return $resource((myApi || API_END_POINT) + 'user');
});

2voto

jvannistelrooy Points 341

Si vous utilisez le Brunch, le plugin Constangular vous aide à gérer les variables pour les différents environnements.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X