Packaging into JS Files
After Java files have been converted to JS, each type's JS code is stored into an intermediate file. Those intermediate files are then assembled into one or more JS files loaded by the browser. There are two mechanisms you can use for controlling how this packaging is performed.
One option is to use the jsModuleFile annotation on your classes. When you do this, all Java types using the same module are put into the same file. That file must have an ordered list of dependencies against all other types in how they are packaged in JS files. It's a conflict if one jsModuleFile depends on another which depends back on itself. TODO: this is primarily a problem when one class extends another in a different module which extends a class back on itself. Because we are loading the classes in each module file all-at-once, we need to determine the proper order and can't include a module file which may require the constructor of a downstream module to already be loaded. Today, we treat all dependencies the same as well so there's no way to figure out the proper order, if there is one which preserves the 'extends order'. I think the JS way to solve this is to create the classes dynamically from objects, so each class resolves it's extends class as soon as it's needed but something about that probably adds overhead.
If you don't use modules, StrataCode figures out all of the entry points required for a given HTML file, and puts all unassigned Java types that are used by those entry points into that file. With this approach, types which are not referenced are not included in the resulting JS file making it smaller, but there's no reuse of the lower-level pieces so they'll be downloaded again for each application loaded into the browser.
A subset of Java's utility libraries (ArrayList, HashMap, etc.) have been added to the framework. Those were all just copied from the apache Java project into the js/sys layer. When there are native dependencies in types you must simulate that code in native JS. The native Java types are hand-written in the file js/javasys.js.
Using the JS System
Include the js.schtml layer if you want to use schtml files as well that are compiled to .java files, then to .js files for loading along with the default runtime.
- typeTemplate: Override the frameworks type template used to generate code for this type and subtypes
- prefixAlias: Registers an alias for this types package to use as the prefix instead of the default convention of pkgApkgB
- dependentJSFiles: Comma separated list of jsLibFiles which this lib file depends on being included before it. This sorts the order of the jsFiles property available to templates for generating the list of scripts to include.
- jsModuleFile: Set this for library code which you want to group into a separate .js file. By default, all .js files are loaded into one main .js file.
Naming Conventions, and Runtime Rules
- In place of super, the SuperType_c.method.call(this, ...) pattern is used.
StrataCode initializes all fields with null before accessing them. If you hit "undefined" when accessing a field that should be there, that's a bug. Because of that assumption, it uses fieldName !== null instead of fieldName !== undefined in all comparisons.