fyi, setting "selected" in the template takes care of it. Can you add this to the converter?
<option
li-element="product-option-select-loop"
class="option"
x-text="variantName"
:value="variantName"
:checked="selected_or_first_available_variant?.options.includes(variantName)"
:selected="selected_or_first_available_variant?.options.includes(variantName)"
>
although it's still not working correctly on the 2nd and 3rd product options, when they are also select inputs rather than radio buttons. I've debugged this through and found that the call to updateVariantStatuses is setting the option 2 and 3 selectboxes back to a default state, despite what the selected variant is on initialization.
I'm not sure this makes much sense to do at all, when you call the product page and pass in the variantid as a querystring paramter, the handleVariant() funtion is going to get that particular variant. And, even in your example template the price of the selected variant is always displayed.
So, for this scenario, I'm not sure why you've put this in here. This code is scoped only to when it's a 'select' rather than a radio button, which implies there's some sort of hierarchial dependcy, but there's not. Just like with using radio buttons, those are mapped directly to a variant ID.
I believe what you're attempting to do is disable the options if it's unavailable but I'm not sure the logic is correct; and besides that there's logic to show an "out of stock" rather than "add to cart" in that event, which are two conflicting design choices.
Hi @jason, thanks for your post. We will take a look.
Thanks, in the meantime I removed the product-variant-handler tag from my component and manually set some of the bindings, and created a copy of the liquify_custom.js file to use with my edits, as it will be overwritten every time I convert the theme
Hi @jason, that should be fixed now. Can you test it?
You'll have to give me a little time in order to do that, I've already made significant changes to work around this and it'll be a bit of an effort to unwind. I'll likely clone the project and branch it to test, sometime next week
@jonas.halbstark your changes here look pretty similar to what I did. Granted, I need to keep with my replacement for the entire script due to custom field validation and add to cart logic I've added, but I think your changes are good. In fact, they are so close, I had to go look at an old commit to see what it was originally, because side by side, our updateVariantStatuses() look the same
Hi @jason, sounds good 🙂
What kind of add to cart logic have you added? Maybe we can extend our script
@jonas.halbstark sorry for the slow reply, I've been away. I'll just leave it at this: we have a lot of extended product options that aren't handled natively in Shopify product options, that are a part of configuring our products. Some of those end up being additional variants that are bundled, and some are line item properties that are added, and there are a lot of cascading dependencies. It's all just very, very custom to us.
The other big part that goes with that is custom form validation; so the combination of it all requires we build out this part on our own. However liquify give us the building blocks for it (along with alpine
