For complete architecture examples using this technique you can consult:
-
In the browser, NPM dependencies have to be bundled separately in lib/vendor JS file
Modular provides a pattern to consume NPM libraries safely.
-
Haxe-JS code and sourcemaps splitting, and lazy-loading
Code splitting works by identifying features which can be asynchronously loaded at run time. JS bundles can be created automatically when using Modular's async API.
-
Hot-reload
Modular offers code hot-reloading capabilities.
Add -D modular_dump to your Haxe compiler arguments to generate a size report as an extra
<output>.stats.json, and an interactive visualisation of this report, as an extra <output>.stats.html.
Viewer usage: click a group to reveal more details, press Escape or click the Back button to navigate back.
Modular recognises a few additional flags:
-D modular_nomaps: disable sourcemaps processing,-D modular_debugmap: generate additional debugging file (<output>.json,<output>.graph), and for each module, an extra.map.htmlfile showing a visual representation of the sourcemap.
Using reflection (e.g. Type.resolveClass) doesn't create link between classes, so such
types will land in the main bundle. It can be controlled
If you don't know what static __init__ is, don't worry about it!
(if you're curious)
When using __init__ you may generate code that will be difficult to attribute to the
right context:
- assume that
__init__code could be duplicated in all the bundles, - unless you only use calls to static methods.
class MyComponent
{
static function __init__()
{
// these lines will go in all the bundles
var foo = 42;
untyped window.something = function() {...}
// these lines will go in the bundle containing MyComponent
MyComponent.doSomething();
if (...) MyComponent.anotherThing();
// this line will go in the bundle containing OtherComponent
OtherComponent.someProp = 42;
}
...
}