Is there a standardized method for detecting variant changes when we want to update app block content based on the selected variant?
Currently, examining the “Dawn” theme files, I’ve noticed a “pubsub.js” file and a custom element called “VariantSelects” in the “global.js” file that publishes variant changes.
javascript
class VariantSelects extends HTMLElement {
constructor() {
super();
}
connectedCallback() {
this.addEventListener('change', (event) => {
const target = this.getInputForEventTarget(event.target);
this.updateSelectionMetadata(event);
// Here it is! This seems to be provided by "pubsub.js"
publish(PUB_SUB_EVENTS.optionValueSelectionChange, {
data: {
event,
target,
selectedOptionValues: this.selectedOptionValues,
},
});
});
}
...other...
While we can detect variant changes using subscribe(PUB_SUB_EVENTS.optionValueSelectionChange, CALLBACK) with this approach, I often encountered search results suggesting document.addEventListener("variant:change", CALLBACK).
This led me to wonder: “Doesn’t the method for listening to variant changes differ completely depending on the theme’s code? Or might some themes not have this functionality at all due to code reduction?”
However, there are cases where we want to create app blocks that change their display content based on the selected variant.
simple example: app block that displays the value of a metafield associated with a variant.
It seems impossible to create such app blocks without a rule stating “Always do this after a variant change”. What are your thoughts on this?
This is correct - it’s very challenging to find a fully reliable method for apps to respond to changes like a variant changing on a section. If it’s a product page, changing the variant will change the URL, so that’s easy to adapt for, but on other pages there could be different techniques used by devs to update dynamic content so you could have to set up a different event listener depending on how that theme is set up.
I appreciate your confirmation. Here’s my personal opinion on this matter:
I believe it would be beneficial for both app and theme developers if Shopify were to provide an official library, available as a package and via CDN, that offers a consistent interface for handling such functionalities in the long term.
Key points:
Utility beyond app block development: This library could be useful for various theme development tasks.
Lightweight implementation: The combined code of “pubsub.js” and the “constants.js” file containing PUB_SUB_EVENTS is less than 40 lines, making it a lightweight solution.
Minimal impact on existing practices: It’s unlikely that many theme developers are deliberately removing files like “pubsub.js” (though this is my speculation).
While the code might grow if similar cases are addressed, I believe the benefits of having consistent functions to solve issues like this outweigh any potential drawbacks. As mentioned in point 1, these functions could be widely used in theme development as well.
I really like your proposal of this consistent model to ensure easier implementation between apps and themes - and I’ll be presenting this to the relevant team internally. There are also efforts headed by the developer community that aims to improve the connectedness between apps and themes, eg Theme Elements and JS event guides for specific 3P themes.
Although many themes change the URL (SearchParam) when changing variants, the implementation is free, so it is not certain.
Also, as I mentioned, the latest “Dawn” functions such as subscribe and publish may not be used in many themes.
I sorted the “Paid Themes” by “Popularity” at https://themes.shopify.com/, and tried to check subscribe and publish in the developer tools console on the demo site in order, but I found that they were not defined.
