Description
Several things to implement:
Alternative Modulo.js builds
Once Modulo.js's source code is more stable, it's time to create alternative versions of it. New
New repo structure
/Modulo.js
/alt/Modulo.prod.js
/alt/Modulo.core.js
That way, when you version pin Modulo with unpkg, it's easier to remember as well, e.g. unpkg.com/mdu.js@1.2.3/Modulo.js
Implementation of /alt/
Write a simple bash or npm script that "snips" the Modulo.js source code at specific locations specified by comments, e.g. [END OF Modulo.core.js], or if the snips are in JS as well, something like // - - - - SNIP - - - - (Exclude below from build) or something (e.g. both descriptive to humans and an unlikely thing to ever occur)
commands.buildslim
New "buildslim" command that applies SNIPs, and/or asset manager can try to substitute /Modulo.js for /alt/Modulo.prod.js during build.
Modulo.prod.js
Only what's needed for running in production. This excludes all processors. This will only include, then:
- Most of the core Modulo class
- All the CPart classes (but not their defaults, or associated definition processors)
- Reconciler, DOMCursor
- template filters, a few parts of Templater (but not template tags)
- Some utils
Will need to refactor to get defaults in one spot, and eventually extract irrelevant parts of Templater and Modulo into separate things. One idea: Make it more like modulo.registry.cparts = class State { to really keep it separate. Also possible to programmatically snip, e.g. base it on entire lines that look just like that with class ClassName {, and then use configuration to "snip" based on ClassName's, until the next } that is followed by modulo or the end of the file.
Modulo.core.js
A tiny core of features to allow loading of CParts, so a custom Modulo build can be made, but no bundled CParts, utils, bundled templating language, reconciler, etc. Those can all be included separately (e.g. in separate JS files), so it's easier to "remix" Modulo into a new framework.
Sparse def
Sparse def: Factor out the repetitive code in definitions that would be loaded by defaults (i.e. subtract the keyset of config defaults from the keysets found in moduloBuild.definitions).
A KISS, non-recursive approach that renders the "defaults" as JSON, then renders definitions 1 deep into window.moduloBuild.definitions.x_MyDefinitionWhatever = Object.assign({ }, window.moduloBuild._defaults.Script, { removeKey: undefined, otherThing: "okay" });
The simplest algo would be "defaults-like", but just find "the most common setting" and create a base obj that way (with "undefined" being an option for a value as well, also allowing sub settings to "unset" by setting undefined), then another O(n) passover loop to trim all undefineds. (Maybe even a messy oneliner like: (() => { for (const def of Object.values(window.moduloBuild.definitions)) { for (const key of def) if (def[key] === undefined) delete def[key]; } })())
- NOTE: Might want to profile, could go either way in terms of what's faster. It might be that "unrolled" defs parse or load faster as a single data structure, and that gzip is good enough to find repetitive substring runs in the source code that the gains from semantic refactoring would be nearly erased
- Alternatively: Don't include defaults, but find a "largest subtree factoring" algo?
window.moduloBuild._subtree['xe32f4ae']