Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pdb_ng2: Bundling strategy #64

Open
mrjmd opened this issue May 27, 2016 · 1 comment
Open

pdb_ng2: Bundling strategy #64

mrjmd opened this issue May 27, 2016 · 1 comment

Comments

@mrjmd
Copy link
Owner

mrjmd commented May 27, 2016

Especially with the release of RC1 for Angular 2, our request numbers are out of control. Now that we have a basic update in place, we need to get some bundling going on to reduce our requests.

Since we can't know in advance which components will be on a specific page, we're going to rely on a base bundle of core assets. Per-component bundling will come after that.

Also offline template compiling should be incorporated into overall bundling strategy.

The ultimate goal would be to get in place a bundling strategy that for any given page will strike the appropriate balance between cacheability and reusability.

@mrjmd mrjmd changed the title pdb_nd2: Bundling strategy pdb_ng2: Bundling strategy May 31, 2016
@mrjmd
Copy link
Owner Author

mrjmd commented Jun 26, 2016

My stopgap measure for upgrading to the RC's was to rely on the umd.js packages provided by npm. I'm doing this for all the ng2 packages as well as rxjs... but this is obviously not an ideal solution. For now it's keeping the request numbers down and is better than the full front loading of the framework we were doing with ng2 betas, at least.

I've done a lot of thinking about this but it is a pretty hard problem. Bundling appropriately is complicated by the fact that which components will appear on any given page is dynamically driven by which blocks are placed via the UI.

I was recently pointed to the System bundlers trace API (https://github.com/systemjs/builder#example---direct-trace-api), which gives us a lot more control over how we determine joint dependencies between components.

I've been thinking about a recursive version of trace API, where we first create component bundles, and then page bundles, and then vendor / app bundles. Having bundle generation triggered by block placement regardless of placement UI (core blocks, panels, etc) is no easy task, and may force a node.js requirement on the production box, as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant