Including reusable logic blocks? Render vs. include tag announcement.

3 0 3

With this most recent announcement, is there a way to include blocks of Liquid logic and make variable available outside of the snippet, without using the (now depreciated) include tag?


For example, I will often abstract variable-setting logic into a snippet that I reuse multiple times in various sections. I expect the variables to be available outside of that snippet. My most recent use case tested for if a section contained "links" - any combination of a 4 fields: 2 text fields, and 2 URL fields. If certain parameters were met, a "has_links" variable was set to true, which was then used conditionally throughout the section, outside of the context of the snippet.


With this news, it seems my options are
1) write un-DRY code and explicitly include the (rather verbose) logic every time I need it

2) use the depreciated include tag (while it still works...seems that it is still somewhat supported, but still depreciated)


The include tag was very useful for this kind of operation. My impression is that the render tag is intended to actually be responsible for rendering what it contains, but this is not exclusively how snippets have been used in the past. Is there an official workaround, aside from above?

6 0 2

BUMP: We would also really like to know a solution to this.


As an Example, we are calling this code:

{% assign isDarkTheme = false %}
{% if contains "" or settings.dark_theme %}
    {% assign isDarkTheme = true %}
{% endif %}

using an include at the top of multiple sections like this:

{% include 'dark_theme_switcher' %}
3 0 3

For what it's worth, at the moment, I've simply been using "{% include %}" less, and only for the situation outlined above...given that it's deprecated, but still supported for the moment, my best "solution" is to use "render" when it makes sense, and "include" when I must.

Hoping alongside you that there's a more thoughtful solution than that though, as it is fundamentally flawed by nature.

21 2 7

I settled on this pattern, which I wasn't so happy about:

Which works, but now I want to have a single env.liquid snippet that I can get a few values from in my layouts, and I'm back to the drawing board. Because my solution using render tags with captures works for a snippet that outputs a single value (and that value will automatically be a string).

I think include shouldn't be deprecated, at this point. The render tag should be used where it makes sense, as was noted in @_daniel_nordby's reply. I just worry about continuing to using includes.

4 1 1

Would also be very interested to hear about possible solutions to this problem. In the current situation it is difficult to imagine how we are going to be able to stop using "include".

New Member
1 0 0

We use {% include %} for DRY logic programming similar to what many in this thread have described.  

Although the {% capture %} {% render %} method might work for strings, liquid variables are more than just strings, and converting and reconverting would add unnecessary computation - if it's even an option for some variable types.

With {% include %} being deprecated, I would be very interested in the offical way to achieve this type of DRY programming.

Until then, I'll have to keep using {% include %} where it's needed and hope Shopify maintain their backwards compatibility ethos - without {% include %} all my complex themes will break .