Skip to content

Conversation

@dejmedus
Copy link

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!" %}

Copy link
Contributor

@karreiro karreiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@karreiro karreiro requested a review from charlespwd October 21, 2025 16:51
@dejmedus dejmedus force-pushed the jb-inline-snippets branch 3 times, most recently from bdf3e2a to 266e1ed Compare October 22, 2025 22:47
Copy link
Contributor

@Maaarcocr Maaarcocr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Author

dejmedus commented Oct 24, 2025

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?

@dejmedus dejmedus marked this pull request as ready for review October 24, 2025 00:15
# {% snippet input %}
# value
# {% endsnippet %}

Copy link
Contributor

@karreiro karreiro Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could remove this line:

Suggested change

(I'm almost sure it doesn't impact YARD pipeline, but I think it would be nice to remove to be 100% sure and also be cohesive with the other tags) 😌

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call! Fixed

Base automatically changed from rigid-mode to main October 27, 2025 15:56
EvilGenius13 and others added 15 commits October 27, 2025 10:11
Inline snippets will reduce code duplication and
improve the developer experience, eliminating the
need for one-off snippet files
Previously, inline snippets syntax looked a bit
different, they:

- used strings as tag identifiers
- defined tag arguments {% snippet "input" |type| %}

This PR updates snippets to better reflect
the currently proposed syntax

Co-authored-by: Orlando Qiu <orlando.qiu@shopify.com>
Currently, snippet files identified by strings. This
PR makes changes to render to allow for new inline
snippets to use variables as identifiers instead
This commit updates the render method to share parts
of the snippet and block rendering logic to enable
inline snippets to support `with`, `for`, and `as`
syntax
Copy link
Contributor

@karreiro karreiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@dejmedus dejmedus requested a review from Maaarcocr October 27, 2025 18:52
# @liquid_description
# You can create inline snippets to make your Liquid code more modular.
# @liquid_syntax
# {% snippet input %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non blocking: we should name this snippet_name instead? So that we'd call {% render snippet_name %}?

Looks like the docs for assign are using variable_name. We can try to be consistent here.

@to = p.consume(:id)
else
raise SyntaxError, options[:locale].t("errors.syntax.snippet")
end
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're missing a p.consume(:end_of_text), otherwise folks could do stuff like {% snippet foo bar baz %} and we wouldn't be throwing an error

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! Fixed

Copy link
Contributor

@karreiro karreiro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, @dejmedus! Excellent stuff 🚀

@dejmedus dejmedus requested a review from charlespwd October 28, 2025 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants