Packaging into JS Files
After Java files have been converted to JS, each type's JS code is stored into a temporary file. Those temporary 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.
By default, 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 the resulting JS file is not reused and not cached in 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.template 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.