Perform a single pass so the work of doing `m` replacements in a string
of length `n` is O(m + n) instead of O(m * n)
For the yogalogy template this change improves the script munging step
from ~2.5ms to 0.5ms [release] (from ~17ms to 3ms [debug]).
Factor out the content code from the supporting editor. The next step is
to derive the visual CMS editor from the content codebase. In theory the
system will work like this:
A user would edit the view functions in src/Components/* with a Figma style
editor and write the changes back to the source Elm file.
A second tool will inspect the source directories looking for modules
that expose (route: astrid-pages/core/Astrid.Pages.Route). It will allow
a user to visually define and edit routing rules that decide which
module should handle each request. This tool compiles the routing rules
and source files into a standalone binary.
A third tool will generate a visual CMS that modifies the view functions
of each route to insert clickable targets on components. These targets
will open database record editor modals for the rows that generated that
specific HTML. This is achieved by engineer cooperation via annotations
rather than static analysis. This visual CMS can hot reload itself when
the view functions are changed by the first tool.
A fourth tool will generate an AirTable style database editor from the
type definitions found in src/Database/* modules.
The automated operation of these tools allows a non technical user to
edit the appearance and data of a website in cooperation with software
engineers define the data structures. The simple nature of Elm prevents
the engineers from being so creative the tools cannot understand what is
going on. And Elm checks the work of non technical contributors for any
conflicts with the engineers' design.
