I wanted to share some pain points I’ve noticed while developing theme app extensions over the past year or so:
Deprecating/removing settings
No available_if_not: It would be amazing if we could make an app block usable only if a specific metafield were not present. This would make it very easy to deprecate outdated app blocks for new users.
Settings do not have available_if/available_if_not: This makes it very challenging to remove settings from an app block.
A pretty common scenario is:
Based on customer demand for a specific feature in the storefront, I create a new app block
As time goes on and I gain a better understanding of the problem being solved, I want to change the implementation of the app block. Maybe I’ll be removing settings. Or maybe, the entire setup could use an overhaul. I’ve found that app blocks lack flexibility and make such changes difficult.
Deprecating app blocks
It’s hard to know which users are actively using which app block. Your best bet is to use the Theme API and parse the JSON templates, but this might not be all too reliable if, for example, some existing users haven’t granted you read_themes access or if you no longer have a valid session token for them.
As a result, if you want to remove a deprecated version of an app block, you risk breaking your users’ stores without being able to at least contact them beforehand.
Onboarding
Deep links cannot contain configuration information. Let’s face it: most users do not read the settings/documentation when adding app blocks to their theme. People frequently miss important information. It would be amazing if apps could just deep link users to the perfect settings for their theme.
Though you can autofill settings of type product, you can’t do this for collection.
Lack of dynamic configuration
App blocks cannot contain other app blocks as their children. This would make it possible to have more dynamic configuration. For example, if you had a “Collection list” app block/section, and wanted users to be able to provide different settings for each collection in the list, there’s no way to do that right now.
Conclusion
Theme app extensions are very much a “once you add this app block/setting, it’s there forever, and removing it might be unsafe” situation.
It is difficult to improve the onboarding process for theme app extensions.
Thanks in advance for your consideration. I recognize this is a long list. It would be interesting to hear if any other developers are facing similar challenges.
Cannot use a deep link for multiple app blocks installation
limiting settings - max 25 allowed
Users don’t read docs, I don’t have an installation process but forced to have one after upgrading to app blocks from section liquid files. But most users find it hard to follow.
BFS has a hidden assumption to have 1 app block added to the existing product template as a widget. Most apps work like this. If you don’t follow this convention, it’s hard to pass the storefront performance test.
Appreciate you sharing your experiences and feedback here - I’ll ensure that the product team in this space is alerted to these. And we also welcome more feedback from other devs in the community building theme app extensions.
Restrictions on the assets under the theme app extensions
Unable to upload font files to the assets folder
Settings in theme app extension are not accessible via a api - the api helps in case merchants face customisation issues today! We need to ask for collaborator access to achieve any customisation on top of the extensions when a merchant is unable to do one themself
Theme app extension webhook
A webhook that informs when a app extension is enabled or disabled
I also want a way to migrate a schema setting. I use a checkbox to activate a feature (e.g. show a step builder); however, when time goes by, some users want more styles (e.g. square button steps, round button steps, etc). I find that there is no way to handle this migration.
I can’t move from the checkbox to a drop-down select box, unless I deprecate this setting and replace it with a new one. Also, there are only 25 settings in an app block. If I add a new one, I run out of the limited options.
This app block feature is pretty limiting. Many app developers have abandoned this feature and use the app embed block with their custom visual editor. Can you upgrade the app block features?
I don’t see any obvious upgrades after the app block was launched a few years ago. It makes the app developers using the App Block lag behind the others
@Liam-Shopify, I second some of the pain points listed by @tobebuilds, particularly about upgrading a block to a newer version that might have completely different settings, without affecting merchants that have the block running in production.
A couple of ideas for brainstorming:
Extension versioning: Allow us to specify different live versions for an extension. For example I could have Block 1.0.0 extension. If I deploy any Block 1.x.x, it’s applied to all merchants with the 1.x.x series. But if I release Block 2.x.x, it only applies to new installations. This would allow us to maintain different streams of blocks, but could get very complex very quickly.
Create a onNewVersionDeployment function: This would be a one-off function defined in the schema,that lets us access values in the current schema and copy them to the new one.