Use different templateEngineOverride values for different pages in a pagination set

[zachleat]

What I really want to do is build two things from one source file -- output to manuscript/foo.md (to be consumed by leanpub) and also _site/foo/index.html

Reported by @zcorpan

https://twitter.com/zcorpan/status/1113803186693971970

(There may be a better way to do this, open to ideas)

[Ryuno-Ki]

Hm,in shell you would likely use tee for that. Here's an approach using writableStreams: https://github.com/jb55/node-tee (albeit needs an update regarding modern expressions)

[Ryuno-Ki]

Hey @zachleat
What about this: Instead of turning dat failes + markdown into HTML, turn them into a well-defined JSON.
Then offer hooks to grab that JSON and render it.

This way you could have a single point to render different formats from.

I imagine something along the lines of what istanbul.js is doing (I recall them having better docs on how to write a custom reporter - or did I confuse it with karma?)

This way, people could come up with weird ideas. Like https://jsonfeed.org/
Or using Eleventy as kinda headless CMS etc.

WDYT?

[zachleat]

Hmm @Ryuno-Ki I’m not sure what you mean—can you elaborate? What would the standard JSON format represent?

[Ryuno-Ki]

Okay, then let me explain it in more detail.

First off, I'm coming from an MVC background (Ruby on Rails, Django etc).

There, in a view method, you would compute a context object and pass it to a template. This way you render the output format (e.g. HTML or JSON or LaTeX or who-knows).

My mental model was now like this:
Eleventy is currently built up of several parts:

• Markdown files
• Data dirs
• Layout files
• Utilities (filters, shortcodes, plugins etc).

I assume that you compute some kind of context object from the markdown files and data dir. Then passing each of those to the specified layout (either set in frontmatter or data dir - at this point likely doesn't matter).
The resulting HTML is then written to disk.

What about allowing to hook into the computed context object?

It would need to be well defined.
That is, the JSON schema must contain all relevant information (metadata, content, source file, ...).

Then ... renderers could pick those context objects up and treat them like they please (e.g. passing it to a layout file, change the type of the layout template language or so).

It's something I liked on harp.js. Harp.js can even be used as middleware to express.js!

But being able to make network requests at build time + layout hierarchy are niiicee also :-)

[Ryuno-Ki]

Maybe would allow things like #488 as well.
E.g. transforming information from other JAMstack/CMS to a single format.

[Ryuno-Ki]

Hm, or I am thinking too far ahead. What about working together with HTMLx instead?

You're already supporting quite some template languages...

[zachleat]

Just FYI, the next large feature on the roadmap is #117 which will decentralize the template language support from Eleventy core, allowing plugins to add their own custom extensions and support template languages.

But let me stew on what you’ve said here a bit more.

[Ryuno-Ki]

Yeah, I can see, how this would play into what I envisioned.
Would be a good time to address #405 (comment) after its release, I think :-)