Caching rendered blocks content to reuse them in further calls

[ilyapuchka]

Resolves #158
This PR implements caching of rendered blocks context in the top context so that it can be later rendered again using variable expression.

Example:

<title>{% block title %}Hello World!{% endblock %}</title>
<h1>{{ block.title }}</h1>

Result:

<title>Hello World!</title>
<h1>Hello World!</h1>

In case of inheritance cached content is updated each time child block is rendered, so when block repeats in the base template its content will be the same as content of the first block invocation, containing all its children contents.

Example:

base.html

<title>{% block title %}Hello World!{% endblock %}</title>
<h1>{{ block.title }}</h1>

child.html

{% extends base.html %}
<title>{% block title %}{{ block.super}} Foo Bar {% endblock %}</title>

Result (when rendering child.html):

<title>Hello World! Foo Bar</title>
<h1>Hello World! Foo Bar</h1>

[djbe]

Should we still consider this, as we're planning on merging filters such as set from StencilSwiftKit?

[ilyapuchka]

@djbe I think it's a bit different than set, though they may be used to achieve similar results

[ilyapuchka]

@kylef @djbe @yonaskolb can we move on with that?
@djbe speaking of differences with set, blocks are rendered when they are defined and they are designed primarily for inheritance.

[djbe]

Side Note: set is also rendered when it's defined.

I've just read through the related issue #158, where you mention what Jinja does. Seeing as Stencil tries to mirror Jinja where possible, shouldn't we do the same? I.e. have the block title be cached under self.title?

[ilyapuchka]

@djbe we can do self.title but I think block.title is more helpful to recognize what this variable stands for

[djbe]

I agree that block.title may be clearer, but we're basing ourselves of Jinja, so I think we should mirror that if possible.

@kylef thoughts? You have better knowledge about this.

[ilyapuchka]

@djbe I don't think we should prefer mirroring Jinja syntax to better API, where block.name is better and we seem to agree on that. We already have quite a few points of divergence with Jinja and it's just not a goal to be canonical Swift implementation of Jinja language 🤷‍♂️

[ilyapuchka]

Is this something we want to have or it can be closed?

[SwiftGen-Eve]

Hey 👋 I'm Eve, the friendly bot watching over Stencil 🤖

Thanks a lot for your contribution!

---

Seems like everything is in order 👍 You did a good job here! 🤝

Generated by 🚫 Danger

[djbe]

Looks good. I've made the cacheBlock function public in case anyone with custom blocks wants to do the same.