Use {% render %}, vars, assets , or other inside {% schema %} to make repeated settings modular, reduce duplicated settings code.

[PaulNewton]

It would be better if we had some way to reference a single file to be reused in {% schema %}'s

Using {% render %}, variables or assets filters? , or some other method inside {% schema %} to consolidate code, making repeated settings modular and composable without needing external tooling.
Also see discussion here for "Shared schema capabilities"

Settings have always had a high amount of duplicated code which has made it important when developing themes to also have to create a build process or tools to help share a single source of code for schema's across multiple files.

But that's if you know how to make build tools or have the time to do so.
Then aftermarket developers wont have any of the build process used to make a theme so changes to settings can mean editing every single file by hand that needs a specific setting changed or added; when find+replace aren't up to the job; which can also be an error prone process editing a machine format even it is human readable.

And that was for sections, this problem is going to 💥explode💥 when extended to theme-blocks settings and presets.

It would be better if we could just get rid of this extra phase of editing.

For example if a merchant wanted to add a custom icon to the reference theme at least three areas have to be edited.
The {% schema %}'s in two block files and a snippet to insert the svg code.

https://github.com/Shopify/reference-theme/blob/main/blocks/icon.liquid
https://github.com/Shopify/reference-theme/blob/main/blocks/link.liquid
https://github.com/Shopify/reference-theme/blob/main/snippets/icon.liquid

In such customizations the merchant then also needs to add liquid-logic to the files to consume the settings.

It would be better if we had some way to reference a single file to reuse code in {% schema %}'s using existing concepts such as:

Hypothetical example of {% render %} inside {% schema %} :

{% schema %}
{
  "name": "Button",
  "tag": null,
  "settings": [
    {
      "type": "url",
      "id": "link",
      "label": "Link"
    },
    {% render 'icon-schema' %},
    {% render 'icon-schema' , default: 'none' %}
  ]
}
{% endschema %}

with icon-schema containing the entire icon setting in the icon block

Hypothetical example of variables made outside the {% schema %} :

{% capture schema_image_picker %}
    {
      "type": "image_picker",
      "id": "image_upload",
      "label": "Custom icon"
    }
    {% render 'icon-schema' %}
{% endcapture %}

{% schema %}
{
  "name": "Button",
  "tag": null,
  "settings": [
    {
      "type": "url",
      "id": "link",
      "label": "Link"
    },
    {{ schema_image_picker }}
  ]
}
{% endschema %}

Hypothetical example of an asset filter for json assets inside the blocks folder {% schema %} :

{% schema %}
{
  "name": "Button",
  "tag": null,
  "settings": [
    {
      "type": "url",
      "id": "link",
      "label": "Link"
    },
    {{ 'icon-schema.json' | block_asset }},
    {{ 'icon-schema.json' | block_schema }}
  ]
}
{% endschema %}

Hypothetical example included JSON can be partial it doesn't have to be a full setting or schema.

Or course the rendered code still must always results in valid json so what is actually in the snippet doesn't have to be a full schema.
Meaning this this would work as well just filling partial of a setting instead of the entirety:

{% capture schema_image_picker_label %}  "label": "Custom icon"{% endcapture %}
{% schema %}
{
  "name": "Button",
  "tag": null,
  "settings": [
    {
      "type": "url",
      "id": "link",
      "label": "Link"
    },
    {
      "type": "image_picker",
      "id": "image_upload",
      {{ schema_image_picker_label }}
    }
  ]
}
{% endschema %}

Or other?

Meanwhile something more strict requiring the included files to contain an entire setting or preset would probably require a new tag , or new setting types don't use liquid and are still only JSON to reference the files.
I'm not a fan of yet another tag piling on liquid's growing vocab, but I'm a huge fan of something that would wipe out thousands of lines code in themes and reduce the complexity of third-party build tooling; though may add complexity to syntax-highlighting womp womp

Hypothetical example of a new setting properties to reference settings files for inclusion.

{% schema %}
 {% section_schema 'shaped-divider-schema' %}
 {% block_schema 'badges-schema' %}
 {% setting 'badges-schema' %}
 "etc": "etc etc"
{% endschema %}

Example of a $ref property by panoply

  "settings": [
     { 
        "$ref": "icon-schema.json"
      },

See @panoply's discussion #15 (reply in thread)

What new tag names or setting-property names would be ,or there exact syntax would be something to hash out.
Preferable if it's syntax has some similarity to some mainstream system familiar to most devs; can't think of any off top of my head.

I guess the blocker for this has probably been something like the visual-theme-editor's statically parsing the JSON

[TeamDijon]

Lots of great suggestions, there are so many ways to approach the subject, it's crazy ahah

Definitely agree more when you're saying the shared schema problem will explode with theme-blocks !

[PaulNewton]

The sanest way is to treat liquid as intended: to be approachable by merchants.
So we have to stop adding things to the language that can instead be done with what exists, to be able to use what's there without having to know|remember the increasing amount of catches and exceptions.

[TeamDijon]

While I agree that we should not add too much in order to enable shared schema, schema is in the end JSON and should be treated as such. As long as we have proper documentation (which we have for schema), adding a few properties inside schema should not be that big of a hurdle.

For a basic implementation, I thought of the following based off @panoply great and extensive work :

• A file inside the config theme directory, perhaps shared_schema.json
  The file is a JSON collection of schema blocks, characterized with an ID and a list of schema input settings

{
  "schema_groups": [
    {
      "id": "schema_group_id",
      "settings": [
        {
          "type": "range",
          "id": "max_width",
          "label": "Section max width",
          "min": 200,
          "max": 2000,
          "step": 20,
          "default": 2000
        },
        { ... }
      ]
    },
    { ... }
  ]
}

• A reference schema setting

{
  "type": "schema_reference",
  "id": "schema_group_id"
}

Just that would be a good start, amounting to 80% of the needs. All without any major disruption of schema expected behavior and minimal addition to the documentation for the end-user.

When the feature becomes mature, we can then start to implement some override capabilities to unlock another layer of shared schema. For the basic implementation, there could be some problems of having really small schema groups, in order to account for all possibilities. With some override, the abstraction layer could lead to some really interesting patterns from theme partners :)

[panoply]

Hey @PaulNewton,

I do like this but I have some reservations about the Liquid and JSON infusion. I tend to lean on the side of keeping Liquid within markup and is personal preference that stems partly from the challenges I've faced taming lexers in Æsthetic to handle Liquid structures within JavaScript, CSS and JSON. But, I digress...

AFAIK Shopify processes {% schema %} regions in a very specific manner. The actual JSON isn't processed in real-time when a visitor accesses a page. Instead, it's handled beforehand during theme compilation and preparation. That pre-processing approach might make it difficult to implement your suggestion as described, but I'm merely speculating, so don't hold me to it.

That said, I believe many experienced developers would welcome the ability to dynamically inject schema on the fly as per code samples. Your suggestion here would certainly help reduce repetition and promote a more DRY approach overall. However, we should consider that this level of extensibility might only benefit a small minority of developers who are well-versed in the intricacies of Shopify theme dev. Maybe I'm over analyzing here, but it's easy to forget that many developers working on Shopify themes may not approach problems with such advanced techniques in mind (IYKWIM), but I'd be curious on the thoughts of other devs.

Regarding the shared schema tactic

It went through several iterations before arriving at the version I described in #15 (reply in thread). I was fortunate to receive valuable feedback from several talented developers, including @TeamDijon, during the initial phases. The goal was to make shared schema feel native and avoid overly complex logic. I believe the current implementation achieves this, and Shopify could potentially replicate that functionality with relative ease, given that it mimics behavior already present in the theme architecture.

As you pointed out, the current approach does require a build step, which can be a barrier to adoption for a lot of developers, and I'm yet to make things easy for devs in Syncify. It's worth noting, however, that Syncify has been designed as a potential replacement for the Shopify CLI in theme development, with the foundations already in place to achieve its intended purpose.

FWIW, I'm planning to resume active development on the project in coming weeks. Once it's out of beta and viable for real-world usage, I'd love to have someone with your expertise provide insights. I've really enjoyed reading your perspectives and suggestions in this repo lately.

[PaulNewton]

it's easy to forget that many developers working on Shopify themes may not approach problems with such advanced techniques

For developers, designers and merchants part of the point of this feature is being LESS advanced: it's simpler when there is consistent usage of language features, snippets and variables working everywhere in templates.
Every designer that sees {% render 'price' %} can immediately follow that logic of where some single piece of code lives.
Seeing {% render 'block-schema' %} would be as simple.

{% schema %} getting an exception IS the advanced technique, a force-multiplier in complication compounded by all the other you-should-have-known gotchas that have accumulated in shopify-themes over the years.
For authorship digging through dozens of sections/blocks to edit a schema is it's own advanced technique and currently the poor QOL most are living with and will toil even harder with if this problem isn't solved at the language/platform level.

These exceptions and toil are the advanced technique's that we as developers are so used to we don't even think of it as advanced "it's obvious" because we have or know the advanced tools, or we learnt to NOT be able to use language features instead of being able to just use it due to a specific advanced exception.
..then we forgot we had to climb that one very specific tree out of all the other far away trees, so that it's only if the tree gets removed that we notice the lack of it from a distance unable to see the stairs created to replace it.

Meanwhile some new merchant/designer/dev is working with notepad because the internet is off in the subway.
They don't know what they don't know about code-editors but the language shouldn't punish them or the rest of us for it from the get go.

[PaulNewton]

I tend to lean on the side of keeping Liquid within markup

I agree because we already treat JSON likes it's markup with liquid in shopify themes for things like schema.org, js frontend frameworks, js frontend config/settings objects etc.
And we do that since there is no specific non-liquid system for markingup/authoring JSON in shopify themes.
Forcing {% schema %} to be an inconsistent exception, that in enforcing such a "markup only means html" truism just creates new compounding problems giving any future features like nestable-blocks their own difficulties on arrival.

[PaulNewton]

given that it mimics behavior already present in the theme architecture

Where is something like "$ref": "icon-schema.json" in the architecture, have I missed something new somehow???
Or do you mean mimics the JSON support itself i.e. "propname": "value"

Not on shopify liquid-themes, but I've seen stuff like that but I can't think of anything specific.
If there is a popular mainstream system, convention, or standard that can be pointed at using similar syntax that would be the type of thing to push on if {% render %} can't be a path forward.

Aside: I guess a side issue is also having linters and parsers that don't flip out or fail if there's an unrecognized property. so if a pre-build file gets pushed to a theme as the schema still works as much as possible. 🤔 Though I guess the newer comment support in JSON can be a workaround there ,but ugh parsing comments as logic.

[panoply]

The multiple comments create a lot of noise, making communication difficult and reducing engagement. Points cannot be addressed correctly when there are several comments and this leads to obfuscated discourse. While threaded conversation trees would help, GitHub doesn't support them. Given that you have some great thoughts and ideas, it would be better if they were more contained for easier digestion.

I'll respond to all the above 3 comments below.

---

# 1

For developers, designers and merchants part of the point of this feature is being LESS advanced: it's simpler when there is consistent usage of language features, snippets and variables working everywhere in templates.
Every designer that sees {% render 'price' %} can immediately follow that logic of where some single piece of code lives.
Seeing {% render 'block-schema' %} would be as simple.

I hear you, but what you are proposing is extraneous and I don't see what problem it solves other than flexibility via design pattern. The approach you've suggested requires, {% capture %} encapsulation, {% render %} referencing and JSON injection to achieve the desired outcome.

{% schema %} getting an exception IS the advanced technique, a force-multiplier in complication compounded by all the other you-should-have-known gotchas that have accumulated in shopify-themes over the years.

I disagree. There are 3 separate JSON structures here, each has varying nuances to grapple with. It's not that the pattern you've suggested is not viable, it's that it requires far more consideration and strict adherence on the markup level. Liquid's simplicity often leads to chaotic usage and this extends to {% schema %}.

Without enforced standards, such extensibility becomes unpredictable, especially for novices. This is why I consider your suggestion advanced – it increases cognitive load, far more prone to inconsistencies and requires varying awareness to implement effectively in Shopify themes permissive environment from the developer.

# 2

I agree because we already treat JSON likes it's markup with liquid in shopify themes for things like schema.org, js frontend frameworks, js frontend config/settings objects etc.

This is something, that I too noticed. Few points on this.

I do have solutions for specification which address the various contexts in which Liquid is used. These are actually what enable IDE capabilities in VSCode Liquid. The @liquify/specs project provides grammar-like custom-data references, and the entire Shopify Liquid API has been mapped with the shopify directory being particularly relevant.

Regarding JSON specifically, @liquify/schema is another project I maintain. It works in tandem with VSCode Liquid, leveraging the JSON language server to offer comprehensive IntelliSense capabilities for Shopify schema (section + other) structures.

Forcing {% schema %} to be an inconsistent exception, that in enforcing such a "markup only means html" truism just creates new compounding problems giving any future features like nestable-blocks their own difficulties on arrival.

Personally, I have reservations about many of Shopify's proposals for OS~3. The concept of nestable-blocks, in particular, fails to impress me. Until these features are in production, we can only speculate about their implications and nuances.

Regarding the {% schema %} tag, as aforementioned, I am opposed making it an inconsistent exception and allowing Liquid infusion. The only context where I find Liquid infusion acceptable is in the locales strategy, where we can use Liquid syntax for properties suffixed with _html but there is no appropriation point for that in this context.

# 3

Where is something like "$ref": "icon-schema.json" in the architecture, have I missed something new somehow???
Or do you mean mimics the JSON support itself i.e. "propname": "value"

Shared schema leverages referencing behavior, mirroring existing patterns in Shopify's theme architecture. When I mention that it mimics behavior already present in the theme architecture, I'm specifically referring to Shopify's underlying logic for creating relationships between files and views. Shared schema parallels how Shopify processes section files within JSON templates. In JSON templates, we establish relationships between sections and templates by referencing a filename, For instance:

Theme	Schema
├─ sections │ ├─ foo.liquid │ └─ bar.liquid │ ├─ templates │ └─ index.json	{ "sections": { "foo": {"type": "foo"}, "bar": {"type": "bar"} }, "order": ["foo", "bar"] }

The shared schema tactic effectively mimics this referencing relational behavior. While not part of the official JSON (section) schema, I introduced the $ref key to enable the capability possible in Syncify. FWIW: I chose to prefix $ref with a $ dollar sign as it's a common convention in JSON to use $ for special or action-oriented keys.

Aside: I guess a side issue is also having linters and parsers that don't flip out or fail if there's an unrecognized property. so if a pre-build file gets pushed to a theme as the schema still works as much as possible. 🤔 Though I guess the newer comment support in JSON can be a workaround there ,but ugh parsing comments as logic.

So, a few things on this point.

First, I'd like to clarify that I don't think your proposal is inherently bad or anything. In fact, I believe developers can greatly benefit from this capability. However, I see it as an alternative pattern more prone to inconsistencies. The same outcomes can be achieved with less verbosity and more consistency by using a shared schema.

Regarding the IDE capabilities, Liquid occurrences in non-markup languages present a significant lexical challenge. I've spent considerable time addressing this issue. In the upcoming release of Æsthetic, It is possible to actually extend it to apply beautification within custom {% capture %} regions and have Æsthetic pass the containing contents of certain tags to one of its lexers. This means that JSON contained within captures as per your suggestion can be formatted and apply a small subset of validation (only parse errors throw), anyway, my point is that it is not impossible to achieve.

Below is a small screener of JSON and Liquid beautification support to give some visual representation:

json.mp4

When we talk about extending linting capabilities, this where complexity arises. When we encounter such lexical anomalies as Liquid in JSON or Liquid in CSS and even Liquid in JavaScript, there is no definitive "right way" or consensus on how a parser should interpret this mixture of languages. This edge case realm poses unique challenges, and the study of achieving lexical context in such scenarios has not been extensively explored in academia. While possible to extend upon existing solutions, you'd be pressed going that route, and as such, one would need to produce their own parse algorithm to tackle the nuances and variabilities.

[PaulNewton]

Meta fix: native build system

For JSON authorship having full liquid support in {% schema %} tags is sanity measure, addressing several problems in developering, customizing or managing shopify themes.
Meanwhile a bigger broader fix would be shopify coming out of left field and adding a native build system for online store-themes.
But that's would be such a WILD departure , and there are soooo many ways to implement that, making a build-system such an EPIC WANT it seems non-sensical to even bring it up for liquid-themes

A native build system is such a departure that in practice if a single merchants theme needs a build system that's just an indication that a store should be using hydrogen.
So that's why I haven't bothered to create a discussion about such a meta feature to bypass {% schema %}.

[panoply]

For JSON authorship having full liquid support in {% schema %} tags is sanity measure, addressing several problems in developering, customizing or managing shopify themes.

I'm still having a hard time understanding you reasoning for this. While the existing logic is not perfect it is very powerful and trust me, I'm the last person in the space to give praise to Shopify, but OS ~ 2.0 solves almost all nuances and imo only minor changes should apply to OS ~ 3.0.

Meanwhile a bigger broader fix would be shopify coming out of left field and adding a native build system for online store-themes

If by native builds, you are referring to CI/CD infrastructure made available on the platform, that would be cool. However, theme developers will almost always apply local logic. The bigger problem is how they've approach theme development via the CLI, which imo is not very good.

In any sense, developers can already replicate a native build system using the existing infrastructure Shopify provides by forwarding content to third-parties for processing (e.g: Vercel, Netlify etc). Though not very elegant, it is possible. Before markets become available, I would have geographical references generated and written to themes via webhook that would trigger lambdas and publish content to themes over the wire.

So that's why I haven't bothered to create a discussion about such a meta feature to bypass {% schema %}.

Does this not apply specifically to your proposal here though?

[PaulNewton]

If nothing is done...

I wouldn't be shocked if some are clinging to the idea of AI|LLM fixing such gap issues so once again everyone can ignore that first-party tooling is not first-class while ANI-assistants spout out time wasting nonsense.

And any gold rush or golden era in third party tools shouldn't be where the bare minimum in a first day experience,

Meanwhile if nothing is done because it's too hard or it's kicked down the road due to "technical limitations" that means in terms of authorship efficiency the code duplication in the nesting-blocks architecture will be yet another new larger gap between have and have-nots

[jdunham2]

Another idea for implemention here: #15 (reply in thread)

Main difference is not to use the render tag but to extend the schema tag to work like it.

The nice part of keeping them separate is that the schema tag references files in the ./schema directory, as render references the ./snippets directory. This keeps the concerns separated.

Also, in this implementation, existing liquid syntax is retained making adoption of the new syntax very easy.

{% schema %}
{
  "name": "Group {{ ss_app_version }}",
  "tag": null,
  "blocks": [{ "type": "@theme" }, { "type": "@app" }],
  "settings": [
     {% schema 'size-panel', width: '100%' %} <-- renders contents of ./schema/size-panel.schema
     ...
}
{% endschema %}

//  ./schema/size-panel.schema file
...
{
  "type": "text",
  "id": "size_width",
  "label": "Width",
  "default": "{{ width | default: 'auto' | strip_quotes }}"
},
{
  "type": "text",
  "id": "size_width-mobile",
  "label": "Width",
  {% if width-mobile %}
    "default": "{{ width-mobile | strip_quotes }}",
  {% endif %}
},
...

[PaulNewton]

I'm for something like this, though more than likely needs to overload the /config folder; ala section locales in /locales
I do not see shopify adding yet another folder, but then again more than 2 files in /config would also create a ton of initial confusion and probably break a lot of naive tooling or complicate tutorials with a new risk.
They added the inline_asset_content filter before allowing a different folder structure. Of course that means they also reached for a filter before creating a new type of content tag for assets or changing render tag behavior for assets but then added /blocks folder for nesting complexity sooo... 🤷‍♂️