Application decoupling

[mgechev]

Purpose

Allow easier development of multi-platform applications with easy code reuse across them.

Make the entire client-side application and its dependencies, decoupled from the build process and encapsulated inside src/client.

Background

At the moment we have our client application in the src/client directory and the build-related tasks in tools. Although we have this separation, all the client-side related dependencies and testing configuration are global (test-main.js, karma.config.js, protractor.config.js).

This makes it unpractical to use the seed for development of multiple Angular applications for different platforms which are sharing common features.

For instance, in case we want to develop backend for the current application, which reuses some of the logic which is already defined by services in the client-side, we need to:

• Store all the server-side related dependencies in the package.json file where we have the tooling related dependencies and client side related dependencies.
• Have another testing configuration inside src/server.

This approach is not modular and has several drawbacks:

• If we need to build only the backend we need to install the dependencies for the backend, client and tooling.
• The configuration is not encapsulated and it could be confusing to have different versions of the same configuration files (for client in the root directory and for the server in src/server).

  Proposal

• Move all the files which are related to client-side configuration and logic to src/client.
• Have a single build for each individual application (i.e. leave the current build organization unchanged).
• Leave all build related dependencies in the package.json in the root of the project and move all others to src/client/package.json.

.
├── appveyor.yml
├── gulpfile.ts
├── src
│   └── client
│       ├── dist
│       ├── coverage
│       ├── app
│       ├── assets
│       ├── css
│       ├── index.html
│       ├── test-main.js
│       ├── tsconfig.json
│       ├── karma.conf.js
│       ├── package.json
│       ├── protractor.conf.js
│       └── typings.d.ts
├── tools
├── tsconfig.json
├── tslint.json
├── typings
├── package.json
└── typings.json

@NathanWalker's advanced seed should benefit a lot from the proposal above.

// cc @ludohenin @d3viant0ne @TheDonDope @nareshbhatia

[vyakymenko]

@tarlepp , your tree it's a seed project, and folder's like client it's a branch(some first app with same dependencies), then you add another branch, folder fo example admin, and we have one tree with 2 branches.

But, I agree with your point !

For sometimes, tree can be.

[vyakymenko]

@tarlepp , I was thinking about your point that you told in latest comment and have some real-world example of this seed vision. One project --> One seed, it's a must for good project support. One project can have multi-applications, real example:

• We need to create for Tetris game.
• It can have free and pay versions, all of them based on free version.
• Pay version have some additional features, more figures and no advertising.

So, we will have 2 folders client, client-pay for example. And by the way, the client-pay can import, extend client(base) functionality, and we can add another feature for pay version. We can update client(free) core for 2 applications.

So we build one project(angular2-seed) with dual-application.

[jerryorta-dev]

Idea 1:
The SystemJS builder requires a config and the main.ts file. It recursively looks for all the imports, then using rollup and tree shaking to create the build. You can use this feature to have multiple app files -- mainTetrisFree.ts, mainTetrisPay.ts -- to create different builds. Each main file can import the proper feature set -- free or pay -- as needed and a gulp task wrapper to support each.

Idea 2:
SystemJS supports conditional loading. You can import the appropriate feature based on environment flags.

Idea 3: In conjunction with the ideas above, features can be shared via namespaced npm modules.

Any idea requires you to contend with the <%= SOME_VARIABLE %> variables.

[jerryorta-dev]

My fork now has an example of SystemJS Conditional Substitution feature -- loading/building and app to include featureA or featureB based on configuration. This is just a PoC to see how you can handle decoupling with SystemJS.