CASE: check if database variables exist first

Templates Cases
1

When we create templates, we often need certain values from database variables (inputs) from other templates to refer to, and we might skip linking to it by using result tags to avoid complexity in the coding (circular references) and make sure the template can render without having to wait on the rendering of that other template (where the result is created).
So it’s a case where we want to directly link to the database variable.

Let’s say in our example, we have a reconciliation (handle = wp_settings) in which we create a check to see if a company is VAT compliant or not:

{% t "t_vat_compliant?" %} {% input custom.check.vat_compliant as:boolean default:false %}

In another template, we want access to that value of that database variable custom.check.vat_compliant, so you might think creating it like this:

{% comment %}VAT compliant check{% endcomment %}
{% assign wp_settings = period.reconciliations.wp_settings %}
{% assign vat_compliant = wp_settings.custom.check.vat_compliant | default:false %}

Right? Well, above code won’t work if the template you refer to (wp_settings) does not exist in the company, as you’ll get the following Liquid-error:

Liquid error (line 3): Called .custom on an undefined value: assign vat_compliant = wp_settings.custom.check.vat_compliant default:false

You might think that the assign would skip the non-existing database variable, and use the default instead, but Liquid cannot skip that as it has no way on telling if it doesn’t exist or not, as it cannot access that specific reconciliation.

Therefor, it’s advised to always check first if a certain template exists or not (more on that here too):

{% comment %}VAT compliant check{% endcomment %}
{% assign wp_settings = period.reconciliations.wp_settings %}
{% if wp_settings.exists? %}
  {% assign vat_compliant = wp_settings.custom.check.vat_compliant | default:false %}
{% else %}
  {% assign vat_compliant = false %}
{% endif %}

Even if you create a certain workflow where that other template might be activated with auto-add (so every workflow will have that template), it’s a good coding guideline to follow as you never know when that auto-add setting might be activated or not.

See coding guideline on our developer site as well :point_left: