Passing values to component?

[96312]

Currently I have a post layout that is imported in my frontmatter using this alias =
eleventyConfig.addLayoutAlias('post', 'layouts/post.njk');

Can I also create components that I can directly pass values to? and import inside my actual post? Something like =
{% include "components/title.html" %}
where title.html lives inside /components -> takes the value of current title or whatever I pass into it -> formats it a certain way -> spits it out in my post?

I don't wanna copy and paste the style every time and want to use this formatting on different texts throughout.

That possible?

[96312]

Oh and if this is possible, can I create aliases for it to easily include it?

[96312]

Okay, here's some code which'll make it easier for you understand what I want.

<div>
    <ul class="gap-4 flex flex-col">
      {% set latest_posts = collections.posts %} {% for post in latest_posts %}
        <li class="list-inside">
           {% include "components/card.html" with url=post.url title=post.data.title %} < ---- this possible???
        </li>
      {% endfor %}
    </ul>
</div>

Where my card.html looks like this:

<div>
    <a href="{{ url }}">
        <h1 class="text-lg">{{ title }}</h1>
    </a>
    <p class="text-sm"> Click the link to go to the post.</p>
</div>

Right now, I'm just putting the whole card.html thingy inside the <li> and passing url and title values but I want it neater you get it??

[pdehaan]

I know you can do something like that w/ LiquidJS templates, but not sure about .njk files.
One option might be converting to a custom shortcode, which might look something like:

{% card post.url, post.data.title %}

Or just pass the entire post object to the card and let it extract the url and data.title props.

[96312]

@pdehaan BTW one area where the shortcode wins is that I don't have to import it again and again for each file like I have to with a macro.

[edwardhorsford]

@96312 two things that can help with that -

Define all your macros in a single file, then import that single file only. Like this:

{% import "macros.njk" as macro %}

You can then use any of the macros in that file like this:

{{ macro.foo(args) }}

You still need one import per template. There's a partial solution, but it's not perfect.

[96312]

@edwardhorsford Yup, I ended up collecting all my small ones into a large file then imported it. Thanks for that link but I'll not use it. Hope 11ty changes to make it easy to import macros in the layout I'm inheriting.

What's the with context you mention in {% import "includes/macros.njk" as macro with context %} something special?

[edwardhorsford]

@96312 with context allows the macro to access the Nunjucks context. So this would mean it could have access to any page data / global data, etc without it having to be explicitly passed in - just like an include has access to the context from where it's called.

Not everyone likes to use it - some prefer to explicitly pass in all the required data. I use it sometimes where my macros need to look up data from my Eleventy collections.

[96312]

@edwardhorsford Cheers Ed, aint it nice that's an option too? Thanks for clearing that up you're a right legend.

[edwardhorsford]

If you're using Nunjucks and want to explicitly pass data along you can look at macros.

[pdehaan]

This! And I was also going to mention Nunjucks' kwargs: https://mozilla.github.io/nunjucks/templating.html#keyword-arguments

[pdehaan]

{% macro %} docs, plus this ominous sounding note in the Nunjucks docs:

Note

If you are using the asynchronous API, please be aware that you cannot do anything asynchronous inside macros. This is because macros are called like normal functions. In the future we may have a way to call a function asynchronously. If you do this now, the behavior is undefined.

[pdehaan]

@edwardhorsford Is there any benefits to using a Nunjucks-specific macro vs a more 11ty-esque custom shortcode? 🤔

[96312]

@pdehaan @edwardhorsford Alright, I looked at macros and shortcodes. They both work for my purpose. Thanks for the suggestions.
context: my markdown, html and data template engines are all njk.

Any reason why I should prefer one over the other? My order of preference:

1. Ease of code maintenance.
2. Code readability and compartmentalization (if possible)
3. Set and forget it kinda deal when using them.

[edwardhorsford]

@pdehaan I've been using Nunjucks for far longer than I've been using Eleventy, so mostly it's because I'm more comfortable with them. I'm very used to using macros combined with filters (81 macros and 122 filters and counting). My reasons are below:

• I prefer the more functional syntax of name(...args) over name arg, arg
• If I ever leave Eleventy I'm almost certainly going to still be using Nunjucks - I'd prefer to keep to native templating things where possible.
• In Nunjucks, {% is used for expressions, whilst {{ is used to render to page. Eleventy using {% just feels 'wrong' to me.
• They're pure templating, so can be more suited to html based manipulation.
• Named args - though in truth I rarely use these and instead usually pass an object with my params.
• Nunjucks logic is generally more fault tolerant than js - you can do the same things in js, but often need to be more careful. (For example in Nunjucks you can safely read undefined nested properties and it'll just invisibly fail / return '' - whereas in JS you'd break the build.) - this can make templates simpler.

Some downsides:

• They're at the templating layer rather than js, so aren't automatically available in templates - you need to import them in to each layout / page, or else do some hacks. I really don't understand why Nunjucks doesn't have a better way of adding them at an app layer.
• They're pure templating rather than javascript - though within that template you could call out to filters / functions / javascript. For complex data manipulation you'd still probably want to use javascript - I might use filters with the macro in that case. But if your macro is mostly js manipulation / complex data stuff, a shortcode might well be easier.

@96312 I think both probably satisfy most of your requirements. And you're probably not locked in if you change your mind. Shortcodes are more js based, and macros html/templating based - and so it partly depends what you wan to use them for. The usage you've indicated is exactly what they're intended for, but shortcodes will also work well for it too.

---

Not so related to this discussion which I expect is about reusable bits of template across an app - but macros can also be helpful for just a single page - if I've got a repeated element on a single page I may often make a macro out of it declared at the top of the page.

[edwardhorsford]

You can of course mix your approaches. I actually made my first shortcode the other week - one for rendering markdown in a Nunjucks template (where I explicitly don't want the template as a whole to be markdown). Using the shortcode the syntax ends up very nice like:

{% markdown %}
## A second level heading
{% endmarkdown %}

The equivalent macro would be:

{% call markdown() %}
## A second level heading
{% endcall %}

But then the macro would just have to pass the content out to a filter or a Nunjucks global so that you can use js to render the markdown. A shortcode is much cleaner / simpler.

[96312]

I appreciate the explanation Edward.

[bobmonsour]

If I might chime in, there's also another method, using 'include'. If you want to achieve what you showed originally, i.e.,

{% include "components/card.html" with url=post.url title=post.data.title %}

You can do this:

{% set postinfo = post %}
{% include "components/card.html" %}

And then you would refer to postinfo.url and postinfo.data.title in your component.

And if 'post' is already available in the context of every place you want to do the include, then you do not need the 'set' statement.

Note that I ran into something earlier today where my include contained a reference to an async filter, which won't work inside of an include. The fix was to set a variable that used the filter prior to the include so that it would be available in the include.

Hope that makes sense.