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.html
file 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;
}
...
}