Hi, I just pushed a rudimentary version of modules. Regular Flex Modules were separate SWFs of classes that could be compiled separately from the main application and loaded after application startup as well thus helping to manage development time and startup time and download bandwidth.
FlexJS modules work pretty much the same way, although we currently don't have a way to unload modules from memory. For SWF, a module is a separate SWF. For JS, it depends on whether you are running in debug mode or not. The production module in bin/js-release is a single .js file with a companion .css file but no HTML wrapper. It is simply loaded as a <script> tag into the main HTML wrapper. For debug mode, the result of compiling a module is a ton of JS files just like the js-debug folder of a FlexJS application, and a XX__deps.js file that contains the goog.addDependency calls for the module. I couldn't find a way to get GCC to not care about the framework JS files that are already in the main application's js-debug folder, so there is a duplicate set of JS files for any FlexJS class that both the main application and module use. The XX__deps.js file needs to be tweaked to indicate the correct path to the module's js files, but the framework js files that are unique to the module need to be copied into the main application's js-debug folders. Also note, because we don't have a way to get GCC to not care about framework JS files used in both the main app and module, the production module's JS file contains duplicates of those common classes. In theory though, it should be possible to write a tool that extracts the shared classes from the module's JS files. In getting it to work so far, I've learned some potentially interesting things. We can use a mapping file to control the production name of the classes, but I don't think it can be dot-path. GCC generally renames those package dot-path expressions into a single variable like org$apache$flex$core$UIBase. Then GCC replaces that name with an even shorter name like "P". Production modules work by controlling the variable renaming in the module so that if UIBase gets renamed to "P" in the main app, it also is "P" in the module. We could use more friendly name, but I don't think it is worth the extra size. But it does generally mean that a module can only work with a main application it is paired with because we need to use the same renaming map for both application and module. This was sort of true in regular Flex in that a regular Flex module often depended on classes being already loaded by the application. -Alex
