Age | Commit message (Collapse) | Author | Files | Lines |
|
The order in which .js files are concatenated is (and always has been)
important, so rather than relying on name order I've changed that to an
explicit $JS_FILES list in the Makefile. Less convenient, but at least
we have more freedom regarding .js file naming and organization now.
Rather than encoding the Elm flags as JSON in 'data-' attributes, I've
added a system for global page variables (pagevars) where the Elm flags
are now stored separately from their HTML tags. This has the advantage
of more efficient encoding (no more "s), faster parsing (just a
single JSON.parse()), and easier/more efficient modification of the Elm
arguments from JS. The pagevars provide a unified way of passing other
variables to JS as well, which I've used to deduplicate the list of
labels on the new ulist page. That shaves off a good 40 KiB on the page
size for a typical listing.
Whether all of this actually improves the page loading time, I don't
really know. Most of the slowness in Firefox seems to come from simply
instantiating many <input time="date"> objects.
|
|
|
|
option
Elm has a bug where the 'selected' attribute is not properly propagated,
that's fixed by patching the generated JS.
Also moved Ffi.js one level up, as it's important that that file is
loaded before any Elm modules are initialized.
|
|
Most of this is copied from v3. I did improve on a few aspects:
- db_edit() and db_entry() use VNDB::Schema rather than dynamically
querying the DB. This has the minor advantage of a faster startup.
- The Elm code generator now writes to multiple files, this avoids
the namespace pollution seen in v3's Lib.Gen and makes the dependency
graph a bit more lean (i.e. faster incremental builds).
- The Elm code generator doesn't update the timestamp of files that
haven't been modified. This also speeds up incremental builds, the elm
compiler can now skip rebuilding unmodified files.
- The Elm API response generator code now uses plain functions rather
than code references and all possible responses are now defined in
Elm.pm. Turns out most API responses were used from more than a single
place, so it makes sense to have them centrally defined.
The doc page preview function is also much nicer; I'd like to apply this
to all BBCode textareas as well.
(Elm.pm itself is ugly as hell though. And we will prolly need some HTML
form generation functions in Elm to make that part less verbose)
|