Answers.Body: <p>As Steve mentioned, there are a few different approaches, but for me I'd reach for <code>embed</code> in this situation. <a href="https://twig.symfony.com/doc/3.x/tags/embed.html" rel="nofollow noreferrer">https://twig.symfony.com/doc/3.x/tags/embed.html</a></p>
  <p>By combining with the <code>parent()</code> function, you can effectively prepend or append your per-instance data-prepping chunks of code to the output like this:</p>
  <pre class="lang-twig prettyprint-override"><code>{# calling template: #}
  
  {% embed '_includes/whatever' %}
      {% block content %}
          {# prepare some data for this instance here #}
          {% set something = 'aaa' %}
  
          {# include the shared portion of the `content` block via parent() #}
          {{ parent() }}
      {% endblock %}
  {% endembed %}
  </code></pre>
  <pre class="lang-twig prettyprint-override"><code>{# _includes/whatever: #}
  
  {% block content %}
      &lt;h2&gt;Hi there&lt;/h2&gt;
      {{ something ?? null }}
  {% endblock %}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-14T17:04:26.890Z
Answers.Text: Hey look! An option I didn't know existed! Thanks James.
Answers.UserDisplayName: stevecomrie
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-14T19:26:22.383Z
Answers.Text: Embed is absolutely invaluable, especially with Tailwind or any build that requires a high degree of componentisation.
Answers.UserDisplayName: James Smith
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-14T08:09:05.267Z
Answers.LastActivityDate: 2022-09-14T08:09:05.267Z
Answers.UserDisplayName: James Smith
Answers.Body: <p>You can't pass a variable from an included template back to the template that called it.</p>
  <p>But you still have at least three options (that I can think of) to achieve the kind of reusability that you're looking for.</p>
  <p><strong>Option 1</strong></p>
  <p>Re-organize your code so that 'prepare-whatever' takes place in your main template, and you then include the contents of your other file which can decide whether or not it even needs to render anything.</p>
  <p><em>index.twig</em></p>
  <pre><code>{% set whatever = entry.whatever.one() ?? null %}
  {% include '_includes/whatever' with {
      'whatever': whatever
  } %}
  </code></pre>
  <p><em>_includes/whatever.twig</em></p>
  <pre><code>{% if whatever %}
      Whatever: {{whatever}}
  {% endif %}
  </code></pre>
  <p><strong>Option 2</strong></p>
  <p>Use the <a href="https://twig.symfony.com/doc/2.x/tags/extends.html" rel="nofollow noreferrer">extends</a> functionality to keep important pieces of common code inside a base template, that your index.twig extends from.</p>
  <p><em>index.twig</em></p>
  <pre><code>{% extends '_includes/prepare-things' %}
  
  {% block content %}
      {% include '_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endblock %} 
  </code></pre>
  <p><em>_includes/whatever.twig</em></p>
  <pre><code>{% if whatever %}
      Whatever: {{whatever}}
  {% endif %}
  </code></pre>
  <p><em>_includes/prepare-things</em></p>
  <pre><code>{% set whatever  = entry.whatever.one()  ?? null %}
  {% set something = entry.something.one() ?? null %}
  
  {% block content %}{% endblock %}
  </code></pre>
  <p><strong>Option 3</strong></p>
  <p>Similar to option 2, except instead of extending a template from you main twig file, you can extend a template from within an included template.</p>
  <p><em>index.twig</em></p>
  <pre><code>{% include '_includes/whatever' %}
  </code></pre>
  <p><em>_includes/whatever.twig</em></p>
  <pre><code>{% extends 'includes/prepare-whatever' %}
  
  {% block whateverContent %}
      {% if whatever %}
          Whatever: {{whatever}}
      {% endif %}
  {% endblock %}
  
  </code></pre>
  <p><em>_includes/prepare-whatever.twig</em></p>
  <pre><code>{% set whatever = entry.whatever.one() ?? null %}
  
  {% block whateverContent %}{% endblock %}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-14T14:12:16.647Z
Answers.Text: Thanks for this excellent list of alternatives. It's very useful. In my case James answer is the approach I will take, so I'm accepting his answer. But this one should be co-accepted!
Answers.UserDisplayName: Álvaro Franz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-09-14T00:49:12.713Z
Answers.LastActivityDate: 2022-09-14T00:49:12.713Z
Answers.UserDisplayName: stevecomrie
Body: <p>I usually load and prepare data before calling a certain include. That data may be loaded in a certain way for different cases, so I cannot add that data preparation code into the include itself. I have to do it before calling it. Like:</p>
  <pre><code>{# Example #}
  {% set whatever = entry.whatever.one() %}
  {% if whatever %}
      {% include '/_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endif %}
  </code></pre>
  <p>Of course there will be more complex situations, this is just an example.</p>
  <p>If I move the <code>{% set whatever = entry.whatever.one() %}</code> line into its own include and then do:</p>
  <pre><code>{# Example #}
  {% include '/_includes/prepare-whatever' %}
  {% if whatever %}
      {% include '/_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endif %}
  </code></pre>
  <p>The scope stays inside the include, so <code>whatever</code> is not defined when I need it.</p>
  <p>How can I achieve the same functionality, to stay <a href="https://en.wikipedia.org/wiki/Don%27t_repeat_yourself" rel="nofollow noreferrer">DRY</a>?</p>
  <p>Thanks!</p>
  
Tags: <templating>
Title: How to reuse "functional code" in multiple twig files
ThreadText: # How to reuse "functional code" in multiple twig files
  
  (Asked by: username_0 on 2022-09-13)
  
  I usually load and prepare data before calling a certain include. That data may be loaded in a certain way for different cases, so I cannot add that data preparation code into the include itself. I have to do it before calling it. Like:
  
  ```
  {# Example #}
  {% set whatever = entry.whatever.one() %}
  {% if whatever %}
      {% include '/_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endif %}
  
  ```
  
  Of course there will be more complex situations, this is just an example.
  
  If I move the `{% set whatever = entry.whatever.one() %}` line into its own include and then do:
  
  ```
  {# Example #}
  {% include '/_includes/prepare-whatever' %}
  {% if whatever %}
      {% include '/_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endif %}
  
  ```
  
  The scope stays inside the include, so `whatever` is not defined when I need it.
  
  How can I achieve the same functionality, to stay [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)?
  
  Thanks!
  
  **Tags:** templating
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2022-09-14. Score: 3 | Accepted answer
  
  As Steve mentioned, there are a few different approaches, but for me I'd reach for `embed` in this situation. <https://twig.symfony.com/doc/3.x/tags/embed.html>
  
  By combining with the `parent()` function, you can effectively prepend or append your per-instance data-prepping chunks of code to the output like this:
  
  ```twig
  {# calling template: #}
  
  {% embed '_includes/whatever' %}
      {% block content %}
          {# prepare some data for this instance here #}
          {% set something = 'aaa' %}
  
          {# include the shared portion of the `content` block via parent() #}
          {{ parent() }}
      {% endblock %}
  {% endembed %}
  
  ```
  
  ```twig
  {# _includes/whatever: #}
  
  {% block content %}
      <h2>Hi there</h2>
      {{ something ?? null }}
  {% endblock %}
  
  ```
  
  > **Comments:**
  > **username_2**: Hey look! An option I didn't know existed! Thanks username_1.  
  > **username_1**: Embed is absolutely invaluable, especially with Tailwind or any build that requires a high degree of componentisation.  
  
  ---
  
  ### Answer by username_2 on 2022-09-14. Score: 2
  
  You can't pass a variable from an included template back to the template that called it.
  
  But you still have at least three options (that I can think of) to achieve the kind of reusability that you're looking for.
  
  **Option 1**
  
  Re-organize your code so that 'prepare-whatever' takes place in your main template, and you then include the contents of your other file which can decide whether or not it even needs to render anything.
  
  *index.twig*
  
  ```
  {% set whatever = entry.whatever.one() ?? null %}
  {% include '_includes/whatever' with {
      'whatever': whatever
  } %}
  
  ```
  
  *\_includes/whatever.twig*
  
  ```
  {% if whatever %}
      Whatever: {{whatever}}
  {% endif %}
  
  ```
  
  **Option 2**
  
  Use the [extends](https://twig.symfony.com/doc/2.x/tags/extends.html) functionality to keep important pieces of common code inside a base template, that your index.twig extends from.
  
  *index.twig*
  
  ```
  {% extends '_includes/prepare-things' %}
  
  {% block content %}
      {% include '_includes/whatever' with {
          'whatever': whatever
      } %}
  {% endblock %} 
  
  ```
  
  *\_includes/whatever.twig*
  
  ```
  {% if whatever %}
      Whatever: {{whatever}}
  {% endif %}
  
  ```
  
  *\_includes/prepare-things*
  
  ```
  {% set whatever  = entry.whatever.one()  ?? null %}
  {% set something = entry.something.one() ?? null %}
  
  {% block content %}{% endblock %}
  
  ```
  
  **Option 3**
  
  Similar to option 2, except instead of extending a template from you main twig file, you can extend a template from within an included template.
  
  *index.twig*
  
  ```
  {% include '_includes/whatever' %}
  
  ```
  
  *\_includes/whatever.twig*
  
  ```
  {% extends 'includes/prepare-whatever' %}
  
  {% block whateverContent %}
      {% if whatever %}
          Whatever: {{whatever}}
      {% endif %}
  {% endblock %}
  
  ```
  
  *\_includes/prepare-whatever.twig*
  
  ```
  {% set whatever = entry.whatever.one() ?? null %}
  
  {% block whateverContent %}{% endblock %}
  
  ```
  
  > **Comments:**
  > **username_0**: Thanks for this excellent list of alternatives. It's very useful. In my case username_1 answer is the approach I will take, so I'm accepting his answer. But this one should be co-accepted!  
  
  ---
  
  