JS modules are still bleeding edge but they're a necessary requirement to put the facade pattern to work.
Each library should ideally be separated into multiple modules internally.
The main source file imports all submodules by default making it easy to get started.
import 'rxjs';
As a project matures and it comes time to optimize dependencies for performance, the main import can be swapped with feature-specific imports to trim the fat.
import { Observable } from 'rxjs/core';
import { FlatMap, Debounce} from 'rxjs/operators';
Optionally, an additional facade layer can be included to import specific classes of submodules.
import 'rxjs/operators';
Or, alternatively:
import { OPERATORS } from 'rxjs';
A facade is nothing but a js file that contains a bunch of imports that are logically mapped to one or more exports.
The 'real' issue is, it wasn't really possible to use this before the ES6 module standard because of the divergence of implementation-specific features of the existing module pseudo-standards (ie AMD, UMD, CommonJS) and the overreliance on bundling required by the expensive overhead of HTTPv1.
JS has a lot of baggage and it's going to be a while before the community as a whole learns how to design non-sucky APIs.
If you want to see this in action, take a look at http://github.com/evanplaice/ng2-resume. In it, I use facades extensively at multiple layers to compose smaller components/directives into larger ones. It maximizes reuse while allowing a great degree of flexibility.
I still have freedom to break off chunks of the source for reuse elsewhere. For example, I'm planning to move the models to a separate repo for use on the server-side. It's trivial to bring those chunks back in via the ES6 module loader and a package management utility like JSPM/Webpack.
Not sure why this touched a nerve enough to be downvoted into oblivion. If it was the cheeky tl;dr I guess I can make a point to avoid any and all attempts at sarcasm in my future posts.
As for the rest, I genuinely think it's a useful approach to consider
1. it's relies on future web standards not tools
Tools come and go. Web standards never go. If the goal is to avoid technical debt, then don't write code in a way that will eventually be obsolete.
2. 'Abstractions are the solution to every problem, except the problem of too many abstractions'
Except, when there's a viable strategy to provide access at multiple layers of abstraction. If we're finally getting a truly universal module standard, why not leverage it to improve our library APIs?
It's not like we have to waste the time/energy/effort supporting multiple module non-standards anymore. The approach I outlined above provides much better usability with very little effort on the part of the dev implementing an API.
3. It doesn't rely on approaches that will eventually be obsolete
Namely bundling. Tree shaking is great if the end goal is to analyze all dependencies and create an optimized bundle.
Except for the fact that bundling will become an anti-pattern when HTTPv2 reaches widespread adoption.
Tl;dr: Y'all need better API designers.
JS modules are still bleeding edge but they're a necessary requirement to put the facade pattern to work.
Each library should ideally be separated into multiple modules internally.
The main source file imports all submodules by default making it easy to get started.
As a project matures and it comes time to optimize dependencies for performance, the main import can be swapped with feature-specific imports to trim the fat. Optionally, an additional facade layer can be included to import specific classes of submodules. Or, alternatively: A facade is nothing but a js file that contains a bunch of imports that are logically mapped to one or more exports.The 'real' issue is, it wasn't really possible to use this before the ES6 module standard because of the divergence of implementation-specific features of the existing module pseudo-standards (ie AMD, UMD, CommonJS) and the overreliance on bundling required by the expensive overhead of HTTPv1.
JS has a lot of baggage and it's going to be a while before the community as a whole learns how to design non-sucky APIs.
If you want to see this in action, take a look at http://github.com/evanplaice/ng2-resume. In it, I use facades extensively at multiple layers to compose smaller components/directives into larger ones. It maximizes reuse while allowing a great degree of flexibility.
I still have freedom to break off chunks of the source for reuse elsewhere. For example, I'm planning to move the models to a separate repo for use on the server-side. It's trivial to bring those chunks back in via the ES6 module loader and a package management utility like JSPM/Webpack.