How to transition from deprecated {% include %} tag to new {% render %} tag?

[Matt_Cottis]

Hello Everyone,

I've come across a changelog that notes the {% include %} tag is being deprecated in favour of the new {% render %} tag. I'm aware that previous include tags are keeping their functionality, but the new render tag must be included going forward.

The way in which we render our content on pages that aren't the homepage is using a single section that contains the fields for every content block we have. Then we loop through these block and include the required snippet like so:

{% for section in section.blocks %}
    {%- assign snippet_name = 'section-' | append: section.type -%}
    {% include snippet_name %}
{% endfor %}

However, it seems to not allow me to use a variable in place of the string or allow the snippet access to the data in the parent section which will completely break the site using our current strategy.

Does anyone have any recommendations on how to solve this issue without recoding the whole site?

I was also wondering if there are any new updates coming that will make this change make sense?

Any help would be greatly appreciated, thanks everyone!

[Coding_with_Jan]

Hey Matt,

good question there.

I like the structured way you include your snippets.

Depending on the number of blog types you might want to break this down into the individual types using if/elsif in the future.

{% if block.type == 'type-a' %}
{% render 'snippet-type-a' %}
{% elsif block.type == 'type-b' %}
{% render 'snippet-type-b' %}
{%endif%}

I also couldn´t get dynamic rendering to work yet 😕

With the new render method, variable Scope will change a little bit towards encapsulation. This might help to keep code cleaner and increase performance as Shopify states here:

https://help.shopify.com/en/themes/liquid/tags/theme-tags#render

Hope that helps at least a little bit 😄

[Matt_Cottis]

Hey Jan,

Thank you for taking the time to reply!

The method you suggested was my back-up method, in which I had a snippet called render, then I would pass down the snippet name as a variable. However, I totally forgot about the variable needing to be passed down explicitly.

As I was typing this I had a thought, could I pass the section object down as a variable named section? This way the snippets wouldn't need to be changed in any way?

[Coding_with_Jan]

Hi Matt,

so I just tried to render a snippet and within the snippet you have access to the section object per default.
If you want to access the current block from your for-loop however, you will need to pass this block explicitly inside the render tag.

(Shopify further says:

When a snippet is rendered using the render tag, the deprecated include tag may not be used inside of the snippet.)

I still don´t quite get how you would render your blocks dynamically without any if/elseif statements, when you have access to the section object inside a snippet? 😃

[Matt_Cottis]

Hi Jan, 

Sorry, I wasn't very clear! Here's a visual example of what I was thinking:

{% for section in section.blocks %}
    {%- assign section_name = 'section-' | append: section.type -%}
    {% render 'render_snippet', snippet: section_name, section: section %}
{% endfor %}

// Render snippet file
{% if snippet %}
    {% case snippet %}
        {% when 'snippet-a' %}
            {% render 'snippet-a', section: section %}
        {% when 'snippet-b' %}
            {% render 'snippet-b', section: section %}
    {% endcase %}
{% endif %}

Unfortunately, I know this still isn't dynamic but it's the best I can think of at the moment.

[Coding_with_Jan]

Hi Matt,

thanks for elaborating.

I think I got confused because you renamed the section.blocks into "sections" when they are actually "blocks" 😁

But yes, you are absolutely right -> your snippets should work fine.  🙂

[Matt_Cottis]

Hi Jan, 

Haha I didn't notice I did that, sorry for the confusion!

Thanks for your help!

[Allan-EP]

Running to the same issue as described in the original post. Here's the code:

{% assign snippetSlug = parentCollection.title | handleize | remove: 'the-' %}
{% capture fileName %}materials-{{ snippetSlug }}{% endcapture %}
{% capture materialsGuide %}{% include fileName %}{% endcapture %}
{% capture fileName %}size-fit-{{ snippetSlug }}{% endcapture %}
{% capture sizeFitGuide %}{% include fileName %}{% endcapture %}

We're taking the products "parent" collection (something we've defined in metafields, maps to a collection based on product type), converting it to a handle, then trying to include a snippet matching the pattern of {namespace}-{collection-handle}.  We're capturing the output of that include to later check for "Liquid error" inside the variable to determine whether the file was found or not. This works fine with {% include %} as the tag. 

However, if you convert to {% render %}, we get the Liquid syntax error (line 25): Syntax error in tag 'render' - Template name must be a quoted string error. We could get around this by matching against the collection slug in a gigantic switch statement, but that's not scalable and shouldn't be necessary since {% include %} could handle a variable file name parameter. In a perfect world we'd either get that support brought back, or a string filter added like :

{% render 'size-fit-' | append: snippetSlug %}

For now, {% include  %} will have to stay in place. 😞 

[Bryan30]

Encapsulation sure... but not being able to use a variable snippet name increases the file size. 

Would anyone like to take a step back?  Liquid was getting too dynamic.

[TheLankyCoder]

Found this workaround. By appending a string (even empty) it transforms the variable into a string.

{%- render variable_name | append: ".liquid" -%}
or
{%- render variable_name | append: "" -%}

Found on this thread.
https://community.shopify.com/c/shopify-design/how-can-i-render-a-snippet-this-name-is-defined-by-a-...