Shopify / liquid

Liquid markup language. Safe, customer facing template language for flexible web apps.
https://shopify.github.io/liquid/
MIT License
11.13k stars 1.39k forks source link

{%- render -%} autocomplete #1822

Open stijns96 opened 2 months ago

stijns96 commented 2 months ago

Hi all,

I've opened an issue at Shopify Theme Tools. There is already an ongoing conversation. Please check that one first.

Below a summary.

Is your feature request related to a problem? Please describe. I always have to check the self written documentation in my snippets to see what props I can pass to my snippet.

Describe the solution you'd like I was thinking about something like this.

{% prop source = object | required: true %}
{% prop width = number | required: true | default: 768 %}

{%- liquid
  prop source = object | required: true
  prop width = number | required: true | default: 768
-%}

I know this image now shows the source autocomplete from HTML, but this could be an autocomplete/suggestion from Liquid. It works a little bit like typescript, but then for liquid.

Image

At this point I'm not sure if this will work for liquid, but it's just a suggestion that I'd like to see.

Checklist

karreiro commented 2 months ago

👋 Hey everyone,

I believe this is a really valuable problem to solve. However, I'm not quite sure about the solution.

While it's valuable to introduce some kind of help for folks when they are rendering snippets, so they don't miss any dependent variables, I believe we'd be introducing elements into the Liquid runtime that are not part of the language (such as the object and number elements linked above).

I've noticed that Dawn snippets follow a strong convention of defining accepted elements in the header of snippet files, and I believe we could leverage that emergent pattern to support us in a JSDoc fashion, handling this as a purely tooling-focused feature.

Here's an example of an alternative way to solve the same problem:

{% comment %}
  Renders the test snippet

  Accepts:
  - source: {object} Blog object
  - width?: {number} Optional width of the page

  Usage:
  {% render 'test', source: 'the source', width: 800 %}
{% endcomment %}

{%- render 'test', soâ–ˆ -%}
                     ^-- code completes with source

I'm just leaving this as an alternative approach. But I believe the idea shared by @stijns96 is quite interesting. Still, the introduction of elements that are not part of the language makes me believe it's something a bit less incremental and introduces concepts that might have a broader impact.