¿Cómo configuro diferentes entornos en Angular.js?

¿Cómo gestiona las variables / constantes de configuración para diferentes entornos?

Este podría ser un ejemplo:

Se puede acceder a mi API de descanso localhost:7080/myapi/, pero mi amigo que trabaja en el mismo código bajo el control de versión de Git tiene la API implementada en su Tomcat localhost:8099/hisapi/.

Suponiendo que tenemos algo como esto:

angular
    .module('app', ['ngResource'])

    .constant('API_END_POINT','<local_end_point>')

    .factory('User', function($resource, API_END_POINT) {
        return $resource(API_END_POINT + 'user');
    });

¿Cómo se inyecta dinámicamente el valor correcto del punto final de la API, según el entorno?

En PHP, generalmente hago este tipo de cosas con un config.username.xmlarchivo, fusionando el archivo de configuración básica (config.xml) con el archivo de configuración del entorno local reconocido por el nombre del usuario. ¿Pero no sé cómo administrar este tipo de cosas en JavaScript?

Llego un poco tarde al hilo, pero si estás usando Grunt , he tenido un gran éxito congrunt-ng-constant .

La sección de configuración ngconstanten mi Gruntfile.jsparece

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'
    }
  }
}

Las tareas que usan ngconstantparecen

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'
]);

Por lo tanto, la ejecución grunt servergenerará un config.jsarchivo app/scripts/que se ve como

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

Finalmente, declaro la dependencia de cualquier módulo que lo necesite:

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

Ahora mis constantes se pueden inyectar dependencia donde sea necesario. P.ej,

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

Una solución genial podría ser separar todos los valores específicos del entorno en un módulo angular separado, del que dependen todos los demás módulos:

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

Luego, los módulos que necesitan esas entradas pueden declarar una dependencia de él:

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

Ahora puedes pensar en otras cosas interesantes:

El módulo que contiene la configuración se puede separar en configuration.js, que se incluirá en su página.

Cada uno de ustedes puede editar fácilmente este script, siempre que no marque este archivo separado en git. Pero es más fácil no verificar la configuración si está en un archivo separado. Además, puede ramificarlo localmente.

Ahora, si tiene un sistema de compilación, como ANT o Maven, sus pasos adicionales podrían ser implementar algunos marcadores de posición para los valores API_END_POINT, que se reemplazarán durante el tiempo de compilación, con sus valores específicos.

O tiene su configuration_a.jsy configuration_b.jsy decide en el backend qué incluir.

Para los usuarios de Gulp , gulp-ng-constant también es útil combinado con gulp-concat , event-stream e yargs .

var concat = require('gulp-concat'),
    es = require('event-stream'),
    gulp = require('gulp'),
    ngConstant = require('gulp-ng-constant'),
    argv = require('yargs').argv;

var enviroment = argv.env || 'development';

gulp.task('config', function () {
  var config = gulp.src('config/' + enviroment + '.json')
    .pipe(ngConstant({name: 'app.config'}));
  var scripts = gulp.src('js/*');
  return es.merge(config, scripts)
    .pipe(concat('app.js'))
    .pipe(gulp.dest('app/dist'))
    .on('error', function() { });
});

En mi carpeta de configuración tengo estos archivos:

ls -l config
total 8
-rw-r--r--+ 1 .. ci.json
-rw-r--r--+ 1 .. development.json
-rw-r--r--+ 1 .. production.json

Entonces puedes correr gulp config --env developmenty eso creará algo como esto:

angular.module("app.config", [])
.constant("foo", "bar")
.constant("ngConstant", true);

También tengo esta especificación:

beforeEach(module('app'));

it('loads the config', inject(function(config) {
  expect(config).toBeTruthy();
}));

Para lograr eso, le sugiero que use el complemento de entorno AngularJS: https://www.npmjs.com/package/angular-environment

Aquí hay un ejemplo:

angular.module('yourApp', ['environment']).
config(function(envServiceProvider) {
    // set the domains and variables for each environment 
    envServiceProvider.config({
        domains: {
            development: ['localhost', 'dev.local'],
            production: ['acme.com', 'acme.net', 'acme.org']
            // anotherStage: ['domain1', 'domain2'], 
            // anotherStage: ['domain1', 'domain2'] 
        },
        vars: {
            development: {
                apiUrl: '//localhost/api',
                staticUrl: '//localhost/static'
                // antoherCustomVar: 'lorem', 
                // antoherCustomVar: 'ipsum' 
            },
            production: {
                apiUrl: '//api.acme.com/v2',
                staticUrl: '//static.acme.com'
                // antoherCustomVar: 'lorem', 
                // antoherCustomVar: 'ipsum' 
            }
            // anotherStage: { 
            //  customVar: 'lorem', 
            //  customVar: 'ipsum' 
            // } 
        }
    });

    // run the environment check, so the comprobation is made 
    // before controllers and services are built 
    envServiceProvider.check();
});

Y luego, puede llamar a las variables desde sus controladores como este:

envService.read('apiUrl');

Espero eso ayude.

Puede usar lvh.me:9000para acceder a su aplicación AngularJS ( lvh.mesolo apunta a 127.0.0.1) y luego especificar un punto final diferente si lvh.mees el host:

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/';
  }
});

Y luego inyecte el servicio de configuración y úselo Configuration.APIdonde necesite acceder a la API:

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

Un poco torpe, pero funciona bien para mí, aunque en una situación ligeramente diferente (los puntos finales de API difieren en producción y desarrollo).

También podríamos hacer algo como esto.

(function(){
    'use strict';

    angular.module('app').service('env', function env() {

        var _environments = {
            local: {
                host: 'localhost:3000',
                config: {
                    apiroot: 'http://localhost:3000'
                }
            },
            dev: {
                host: 'dev.com',
                config: {
                    apiroot: 'http://localhost:3000'
                }
            },
            test: {
                host: 'test.com',
                config: {
                    apiroot: 'http://localhost:3000'
                }
            },
            stage: {
                host: 'stage.com',
                config: {
                apiroot: 'staging'
                }
            },
            prod: {
                host: 'production.com',
                config: {
                    apiroot: 'production'
                }
            }
        },
        _environment;

        return {
            getEnvironment: function(){
                var host = window.location.host;
                if(_environment){
                    return _environment;
                }

                for(var environment in _environments){
                    if(typeof _environments[environment].host && _environments[environment].host == host){
                        _environment = environment;
                        return _environment;
                    }
                }

                return null;
            },
            get: function(property){
                return _environments[this.getEnvironment()].config[property];
            }
        }

    });

})();

Y en su controller/service, podemos inyectar la dependencia y llamar al método get con propiedad para acceder.

(function() {
    'use strict';

    angular.module('app').service('apiService', apiService);

    apiService.$inject = ['configurations', '$q', '$http', 'env'];

    function apiService(config, $q, $http, env) {

        var service = {};
        /* **********APIs **************** */
        service.get = function() {
            return $http.get(env.get('apiroot') + '/api/yourservice');
        };

        return service;
    }

})();

$http.get(env.get('apiroot') devolvería la url en función del entorno del host.

¡Buena pregunta!

Una solución podría ser continuar usando su archivo config.xml y proporcionar información de punto final de API desde el backend a su html generado, como este (ejemplo en php):

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

Quizás no sea una solución bonita, pero funcionaría.

Otra solución podría ser mantener el API_END_POINT valor constante como debería estar en producción, y solo modificar su archivo de hosts para apuntar esa url a su API local.

O tal vez una solución que use localStoragepara anulaciones, como esta:

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

Muy tarde al hilo, pero una técnica que he usado, pre-angular, es aprovechar JSON y la flexibilidad de JS para hacer referencia dinámica a las claves de recopilación, y usar datos inalienables del entorno (nombre del servidor host, idioma actual del navegador) , etc.) como entradas para discriminar selectivamente / preferir nombres de clave con sufijo dentro de una estructura de datos JSON.

Esto proporciona no solo el contexto del entorno de despliegue (por OP) sino cualquier contexto arbitrario (como el lenguaje) para proporcionar i18n o cualquier otra variación requerida simultáneamente e (idealmente) dentro de un único manifiesto de configuración, sin duplicación, y legible obvio.

EN ACERCA DE 10 LÍNEAS DE VAINILLA JS

Ejemplo demasiado simplificado pero clásico: una URL base de punto final de API en un archivo de propiedades con formato JSON que varía según el entorno donde (natch) el servidor host también variará:

    ...
    'svcs': {
        'VER': '2.3',
        'API@localhost': 'http://localhost:9090/',
        'API@www.uat.productionwebsite.com': 'https://www.uat.productionwebsite.com:9090/res/',
        'API@www.productionwebsite.com': 'https://www.productionwebsite.com:9090/api/res/'
    },
    ...

Una clave para la función de discriminación es simplemente el nombre de host del servidor en la solicitud.

Esto, naturalmente, se puede combinar con una clave adicional basada en la configuración de idioma del usuario:

    ...
    'app': {
        'NAME': 'Ferry Reservations',
        'NAME@fr': 'Réservations de ferry',
        'NAME@de': 'Fähren Reservierungen'
    },
    ...

El alcance de la discriminación / preferencia puede limitarse a teclas individuales (como arriba) donde la tecla "base" solo se sobrescribe si hay una tecla coincidente + sufijo para las entradas a la función, o una estructura completa, y esa estructura misma analizado recursivamente para igualar sufijos de discriminación / preferencia:

    'help': {
        'BLURB': 'This pre-production environment is not supported. Contact Development Team with questions.',
        'PHONE': '808-867-5309',
        'EMAIL': 'coder.jen@lostnumber.com'
    },
    'help@www.productionwebsite.com': {
        'BLURB': 'Please contact Customer Service Center',
        'BLURB@fr': 'S\'il vous plaît communiquer avec notre Centre de service à la clientèle',
        'BLURB@de': 'Bitte kontaktieren Sie unseren Kundendienst!!1!',
        'PHONE': '1-800-CUS-TOMR',
        'EMAIL': 'customer.service@productionwebsite.com'
    },

Por lo tanto, si un usuario visitante del sitio web de producción tiene una configuración de preferencia de idioma ( de ) alemán , la configuración anterior colapsaría para:

    'help': {
        'BLURB': 'Bitte kontaktieren Sie unseren Kundendienst!!1!',
        'PHONE': '1-800-CUS-TOMR',
        'EMAIL': 'customer.service@productionwebsite.com'
    },

¿Cómo es una función de reescritura JSON de preferencia / discriminación mágica? No mucho:

// prefer(object,suffix|[suffixes]) by/par/durch storsoc
// prefer({ a: 'apple', a@env: 'banana', b: 'carrot' },'env') -> { a: 'banana', b: 'carrot' }
function prefer(o,sufs) {
    for (var key in o) {
        if (!o.hasOwnProperty(key)) continue; // skip non-instance props
        if(key.split('@')[1]) { // suffixed!
            // replace root prop with the suffixed prop if among prefs
            if(o[key] && sufs.indexOf(key.split('@')[1]) > -1) o[key.split('@')[0]] = JSON.parse(JSON.stringify(o[key]));

            // and nuke the suffixed prop to tidy up
            delete o[key];

            // continue with root key ...
            key = key.split('@')[0];
        }

        // ... in case it's a collection itself, recurse it!
        if(o[key] && typeof o[key] === 'object') prefer(o[key],sufs);

    };
};

En nuestras implementaciones, que incluyen sitios web angulares y pre-angulares, simplemente arrancamos la configuración muy por delante de otras llamadas de recursos colocando el JSON dentro de un cierre JS autoejecutable, incluida la función prefer (), y alimentamos las propiedades básicas del nombre de host y código de idioma (y acepta cualquier sufijo arbitrario adicional que pueda necesitar):

(function(prefs){ var props = {
    'svcs': {
        'VER': '2.3',
        'API@localhost': 'http://localhost:9090/',
        'API@www.uat.productionwebsite.com': 'https://www.uat.productionwebsite.com:9090/res/',
        'API@www.productionwebsite.com': 'https://www.productionwebsite.com:9090/api/res/'
    },
    ...
    /* yadda yadda moar JSON und bisque */

    function prefer(o,sufs) {
        // body of prefer function, broken for e.g.
    };

    // convert string and comma-separated-string to array .. and process it
    prefs = [].concat( ( prefs.split ? prefs.split(',') : prefs ) || []);
    prefer(props,prefs);
    window.app_props = JSON.parse(JSON.stringify(props));
})([location.hostname, ((window.navigator.userLanguage || window.navigator.language).split('-')[0])  ] );

Un sitio pre-Angular ahora tendría una ventana contraída (sin @ llaves con sufijo) window.app_props para consultar.

Un sitio angular, como un paso de arranque / inicio, simplemente copia el objeto de utilería muerto en $ rootScope y (opcionalmente) lo destruye desde el alcance global / ventana

app.constant('props',angular.copy(window.app_props || {})).run( function ($rootScope,props) { $rootScope.props = props; delete window.app_props;} );

para ser inyectado posteriormente en los controladores:

app.controller('CtrlApp',function($log,props){ ... } );

o referido desde enlaces en vistas:

<span>{{ props.help.blurb }} {{ props.help.email }}</span>

Advertencias? El carácter @ no es válido JS / JSON variable / nombre de clave, pero hasta ahora aceptado. Si eso es un factor decisivo, sustituya cualquier convención que desee, como "__" (subrayado doble) siempre y cuando se adhiera a ella.

La técnica podría aplicarse del lado del servidor, portada a Java o C #, pero su eficiencia / compacidad puede variar.

Alternativamente, la función / convención podría ser parte de su script de compilación front-end, de modo que el JSON completo sangriento de todo entorno / lenguaje nunca se transmite por cable.

ACTUALIZAR

Hemos desarrollado el uso de esta técnica para permitir múltiples sufijos a una clave, para evitar ser forzado a usar colecciones (aún puede, tan profundamente como desee), y también para honrar el orden de los sufijos preferidos.

Ejemplo (también vea trabajar jsFiddle ):

var o = { 'a':'apple', 'a@dev':'apple-dev', 'a@fr':'pomme',
          'b':'banana', 'b@fr':'banane', 'b@dev&fr':'banane-dev',
          'c':{ 'o':'c-dot-oh', 'o@fr':'c-point-oh' }, 'c@dev': { 'o':'c-dot-oh-dev', 'o@fr':'c-point-oh-dev' } };

/*1*/ prefer(o,'dev');        // { a:'apple-dev', b:'banana',     c:{o:'c-dot-oh-dev'}   }
/*2*/ prefer(o,'fr');         // { a:'pomme',     b:'banane',     c:{o:'c-point-oh'}     }
/*3*/ prefer(o,'dev,fr');     // { a:'apple-dev', b:'banane-dev', c:{o:'c-point-oh-dev'} }
/*4*/ prefer(o,['fr','dev']); // { a:'pomme',     b:'banane-dev', c:{o:'c-point-oh-dev'} }
/*5*/ prefer(o);              // { a:'apple',     b:'banana',     c:{o:'c-dot-oh'}       }

1/2 (uso básico) prefiere las teclas '@dev', descarta todas las demás teclas con sufijo

3 prefiere '@dev' sobre '@fr', prefiere '@ dev & fr' sobre todos los demás

4 (igual que 3 pero prefiere '@fr' sobre '@dev')

5 sin sufijos preferidos, elimina TODAS las propiedades con sufijo

Esto se logra al calificar cada propiedad con sufijo y promover el valor de una propiedad con sufijo a la propiedad sin sufijo al iterar sobre las propiedades y encontrar un sufijo con una puntuación más alta.

Algunas eficiencias en esta versión, incluida la eliminación de la dependencia de JSON para copiar en profundidad, y solo recurrir a objetos que sobreviven a la ronda de puntuación en su profundidad:

function prefer(obj,suf) {
    function pr(o,s) {
        for (var p in o) {
            if (!o.hasOwnProperty(p) || !p.split('@')[1] || p.split('@@')[1] ) continue; // ignore: proto-prop OR not-suffixed OR temp prop score
            var b = p.split('@')[0]; // base prop name
            if(!!!o['@@'+b]) o['@@'+b] = 0; // +score placeholder
            var ps = p.split('@')[1].split('&'); // array of property suffixes
            var sc = 0; var v = 0; // reset (running)score and value
            while(ps.length) {
                // suffix value: index(of found suffix in prefs)^10
                v = Math.floor(Math.pow(10,s.indexOf(ps.pop())));
                if(!v) { sc = 0; break; } // found suf NOT in prefs, zero score (delete later)
                sc += v;
            }
            if(sc > o['@@'+b]) { o['@@'+b] = sc; o[b] = o[p]; } // hi-score! promote to base prop
            delete o[p];
        }
        for (var p in o) if(p.split('@@')[1]) delete o[p]; // remove scores
        for (var p in o) if(typeof o[p] === 'object') pr(o[p],s); // recurse surviving objs
    }
    if( typeof obj !== 'object' ) return; // validate
    suf = ( (suf || suf === 0 ) && ( suf.length || suf === parseFloat(suf) ) ? suf.toString().split(',') : []); // array|string|number|comma-separated-string -> array-of-strings
    pr(obj,suf.reverse());
}

Si está utilizando Brunch , el complemento Constangular lo ayuda a administrar variables para diferentes entornos.

¿Has visto esta pregunta y su respuesta?

Puede establecer un valor globalmente válido para su aplicación como este:

app.value('key', 'value');

y luego úsalo en tus servicios. Puede mover este código a un archivo config.js y ejecutarlo al cargar la página u otro momento conveniente.