Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

{%- render -%} autocomplete #1822

Open
1 task done
stijns96 opened this issue Aug 28, 2024 · 1 comment
Open
1 task done

{%- render -%} autocomplete #1822

stijns96 opened this issue Aug 28, 2024 · 1 comment

Comments

@stijns96
Copy link

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

  • I have checked and made sure that the proposal adheres to this plugin's principles
@karreiro
Copy link
Contributor

karreiro commented Sep 6, 2024

👋 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants