Overriding a block within an include

[roll]

base.html

{% include 'partial.html' %}

partial.html

{% block contents %}
partial.html
{% endblock %}

extension.html

{% extends 'base.html' %}
{% block contents %}
extension.html
{% endblock %}

---

Nunjucks 1.3.4 actual:

partial.html

Expected (?):

extension.html

[devoidfury]

I'm not sure that using blocks in includes is a good idea -- how should the block resolution be handled?

For example, what should happen here?

partial.html

{% block main %} included {% endblock %}

base.html

{% include 'partial.html' %}
<main>
{% block main %} base {% endblock %}
</main>

example.html

{% extends 'base.html' %}
{% block main %} example {% endblock %}

[roll]

I suppose the same as here:

{% block main %} included {% endblock %}
<main>
{% block main %} base {% endblock %}
</main>

It's more a question than a bug report but I thought about includes like macroses to build a template on the first step. May be it works the other way internally.

[devoidfury]

I think you're on to something, and that it's something that should be discussed further.

There are some complexities to it, however -- how to handle blocks defined in includes in top level templates, blocks in includes inside top level template blocks[1], blocks in includes in child templates, error messages when there's a block name conflict in included templates where the block should be top level in both places.

[1]
base

{% block main %}{% include 'partial' %}{% endblock %}

partial

{% block extra %}extra partial {% endblock %}

child

{% extends 'base' %}

{% block main %}
// some code
{{ super() }}
{% endblock %}

{% block extra %}extra extended{% endblock %}

[jlongster]

include does not create an inheritance so there are lot of complexities with how the inheritance chain for blocks should work. This is simply something I'm not interesting in, honestly, I don't think the return would be enough for the high amount of complexity it would introduce to the code.

Please re-open if you really want to see this. I can label is as an enhancement request if there is further discussion. Closing for now.

[carljm]

Not only would this be complex, but it would also break existing uses. Right now an included template has its own totally separate inheritance hierarchy, so it can extend its own base and override blocks from there. So making included templates participate in the inheritance hierarchy of the parent template instead would be a major change that would break existing templates.

[sbussard]

[How] Does this relate to #539 ?

[carljm]

It doesn't relate to #539, IMO.

[est]

is this a bug in JInja2?

Because this seems related

https://stackoverflow.com/questions/21729864/jinja2-how-to-use-named-blocks-inside-included-templates-inside-extendable-tem

[candu]

This reminds me of React's children or Vue's slot mechanism, which in turn would suggest a syntax like:

{% include 'component' %}
  {% block main %}
    <!-- block content here -->
  {% endblock %}
{% endinclude %}

which avoids the name collision issue by scoping blocks within the context of the included template. (I don't know how parser internals work here, though, so no idea how feasible this would be - and at some point, you might just be better off using SSR support in React / Vue to perform static site generation, heh.)

[stepanjakl]

+1 for scoping blocks within included template, like @candu suggests