Add a "simple" lazy loading example

[DorianGrey]

... ok, the example itself is simple, but the way to support lazy loading wasn't.

• Had to provide a workaround for dev mode (modules are referenced from main).
• Several things had to be moved to a SharedModule to be able to import them from the lazily loaded modules. Might be required to add even more modules to the shared one.
• These is still an issue with the TranslateModule being used on shared modules or referenced by lazily loaded modules (see https://github.com/ocombe/ng2-translate/issues/232). Fixed in the third commit, as described here.
• A tool was added to generate a proper production config for the lazy bundles. It rewrites the output from the bundle process (in jspm.browser.js) to contain only those entries referring to modules which are lazily loaded.
• Had to switch from build to bundle: The lazy module could not have been built in global format (as the app was before), so it was required to push both to the same module format.
• As a result, SystemJS, its polyfills and basic config files had to be added to production output. Note that SystemJS would have been required anyway for using angular's string format for lazy loading modules - it refers to use System.import, which is only possible with SystemJS or Webpack 2 atm.
• Thus, the production version now uses SystemJS.import to start as well.

Some things to note:

• The process of adding new lazy routes is not automated yet, although it is a little bit complicated. We might add a tool for this in the future (I'm still thinking about how).
• For each lazy route, an additional bundle has to be created. Atm., this is done using one npm task per bundle. We might consider to use a tool like jspm-bundler to simplify this process, especially since we might not be able to bundle concurrently due to the changes applied to jspm.browser.js.

@svi3c, have fun with reviewing 😄

[DorianGrey]

/ping @svi3c

[DorianGrey]

I've fixed the mentioned issues, and extracted the shared module declaration and handling to a different PR - https://github.com/flaviait/ng2-jspm-template/pull/41.

The problem: Since we annot roll-up our app to global, we have an increased bundle size of ~400K (from 892K to 1284K).

I'll see if there is a solution to this - although it seems to be a more general problem: Different from e.g. webpack, the resulting bundles are not really linked to each other, thus, completely bundling them might not work in terms of rolling up (that's why I'd moved the code to use bundle so that System.registerDynamic takes care of this). However, the SystemJS runtime would be required anyway - it's used by Angular to load the target module.

[svi3c]

Right. I think a different npm script for the alternative module bundling would be great, so we can merge this to the master branch. There is quite a bunch of npm scripts by now, but I'm reducing them step by step issue within #39. Maybe we can even handle this by a simple flag in the config file I'm introducing.

[DorianGrey]

I'm afraid this won't be an easy task, since the parts of the bundling process are rather tightly connected to each other, like here: https://github.com/flaviait/ng2-jspm-template/pull/38/files#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R212

The only valuable thing I can think would be:

• Provide a helper task for generating lazy routes.
• Maintain these within a config or another manifest file (either in on of the jspm config files, or another, more particular target file).
• (Maybe) update the corresponding source-files so that they access the lazy routes correctly in dev mode.
• To be able to generate the target bundles more dynamically, it would be required to move the bundle process to another task file, i.e. bundling via the public API, not the CLI.
• That would enable to dynamically check if there is a manifest for lazy routes, If there is, use "bundle" with the required dependency arithemetic, otherwise fallback to "build" with its current setup.
• Advantage: Offers high level of automization for a not-so-easy task.
• Disadvantage: Requires that the user does not manipulate the mainfest / config data or the created links manually, otherwise, things might be screwn up completely.

The only alternative would be to implement something like the tools in angular-cli already provide: Parsing the source and checking for use of lazy routes. Suppose this would be even more complicated - might be useful with a particular plugin, but these cannot be chained (atm.?) and thus would conflict with plugin-typescript. Kinda... problematic.

Thoughts?

[svi3c]

Yes, I'm currently implementing the usage of the JSPM API. Afterwards we may think of a well-suited solution.