(how) can I add a custom "renderer engine" / file type?

[nonchip]

I'd like to add a custom "renderer" for a specific file type, but the only part that kinda looks related (static get TemplateEngine::templateKeyMapToClassName) seems very static, is there any way to do this?

I need files of a specific ending to have their front matter and (if any) liquid tags etc parsed and then want to supply a function(data,content){return html} (that then gets passed along through the content of the layout engine etc), essentially just replacing the markdown/html parsing part of the chain.

so just like a .md file gets passed through frontmatter, liquid, markdown, and layouting, i want my .something file get passed through frontmatter, liquid, my function, and then layouting.

since I will use the frontmatter, I feel I could also do this via a custom layout file maybe, though, not really understanding the 11ty.js format, I don't know how I would actually write that and also prevent eleventy from trying to parse the content through another renderer before passing it to my layout (would just calling it .liquid or .html suffice, to make it essentially just pass through the contents after parsing any shortcodes/etc)?

[Ryuno-Ki]

Would you upvote #117?

[nonchip]

@Ryuno-Ki done that.

also figured out the .11ty.js format, and was able to implement what i wanted as a layout.

for future reference, this is the code i came up with, parsing yaml+markdown content into html to allow for declaring "map markers" on an image; shortened to the important bits (my actual code does more calculations to make the pins i declared position/orient nicer, and obviously needs some additional css):

// my_layout.11ty.js
const yaml = require('js-yaml');
module.exports = class {
  data() {
    return {
      layout: 'page' // my main layout for most pages
    };
  }
  render(data) {
    var self = this;
    var out='<div class="map">'
    var map = yaml.safeLoad(data.content);
    out += `<img src="${map.img}" />`;
    map.pins.forEach(function(pin){
      out += `<div class="pin" style="left: ${pin.x}%; top: ${pin.y}%;">${self.md(pin.text)}</div>`;
      // self.md is just a filter i declared that just runs markdownIt.renderInline, to allow for nested markdown here
    });
    return out+'</div>';
  }
}

---
# map.liquid
layout: my_layout
---
img: {{'/assets/img/map_bg.png'|url}}
pins:
  - text : "[Center]({{'/universe/center'|url}}) of the universe"
    x : 50
    y : 50

[Ryuno-Ki]

Do yourself a favour and add an alt attribute to your <img />s :-)
If you have some meaningful description of the image, that should go into it. Otherwise leave it as empty string.

[Ryuno-Ki]

Oh, and instead of a String concatenation (which absorbs your memory in no time), you can put the parts into an Array and run a .join('') over it (learnt that in Python land ;-) )

[nonchip]

well it's literally the background image for a map i'm marking places on using that code, sooo don't really see any way of describing that meaningfully. why would you advise adding an empty alt?

also that tiny bit of memory isn't really an issue for me (got 32gig of that stuff, and only need it when i deploy the site, got not a single line of js actually running in a browser; also python land memory management doesn't translate to nodejs necessarily), i prefer instantly readable code :P

[Ryuno-Ki]

Valid HTML demands the presence of an alt attribute. For decorative purposes, it is recommended to set it to an empty string. Otherwise (= it contains information), that should go into the attribute.

[Ryuno-Ki]

i prefer instantly readable code

Enter Python!

(Honestly, I hear that argument on both ends …)

[nonchip]

Enter Python!

yeah no thanks, enter moonscript :P

i'd never claim javascript was readable, i just said += is more readable to me than messing with a string array there :P

[Ryuno-Ki]

Oh cool! I was about to learn Lua anyway. Will take a note to look into MoonScript at a later point. Thanks!

What += does is to repeatedly allocate memory for the next string and then copy over all the previous content to its start (since Strings are immutable). Thus wasting memory.
With an Array.join you could give the interpreter / JIT compiler a better hint on what you are about to.

[nonchip]

interestingly, it seems like += is actually fastest though in modern engines: https://jsperf.com/string-concat-without-sringbuilder/13, and while that doesn't measure memory overhead i'm only working with pretty small strings here and only at compile-time, so i think until i really need to sacrifice source niceness for optimization i'm gonna stick with my "nice because less abstracted code" and let node do its job.

[zachleat]

:D are we good here to lump this in with #117? I believe the code for this is ready-ish in the too-much-static branch but it will not be shipping with 0.9.0.

[nonchip]

sounds like it yeah. and until it ships my layout hack works fine :)