Removal of theme snippets

[ConduciveMammal]

According to the Unite talks, when the new OSDE launches with Sections Everywhere, the new themes will no longer be able to use snippets, which I get. But my main problem is snippets hold so much more than just reusable content, I use snippets for logical code too for things like responsive images and customer tag checking.

Naturally, it wouldn't make any sense whatsoever to use an entire section for simply checking customer tags, so how will this be utilised? I'd really rather not have to copy/paste this code all over my themes and then somehow maintain each of them when a change is made, so in real-life scenarios, what will be the expected functionality here?

[ThomasBorowski]

I think they mentioned in the Q&A (https://youtu.be/HlpOGQrRBPY?t=1318) that they're looking into replacing snippets with something equivalent for the development workflow, so something that would be part of the theme build toolchain.

Here's the timestamp where they go into snippets specifically: https://www.youtube.com/watch?v=HlpOGQrRBPY&feature=youtu.be&t=1580

[nchan0154]

A tool that only compiles snippets at build time is not really an acceptable solution, unfortunately. A ton of people work on customizing existing/paid themes, and theme developers almost never provide the full source.

[ThibautC · Accepted solution]

Following Unite we gathered feedback and re-assessed our plans. Frame, page and content sections will be able to use snippets after all, but will do so via a new Liquid tag, different than {% include %}, which will add some constraints on how snippets are used. The constraints are intended to make our online store platform faster, more reliable, and easier to work with. The new Liquid tag will be released shortly.

[ThibautC]

The replacement for the {% include %} Liquid tag has been released: {% render %}.

[ThomasB_]

What if we need to calculate or evaluate multiple values as we need to use the resulting values to modify parts of our theme's liquid? How are we supposed to achieve this with render? We're doing that a lot with include right now.

[ThibautC]

You can use the {% capture %} tag to capture the output of the {% render %} and use it in the parent template. In cases where you have multiple resulting values, we recommend either splitting your snippet into multiple snippets, or inlining the code.

We understand this is a compromise and that {% render %} has some limitations compared to {% include %}, but we think the benefits around performance and code simplicity are worth it.

[ThomasB_]

Thanks for the information, @ThibautC. Yes, using capture was also our initial thought, alongside that it wouldn't work for multiple variables as you mentioned.

Is there an internal plan or timeframe when the deprecated include will be taken out completely? Do we need to update all out customer themes at some point?

[ThibautC]

While {% include %} is deprecated, it will not be removed from the platform, as we don't break backward compatibility in the Liquid/Theme API. However, as part of the new Online Store design experience we are introducing three new types of section files where the {% include %} tag will not be supported.

[ThomasB_]

I see, thanks for the clarification.

[WillMcFarland]

As far as I can tell from poking around, `{% include %}` is not supported within a `{% render %}`ed snippet, so if a Legacy Section Theme updates to using `{% render %}` for snippets prior to the full release of the new storefront, that will mean any apps that are relying on `{% include %}` within these snippets won't work - is that correct?

[ThibautC]

Correct. Not ideal right now, but we think it'll be better in the long run.

[JohnAtBonify]

@ThibautCyou said...

While {% include %} is deprecated, it will not be removed from the platform, as we don't break backward compatibility in the Liquid/Theme API.

I came across this screenshot "in the wild" this morning. Am I misunderstanding or did this roll out as a breaking change for some stores? As an app developer with thousands of customers relying on "include", I'm extremely concerned about this. Is my concern unfounded? I don't yet have support requests about this but I don't know if I should be expecting them to start rolling in at any moment.

[ConduciveMammal]

For this to have happened, the developer will have had to have used a {% include %} tag from within a {% render %} tag.

In terms of backwards compatibility, this shouldn't occur unless the above is done.

[ThibautC]

While the behavior of {% include %} remains unchanged, when a theme adopts {% render %}, it changes the behavior of snippets in a manner that can be breaking certain apps. We've communicated this in our changelog, and will hold off on using {% render %} in Debut and all theme store themes until Feb 17, 2020.

[tim]

You can use the {% capture %} tag to capture the output of the {% render %} and use it in the parent template. In cases where you have multiple resulting values, we recommend either splitting your snippet into multiple snippets, or inlining the code.

Would you consider adding this directly to  the  {% render %} tag as a shortcut, like:

{% render 'snippet' to result with value as internal_variable %}

will call snippet snippet and capture its output to the variable result?

I guess this could be useful  (and then supercool if snippet to output JSON and tag will parse it to make result an object :).

Because I can imagine people doing something like 

{% capture result %}
  {% render 'snippet' %}
{% end capture %}

{% assign result =  result | split: ";" %}

{% if result[0] == "something" %}
 {{ result.[1] }}
{% else %}
 {{ result.[2] }}
{% endif %} 

[ThibautC]

@tim I like the to result idea. We'll consider it.

We considered JSON parsing but decided against it. You can read some historical context about it here.

Thanks for the feedback!

[dungtran]

Thank ThibautC

i had the same problem