flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject [FLEXJS] Modules
Date Tue, 15 Aug 2017 21:01:33 GMT

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.


View raw message