oliverdavies.uk/content/node.25833838-38b9-414d-bca6-de0bf5c2ac28.yml

uuid:
  - value: 25833838-38b9-414d-bca6-de0bf5c2ac28
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-05-11T09:00:22+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: "Don't put business logic in templates"
created:
  - value: '2024-01-10T00:00:00+00:00'
changed:
  - value: '2025-05-11T09:00:22+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2024/01/10/dont-put-business-logic-in-templates
    langcode: en
body:
  - value: |
      <p>Here is some code from my website:</p>

      <p><img src="https://www.oliverdavies.uk/assets/images/talk-count-code.png" alt="A screenshot of the code that calculates the number of talks I've given." /></p>

      <p>If you want, you can also <a href="https://raw.githubusercontent.com/opdavies/oliverdavies.uk/main/source/_pages/presentations.md">view it on GitHub</a>.</p>

      <p>It is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.</p>

      <p>It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.</p>

      <p>It's only used in a single place, so the same logic isn't duplicated elsewhere.</p>

      <p>But it's in the page's Twig template.</p>

      <p>It has no test coverage.</p>

      <p>If I need to change or refactor it, I'd need to test it again manually.</p>

      <p>Don't do this.</p>

      <h2 id="so%2C-what-should-i-do%3F">So, what should I do?</h2>

      <p>It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.</p>

      <p>Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.</p>

      <p>This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.</p>

      <p>In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.</p>

      <p>Once the logic is separated, you only need to test it once.</p>

      <h2 id="here%27s-the-thing">Here's the thing</h2>

      <p>In a previous version of my website, I did this by creating a custom Twig function.</p>

      <p>It was as simple as adding <code></code> to the template.</p>

      <p>All the logic was moved from the template to my custom extension.</p>

      <p>The logic was separated.</p>

      <p>It had tests.</p>

      <p>This is the approach I'd take to achieve the same result for a client application.</p>

      <p>For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.</p>

      <p>For myself, and for calculating something simple, this is fine.</p>

              
    format: full_html
    processed: |
      <p>Here is some code from my website:</p>

      <p><img src="https://www.oliverdavies.uk/assets/images/talk-count-code.png" alt="A screenshot of the code that calculates the number of talks I've given."></p>

      <p>If you want, you can also <a href="https://raw.githubusercontent.com/opdavies/oliverdavies.uk/main/source/_pages/presentations.md">view it on GitHub</a>.</p>

      <p>It is business logic responsible for counting the number of talks I've given at different events so I can display it on my Talks page.</p>

      <p>It starts at zero, loops over each talk, and increments the talk count if the event is the current day or a past date.</p>

      <p>It's only used in a single place, so the same logic isn't duplicated elsewhere.</p>

      <p>But it's in the page's Twig template.</p>

      <p>It has no test coverage.</p>

      <p>If I need to change or refactor it, I'd need to test it again manually.</p>

      <p>Don't do this.</p>

      <h2 id="so%2C-what-should-i-do%3F">So, what should I do?</h2>

      <p>It's OK to put simple presentational logic, such as looping over a list or whether to show or hide a value within a template, but not complex business logic.</p>

      <p>Business logic should be separated and executed elsewhere. The values should be passed to the template to be rendered.</p>

      <p>This makes the business logic easier to test as you can test the logic itself and determine the value passed to the template is correct without being concerned about the templating engine.</p>

      <p>In an application, you may need to output a value to a template and a terminal. You'd have one source of truth, such as a Service, Action or Command class that calculates the value before passing it to the appropriate output.</p>

      <p>Once the logic is separated, you only need to test it once.</p>

      <h2 id="here%27s-the-thing">Here's the thing</h2>

      <p>In a previous version of my website, I did this by creating a custom Twig function.</p>

      <p>It was as simple as adding <code></code> to the template.</p>

      <p>All the logic was moved from the template to my custom extension.</p>

      <p>The logic was separated.</p>

      <p>It had tests.</p>

      <p>This is the approach I'd take to achieve the same result for a client application.</p>

      <p>For a client, I want to run a test suite and be confident my logic works as expected - now and in the future.</p>

      <p>For myself, and for calculating something simple, this is fine.</p>

              
    summary: null
field_daily_email_cta: {  }