mozilla / nunjucks

A powerful templating engine with inheritance, asynchronous control, and more (jinja2 inspired)
https://mozilla.github.io/nunjucks/
BSD 2-Clause "Simplified" License
8.57k stars 640 forks source link

template-fragments #1441

Open johntom opened 1 year ago

johntom commented 1 year ago

Hi, I've been using htmx and they have a section in docs called https://htmx.org/essays/template-fragments/. I then found out that fragments are supported in Apostroph 3 (https://v3.docs.apostrophecms.org/guide/fragments.html#using-fragments) which uses numjucks as its template engine and I'm curious if ... 1) Are they using fragments in the same way as jinja2? 2) Do you plan to support template-fragments in a future release? Very happy user using fastify/nunjucks and htmx. TIA John

NextThread commented 1 year ago

hey, can I work on this issue

webketje commented 1 year ago

I think this should not be in core. It is a requirement specific to the usage of a third-party software implementing server-driven partial hydration of front-end views, a concern that is not in scope of the Nunjucks templating library. For all other flows and purposes, asynchronous data should be loaded prior to a synchronous Nunjucks render call, or should use an asynchronous custom loader together with an async Nunjucks render call

benkenawell commented 4 months ago

Hi,

I realize this issue is ~1 year old, but I would like to make an argument for it being in core.

If you read the Template Fragments Essay, this feature is about being able to render part of a template out of the greater whole. It is a method of breaking down templates within a single file, a method of template decomposition. It feels complementary to, and maybe inverse of, template inheritance which builds up a single template from decomposed files.

There is no requirement in HTMX, or any server-driven partial hydration methodologies, for this type of template fragmenting. The essay only points out that being able to stay in context, within the file, when writing template files is more convenient. It makes it easier to follow what a page might look like when different templating paths are taken. Whether I return an entirely new page or just a partial page, it still helps to be able to follow what the templated code will look like.

Today, most websites take advantage of partially updating the webpage, they don't often do a full-page refresh. Currently, most partial page updates are still done in JS via React or other client side library, and wouldn't utilize a templating library like Nunjucks at all. Increasingly, libraries like HTMX, Hotwire, and Data Star are becoming more popular. They all allow for easy partial page renders when the server return HTML, making templating libraries very attractive in conjunction with Express/Fastify. Currently, every time I want to make a partial page update, I need to break that part of the page out into its own file instead of just being able to render part of the template. Very quickly when testing a page, I ended up with a layout template, page template, and 3 partials for barebones partial page updates; there are many more things I would still like to break out of my page template! Template fragmenting is a very attractive solution to this problem.

Personally, I like how JStachio handles rendering these fragments though a URI Fragment Notation. It gives all of the flexibility without any additional API surface area. It seems something should be possible using a Custom Extension/Tag or extending the Environment, but nothing compares to the API of that URI Fragment Notation.

If someone would be willing to offer some guidance, I would be happy to try my hand at one of the above. Even if it ends up in a separate package, not core, it would be a great benefit for me.

dougmoscrop commented 4 months ago

Ampt took a stab at this, but I think if this were in core it would be even more powerful: https://github.com/getampt/fraglates

benkenawell commented 4 months ago

Wow, thanks for the link, that looks like what I was looking for, plus some extra. I will have to take it for a test drive soon!

I may still attempt a thinner wrapper, instead of a full replacement. I want to see how far I can go with an extension or a tiny bit of monkey patching.