6

Is there a commonly accepted best practice for maintaining a configuration file that is available on the client side (sort of an equivalent of the AppSettings section on the server side in an ASP.NET application)?

Our application is based on Angular. Our desire is to externalize environment-specific settings (like remote system URLs, etc) from the code itself, so that ideally an Ops person and not a developer can modify settings in one place.

Thanks in advance for any insight!

blaster
  • 8,876
  • 11
  • 48
  • 77
  • 1
    you can keep settings in a dedicated config.js file, editing JSON is not more difficult then editing XML – Guillaume86 May 02 '13 at 20:13
  • 1
    Regarding Angular, maybe this answer could inspire you further http://stackoverflow.com/questions/16339595/angular-js-configuration-for-different-enviroments – kfis May 03 '13 at 07:38

3 Answers3

4

I don't think it's a good idea to use a config.js file when developing AngularJS apps. The reason being, you will break any possibility for automatic testing.

Instead, I create a "Settings" service in which I specify my app specific context. For example:

angular.module('settings',[]).factory('SettingsService',function(){

   var service={};

   // Insert your settings here
   service.ServerPath = 'whateverwhatever';
   service.ImagePath  = 'bla bla bal';

   return service;

});

Then inject the SettingsService into controllers that need access to the settings.

Ofcourse, (which I omitted for simplicity here), you could instead create the ServiceService with an empty body, and then in the application .run() method fetch the settings from the server.

I use the simple described way, and maintain a SettingsService for each deployment type ("development", "test", "production" etc). Then just include the right SettingsService in your build-script depending on the target (I use Grunt, but you could use Ant also).

Spock
  • 2,482
  • 29
  • 27
1

I think the answer to this is very dependent on how you setup your angular layer in the overall structure of the application.

For example, I have served up an angular application the same way for each environment from the base server application (Grails, node.js, RoR) and the angular application is always the same code base because the data I am feeding to angular is controlled by the server side and the angular calls are all relative to the base URL. In other words, I proxy all data through the server app that serves up the Angular application so all the angular app "knows about" is its own url.

If you are directly calling other services and not using the base server application to proxy the data, then maybe you can still use the server to feed you the url's depending on some config on the server side of the application. In this case, you can always store those config values in a DB table so changing them on the fly is possible.

BoxerBucks
  • 3,124
  • 2
  • 21
  • 26
1

I have this same dilemma, and what I have resorted to for right now is: I have a set of config files, like config-local.js, config-staging.js, etc. Then I create a symlink to config.js anywhere I want to run my app. On my local desktop, I symlink to config-local.js, in the staging env, I symlink to config-staging.js. Then I put config.js in .gitignore.

Pros: It works. Cons: Requires symlink creation before the app will work correctly.

Future: Maybe add a task in grunt to create the symlink?

aet
  • 7,192
  • 3
  • 27
  • 25