A way to create an engine that can retrieve templates dynamically

[ckknight]

In the event that a dev stores a template in a database or otherwise not on a local filesystem, there could be a way to allow them to provide something of a dynamic filesystem.

There should be really only two functions that need to be provided:

(1): a way to retrieve the (precompiled) template given a path, as well as an mtime or some other cache identifier
(2): whether or not a template is out of date, based on the previously provided mtime or cache identifier.

[awwright]

So I'm not sure exactly how egs works, but usually when parsing out data, for a template or some other system that makes external references, you have to break down the system a bit:

• A compiler that accepts a template and a cache of templates that may be referred to, and outputs a largely self-contained Function in the form of function(data) -> string
• A parser/lexer that parses the template string into a data model in memory
• An importer that accepts parsed (but not yet compiled) template, a cache to write to, and a dereferencing function that accepts a template name and returns a Function that is the compiled template. This importer determines which external references are made within the template, and asynchronously imports them to the cache, for later use by the compiler. If necessary, the dereferencing function compiles the template, which shouldn't necessarily need to be the same template system (maybe I have a e.g. Jade template that's been provided to me; or I have a function that directly returns a string, and I don't want to use any template system at all)

[ckknight]

I don't plan on exposing the cache system outside the internals, it seems highly unnecessary.

Being able to provide a function that returns a string that is usable from inside a .egs template is quite doable now, you just pass it in the context property of the options. You can also provide a Promise<string> and yield on it without issue, allowing you to plug in other template languages with minimal pain.

[awwright]

The purpose of a cache is to provide the compiler with the complete collection of templates it's going to be using, including the target template, thus isolating the parts of the template system that require asynchronous operations, e.g. fetching from the database or fetching off the filesystem. So I don't know how you don't expose it, it's kind of necessary.

[ckknight]

Oh, that's already handled through the Package system. You can compile a directory of .egs templates into a single .js file, making it not use the cache that would normally be required for the filesystem.

[awwright]

It seems like there's two different utilities doing the same function then, that serve as an in-memory storage location to retrieve templates from.

Ideally I should be able to gather a collection of templates, even of different source formats, collect them all in memory, and pass that to the respective compilers without any asynchronous operations.

[ckknight]

Well, the Package system doesn't hold templates, it holds compiled functions. That's why you don't need the full egs, just the runtime portion. In order to jury-rig other templates in, they'd need to also be precompiled, and trying to get it all to fit nicely is something extremely low priority for me, especially when you could simply provide a function to the egs template system to do it for you. { context: { renderJade: someFunction } }. However that function works is an exercise for the reader.