💡 Feature Request: Simplify Liquid Access for App-Owned Metafields for Merchants

Custom Data
1

Hello everyone,

I’m posting this to highlight a significant friction point for merchants and theme developers trying to build custom storefront experiences using data provided by apps. This specifically relates to accessing app-owned metafields in Liquid.

The Current Problem

When an app creates a metafield definition on a resource (like a product or shop) using a reserved, protected namespace (e.g., $app:my-app-data), the standard Liquid access for a merchant or theme developer is complex and brittle:

  1. The simple, merchant-created metafield access looks like this:

    Code snippet

    {{ product.metafields.my_namespace.my_key.value }}

  2. The access for an app-owned metafield is often not that simple. Instead of using the short, friendly namespace the app owner defines, we are often forced to use the fully expanded, hard-to-find namespace that includes the App ID, like:

    Code snippet

    {{ product.metafields.app--12345678910--my_app_data.my_key.value }}

This is not merchant-friendly for a few key reasons:

  • Discovery is difficult: A merchant has no easy way to know their app’s ID (12345678910). They usually have to dig into the app’s settings, a URL, or the GraphQL API.

  • Brittle code: If a merchant changes their app (even for an upgrade or replacement of the same function), the App ID changes, and the Liquid code breaks.

  • Inconsistent Experience: It contrasts sharply with how easy it is to access a merchant-created metafield.

Proposed Solution: A Consistent, Friendly Liquid Object

Could we introduce a new, consistent, and well-documented way for merchants to access app-owned metafields in Liquid using the original, friendly namespace and key?

I propose supporting the following syntax for all resources with app-owned metafields:

Code snippet

{{ object.app_metafields['app-alias:namespace'].key.value }}

Where:

  • object is the resource (e.g., product, shop, collection).

  • app-alias could be the app’s handle/name or the unique reserved namespace prefix (e.g., my-app-data).

  • namespace.key is the developer-defined, friendly key (e.g., config.setting).

A simpler alternative could be:

Code snippet

{{ object.metafields.app_namespace.key.value }}

…where app_namespace is whatever the app declared, and Shopify’s Liquid layer resolves it automatically to the correct app--ID--namespace.

This change would dramatically improve the developer experience for merchants, simplify theme customization, and make Liquid code more readable and robust against changes in App IDs.

1 Like
2

I think allowing apps to have a ‘app-namespace’ is a fantastic idea, even if it did require some ‘keyword’ like $app:discount-kit or $app:swym - which I believe could also be backwards compatible?

1 Like
3

Just calling out for any readers: you can use $app and co. in theme app extensions already today – Configure theme app extensions

@Sakshi_Gupta is your inspiration behind this about customising the theme to show metafields that were created by some other app, that you have no association with? Or is it about showing metafields that have been created by an app that you/the shop owner has put together?

4

Its about showing the metafields for merchant in their own liquid not necessarily from the app’s extension! Custom builds on merchants side should be able to use app metafields better. If we switch to merchant owned metafields - the writes are public and the other way is a lot of friction to share the metafield to the merchant with a app id etc

1 Like
5

Here’s some example documentation on how brands can use data populated by our application: Storefront data - Discount Kit

We’ve had to add discount_kit as the namespace, so fully formed: app--9549316097--discount_kit.

Otherwise app--9549316097 on its own has no concept of what app it belongs to without deeper investigation.

6

I understand that – but there are cases where a theme app extension is a great fit for a co-developed theme & app and its always worth pointing them out to those who aren’t familiar with them.

@bkspace good call out about better liquid DX with $app:app-name vs. plain $app

1 Like
7

Just to add to @Sakshi_Gupta ‘s note - we are enriching specific entities on the merchant like product, customer, etc with additional dataset that the merchant can choose to render in ways convenient to their implementation. That’s the dataset we are looking for, eg: the reviews/ratings metafield on the product entity is easy to comprehend (and support folks implementing using that field) versus the potentially hardcoded reference that looks out of place in the code. Any simplification we can offer to our merchants and agency partners, the easier they can start using metafields instead of making API calls to our platform dynamically.

1 Like
8

I wasted hours to understand what is the correct syntax and how to use $app.

Here is the exact syntax.

product.metafields["$app"].your_key

if metaobject

product.metafields["$app"].your_key.value

2 Likes
9

image
image1293×852 89.3 KB

And here are the doc links