3

I have an application which needs to be able to dynamically add directives/filters/services/controllers. The functionality I need is akin to loading a Mac OS X Widget / Windows Gadget. To my knowledge there are 3 ways of doing this :

  • Include them in the initial stack -- This isn't realistic for me, as the stack will be too big, and we may be pulling these functionalities from remote locations on demand

  • Hack a bit, and add them to the application -- I have this working, but it's messy when you have to recompile. An adapted version of Loading an AngularJS controller dynamically

  • Bootstrap another app with has all the needed functionality -- Probably the most correct way of doing this...

Right now, I'm sticking to the third option.

These asynchronously added apps don't need routes. What's the best way to write these modules, so I don't have to configure $routeProvider? What do I use instead of ng-view?

Or do I have to just stick using $routeProvider.otherwise() ?

Thanks,

Max.

Community
  • 1
  • 1
Max Bates
  • 1,238
  • 1
  • 16
  • 21

1 Answers1

0

check out my blog post walking through a simple app with a decoupled feature defining its own state: angularjs-state-management-with-ui-router.

The technique shown is to provide a state hierarchy per feature and implement this in said module's config.

Also, look at script.js: not strictly an angular script loader, but plays well with it (as demonstrated in the angular-seed app: deep link to implementation.) This might help you to solve the dynamic loading problem.

ben schwartz
  • 2,559
  • 1
  • 21
  • 20
  • Thanks for the response! Already using $script. My goal is to minimize the footprint of the loaded applications, and throwing Angular UI into the mix goes back a step. My goal is to avoid defining routes (or states) as only one template will be used. – Max Bates May 16 '13 at 21:15
  • two notes: 1) angular-ui is getting broken down into component libraries, and ui-router is just 1000 lines unminified. 2) organizing your application as "n" top level states might still make sense. Regardless of how much overhead you want or don't want to add, thinking of your incremental features as providing a state to your app might still be useful as it provides a common interface/requirement that your modules can satisfy – ben schwartz May 16 '13 at 21:35
  • are you looking to encapsulate the loaded applications completely? is it not ok for them to share the common angular instance bootstrapped by your entry-point application? – ben schwartz May 16 '13 at 21:40
  • These secondary apps need to be added after the primary app has bootstrapped because they are adding new services/controllers/directives/filters, which is currently not supported natively. They share some of the same modules, but can't exist all within the same app. – Max Bates May 17 '13 at 23:51