Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nonchip opened this issue Aug 7, 2019 · 12 comments

Comments

@nonchip
Copy link

commented Aug 7, 2019

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)?

@nonchip nonchip added the education label Aug 7, 2019

@nonchip nonchip changed the title (how) can I add a custom template "engine" / file type? (how) can I add a custom "renderer engine" / file type? Aug 7, 2019

@Ryuno-Ki

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

Would you upvote #117?

@nonchip

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

i prefer instantly readable code

Enter Python!

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

@nonchip

This comment has been minimized.

Copy link
Author

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 9, 2019

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

This comment has been minimized.

Copy link
Author

commented Aug 10, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 17, 2019

: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

This comment has been minimized.

Copy link
Author

commented Aug 17, 2019

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

@nonchip nonchip closed this Aug 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.