Addition of support for template languages other than Dust

[josephdenne]

No description provided.

[eduardoboucas]

@josephdenne Are there any particular engines you'd like us to start with?

What I've done so far is fully decouple Dust from the core and turn it into its own module interface, similar to what @jimlambie has been doing for API data stores. This interface consists of a set of standardised lifecycle functions that core will expect engines to implement (and will validate against).

We can start taking this interface and building support for the various engines we want to ship with, but it also allows the community to build their own interfaces to add support for additional engines. This would happen in the same way they can currently install custom Dust helpers and filters, which effectively needs you could use virtually any templating engine with Web without having to touch the core.

Any thoughts appreciated!

[abovedave]

Template engines I think we should start with (I can help write these modules @eduardoboucas)

• Dust.js 😄
• Liquid - we can capture more of the Jekyll audience
• Pug - by far the most popular on (14.2k ⭐️ on github)
• ES6 templates? (super fast!)

[abovedave]

Further points from Slack:

1. The concept of 'post-processing' could be added in as apart of this (relates to feat: beautify #154 #162 that we're not merging). This could work exactly like events do for page data, but for the output of the template engine - a .js file which you can use to run the html out through, similar to this.

2. Having the file extension of templates be customisable in config.json

{
   "templates": {
        "engine": "dustjs-linkedin",
        "extension": "html"
    }
}

3. Setting up the require structure so the engine is included via npm install in your project package file, rather than that of Web so we keep install times and bloat down.

4. @eduardoboucas thoughts on having this module folder (optionally) be in the workspace? We could have plugins/engines so we can extend it later. We already generate a default workspace folder when using npm install @dadi/web so we could add Dust.js as a default here.

[eduardoboucas]

Thanks for the feedback @abovebored! I'll let you know once I've finished the module interface so we can start integrating some engines.

On your points:

1. Agree. I've already built some lifecycle functions into the modules (e.g. getInfo(), initialise(), render()), so I can add another one that receives and optionally modifies the markup right before it's sent to the client.

2. I think this should be part of the engine's files, so each engine announces its name and the list of extensions it handles. Do you think we should be able to override this in the app, so saying that actually .html files are handled by the dust engine? Wouldn't it be better to have each page schema override the default engine for its extension? Effectively this would mean you could have one HTML page being rendered with dust and another one with liquid.

3. I agree, this would reduce install time. On that note, there's another optimisation I've included in what I have at the moment: engines are only ever initialised, and their dependencies loaded, if/when there's a page that requires it. These two would play nicely together, and it would ensure minimum installation/compile time.

4. At the moment I have a dadi/lib/templates directory, with a few classes I've introduced (like Template and TemplateStore), as well as some helpers. Inside that, I have a engines directory where the engines we'll ship with core live (at the moment there's only dust). My idea was to have core engines in this directory but also load any engines from workspace/engines, in the same way that we load Dust helpers.

I'll push what I have so far to a branch. It won't be ready for a while, but at least we'll all be able to see the shape things are taking and feedback as we go.

[abovedave]

1. ✅
2. I agree with the flexibility of per-page configuration 💯 (it would be super useful for migrating sites over onto the platform AND into a new engine!). I'm saying both - it can be overwrote at global level too, to save repetition(?) Priority would be, to clarify:

1. page.json defined engine and extension (N.B. we already have a template field to tell it which file to render with)
2. config.json for global level
3. Defined in the engine definition file e.g., dadi/lib/templates/dustjs-linkedin.js

Background: It's quite a volatile area for discussion - everyone seems to have a different opinion (see this thread for Django), so I thought of this solution so people can control globally what extension they use. Obviously we can set a default that makes the most sense per language.

3. ✅ Damn that's slick. Slightly related: what's your view on loading modules with an fs.readfile vs a bundle (looking at the way data providers are loaded).

4. ✅

[abovedave]

Side-lol: remember the CSS Zen Garden? It would be funny to do a version of that with multiple template languages!

[jimlambie]

One more thing... please update and add/delete tests as you go?

[eduardoboucas]

@jimlambie Absolutely! 👊

[jimlambie]

Closed by 1255df3