A layout using another layout as a base

cobalt-org / cobalt.rs

Static site generator written in Rust

cobalt-org.github.io/

Apache License 2.0

1.38k stars 102 forks source link

A layout using another layout as a base #942

Open elpiel opened 2 years ago

elpiel commented 2 years ago

Since I'm looking to replace jekyll with something that is built with Rust, I realised that it's not currently possible to have a layout that uses another layout.

I tried extracting the frontmatter for the layer and making a look when rendering the document, however, I was unable to make it work.

Is this something you'd like to have in cobalt? I can open a draft PR if it is so.

epage commented 2 years ago

Have you looked into using include to use snippets between these layouts?

My preference is to instead keep it simple, relying on composing using include but I'm up for hearing use cases to explain why layouts of layouts would be needed.

ghost commented 2 years ago

Have you looked into using include to use snippets between these layouts?

I'm not OP but I can attest one of the greatest features of Hugo are layout inheritance. Without it it's not possible to build a DRY website or practice functional programming via composition in the UI.

elpiel commented 2 years ago

Have you looked into using include to use snippets between these layouts?

My preference is to instead keep it simple, relying on composing using include but I'm up for hearing use cases to explain why layouts of layouts would be needed.

Yeah, this is what the default layout is doing, but the crates one extends it to add more stuff:

https://github.com/AeroRust/are-we-in-space-yet/blob/933b45db16c2585f68d2ce0c9a03640ad6604366/_layouts/crates.html

It's not mandatory to have this feature but it's good to have.

epage commented 2 years ago

Can you help me understand why nested layouts are such a great feature?

To me

They make it hard to see whats happening, having to follow up through several layers of layouts
They seem restrictive in their reuse (all or nothing nesting)
They make creation of god layouts that handle all cases the easy path because of the above restriction. Its easier to say "just one more thing" than to refactor.

This is compared to a layout built of snippets where you pick and choose the descriptive reuse elements you want.

The one value I see in layouts is maintaining the balanced start/end together rather than having separate includes for start/end, much like RAII in C++ and Rust or with in Python. I can see us adding support for something that is a mix of Tera filter blocks and macros

{% define body content %}
<body>
{{ content }}
</body>
{% enddefine%}

{% body %}
Hello world!
{%endbody %}