Introduce Inline Snippets tag

[dejmedus]

This PR implements RFC#1916 and introduces support for the new inline snippets {% snippet %} tag, which allows us to define reusable template components directly within Liquid files

Traditionally, snippets are stored as separate .liquid files in a snippets/ directory and rendered using the {% render %} tag. The {% snippet %} tag allows us to define and render inline snippets in the same file

  {% snippet input %}
    {% doc %}
      @param {string} type 
      @param {string} value
    {% enddoc %}

    <input type="{{ type }}" value="{{ value }}" />
  {% endsnippet %}

  {% render input, type: "text", value: "Hi!" %}

[karreiro]

Thank you for this PR, @dejmedus! Excellent stuff! I've left some minor comments, but it's really cool to see inline snippets working :) 🚀

[Maaarcocr]

given that we are allowing variables to be passed to render like we do for blocks in shopify themes, I think it would be wise to have a shared interface here that we can use in both places.

what does this mean practically? instead of checking for SnippetDrop, if the ruby object that is passed responds to a certain method (let's say render or maybe a less common name that may not be mistakenly implemented by other drops) then it will get called.

This way we can remove our monkey patching of render in storefronts, as having callable objects is now a real liquid feature and it has a shared interface we can use.

[dejmedus]

instead of checking for SnippetDrop, if the ruby object that is passed responds to a certain method

Thank you for the detailed explanation @Maaarcocr! I added a to_partial method to SnippetDrop so render can differentiate by respond_to?(:to_partial). Does this sound like what we are aiming for?

[karreiro]

Thank you for this PR, @dejmedus! I just left one minor question left, but overall, everything looks good to me :)

[karreiro]

Thank you, @dejmedus! Excellent stuff 🚀

[Maaarcocr]

looks solid. one suggestion, if we do not have a test for this, can you please add a test for something like:

{% snippet foo %}
{% render "THIS_DOES_NOT_EXIST" %}
{% endsnippet %}

{% render foo %}

to see what file and line number the render for rendering a non existing snippet has?
(the render inside the snippet is just a simple way to generate a liquid error)

in theory I would expect this to render something like:

Liquid error (<filename> line 2): the snippet cannot be found or something like this

but what I care about is <filename>. if that code is contained in a file called bar.liquid <filename> should be bar

[karreiro]

Thank you for the changes, @dejmedus! Excellent catches, @Maaarcocr!

[bakura10]

Awesome feature! Do we know when this will be added to Shopify? :)

[ianks]

nit: we should first check is_a?(String) since its the common/hot path

[ianks]

would be good to respond to name as well for duck typing

[ianks]

I'm not sure if this makes sense. Assigning a snippet drop shouldn't rely on parsed AST for this functionality.