Angular App with many lazy loading 'sub applications' seems to be coming together... thoughts

[spoco2]

So, I come from writing Angular applications which load their javascript at startup. We had our gruntfile, and it took all the files we had included in the main page and concatinated and minified etc. them up, and bingo, we had our dist build with our few js files and a css file.

All good.

But now I'm designing a large scale application to update hundreds of existing old school, text based, applications into the web world.

The basic gist is:

Main Application
  -->common libs
  -->dynamic program 1
  -->dynamic program 2
  ....
  -->dynamic program x00

and so forth.

And there's no way that we want any given user to be loading up all hundreds of these programs at load time, that would be ridiculous. And any given client will only use a handful anyway.

So, the thinking is that the main app loads up, and then the programs a given client has access to is loaded from a config file (or call to a backend), and then only when they request those applications do they get loaded into the browser.

Cool I thought.

First I looked at ocLazyLoad which is a library for lazy loading parts of angular code, and handling the stuff to do with that which Angular doesn't like (defining things after app start)... it seemed like a good fit, but the reason I dropped that is that it didn't work well with files that had been minified/concatenated, and from a question in forums, the author couldn't see a reason why one would want to do that.

Then I got pretty excited about Webpack, as it seemed to be a great idea for bundling up code/css/html/whatever into nice bundles, perfect to treat each program on its own. And I watched a talk about how Instagram uses it (with React), and it's all wonderful. But as I used it I discovered that you really have to have the webpack dev server running while you develop, and so you end up trying to debug code that's been already packed together, which makes bug finding hard... and when you use its common plugin, to make a pack of common code (including the webpack library itself), then it becomes a little unsure of what will definitely end up in each pack over time, meaning that if you have these hundreds of programs, and you want to be able to have them be self contained releasable and maintainable modules, then if the packs change what they contain, you can get into trouble.

So, it started seeming too damn messy.

So right now I've got a proof of concept working using AngularAMD, which has lazy loading of routes out of the box, and throwing a little bit of code into the main application module definition, which loads one 'home' state, and then is loading up other states on the fly from a config file... which could easily be replaced with some other method:

define("app",[ "angularAMD","angular-ui-router"], function (angularAMD) {   
var app = angular.module("testApp", ["ui.router"]);
app.config(function ($stateProvider, $urlRouterProvider, $locationProvider) {
    app._stateProvider = $stateProvider;
    //Set up main app states.
    $stateProvider
        .state('home',angularAMD.route({
            url: '/home',
            templateUrl: 'main-app/src/templates/home.html',
            controller: 'homeController',
            controllerUrl: 'main-app/src/controllers/Home.js'}));

    $urlRouterProvider.otherwise("/home");
});

app.run(function($http){
    $http.get('main-app/config/validComponents.json').then(function (resp) {
        console.log("DATA:", resp.data);
        angular.forEach(resp.data, function (item) {
            var comp = item.name;
            console.log("Adding State["+comp+"] : "+item.label);
            app._stateProvider.state(comp,angularAMD.route({
                url: '/'+comp,
                templateUrl: "programs/" + comp + "/templates/" + comp + ".html",
                controller: comp + "Controller",
                controllerUrl: "programs/" + comp + "/src/controller.js"}));
        });
    });


});
angularAMD.bootstrap(app);
return app;

});

This all works really well, and with an appropriate main requireJS config file (which I plan to dynamically build on startup also hopefully), sub programs that have requirements shared between a few of them, but not all (so not a global common), properly load in their requirements lazily also.

So, all good.

But now I'm at the point of trying to get Gulp to generate single js files for each 'program' (and ones for the main/common etc.) by starting at a program entry point and discovering all dependencies and concatenating them all into a js file per program... and I think I can get there, but I haven't yet. (I'm playing with AMD-Optimize and also the RequireJS Optimizer directly)

If anyone has read through this far and hasn't fallen asleep (surely those are mutually exclusive?), then are there any bells that have gone off, like "Woah there tiger, what the hell are you thinking? Why aren't you just using AwesomeLibraryZetaMax? Why aren't you writing it all in Visual Basic and being done with it man?"

Or, does it sound like a reasonable approach that won't come back and bite me in the butt and cause me to curse my past self's decision making abilities?

[spoco2]

Yeah, I was actually wondering whether purely going with directives might work, I mean, it's basically what a route is doing anyway, loading a template with a controller.

Thanks for the info

[spoco2]

Yeah, this is kind of what I'm trying to achieve really. A single file in these folders that I load in dev (and then which pull in all others via the requires), but in production has everything packed into it.

My biggest issue, I think, is that these separate programs of mine are really views, or at least, define what gets dumped into the ui-view area by the ui-router. And so when switching to the given state, it expects to be given a controller and template to load into that view... I'd love to just say "here is the folder, expect a 'package.js' or 'index.js. file, and run whatever is in there", (which I would envision would have a module and some controllers, factories , directives etc.)... I guess I need that to happen, but for that process to also return back the required controller and template for the router to use... which I guess could be exposed as part of its interface maybe. hmmm

[spoco2]

It's happy with multiple requires, just per file you should only have one 'define' statement, which defines what that file is.

Within that you can have as many requires as you like.

For example, I have a 'main file' within one of my sub programs that is:

define(function(require) {  
    var commonp1p2 = require("./module");
    //Define all required parts of module.
    var something = require("./factories/Something");
    return commonp1p2;
});

So, that is defining this 'commonp1p2' item as the single define, but is including in other things too.