The only way to close a modal is using a button with command="--hide". This makes it impossible to do validations before closing the modal.
My use case is fairly simple: Click on “save”, submit the form, if there’s an error keep the form open with an error banner, if it’s success close the modal.
Ah thanks @Anthony_Frehner, I missed the “complete workflow” example, it shows how to hide the overlay! I managed to do it with this in my success code:
@Luke I didn’t know about the modal api, but it doesn’t seem to be working with s-modal for some reason. Or might be a bug because it seems to be detecting my modal: if I put a wrong ID it makes an error in the console, if I put the correct ID there’s no error but it also doesn’t close the modal.
Anyway the “hideOverlay()” thing seems to do the trick!
The solution using querySelector does work but this is such a HUGE step backwards compared to the React component that was using a simple boolean to hide/show modals programatically….
Completely agree, the whole web components thing is a big downgrade to everything we had before.
I’ve been working on the POS which was already not the most reliable platform of Shopify and the web components change somehow managed to make everything even more complicated to do extremely basic things.
I kind of wish Shopify would use the same tools as us to build their own UI. Polaris is supposed to allow us to make UIs that looks native, but the new polaris web components makes this almost impossible.
I had to “monkey patch” polaris web components just to add a gray background to table rows to replicate the archived orders rows of the orders page (though this wouldn’t be possible in any other surfaces than the app’s embedded pages).
Works well in React, doesn’t work well in any other framework. I sympathize that your React experience is a bit worse, but we have a large ecosystem of developer tools to think about.
I suspect you could build a custom hook that uses a ref underneath to get a better experience?
Though the parity of what we have access as app developers and what we see in the Shopify’s own UI is definitely not there at the moment. For example I have a page that the functionality is pretty much the same as the Shopify’s orders page, but the table that Shopify uses is more compact and has a “subdued” rows for archived orders, those are not available in polaris web components. I had to do a really complicated “monkey patch” just to get those really basic things that are already part of Shopify’s UI.
In the app’s embedded pages we can pretty much do whatever we want so we can kind of hack our way around those limitations, but with all the UI extensions there’s not really any way to do the same.
Paddings in the shopify UI are also not the same we have access in polaris web components, in some places Shopify uses paddings that are smaller than the “small-300” we have access to.
I don’t have anything against web components themselves, more that it’s not yet there if the goal is to be able to make UIs that really feels native. Just a lot of small random details that bundled together makes it not really feel like a native UI from Shopify.
I might be putting too much thought in trying to make UI that really replicates shopify pages feel, but there’s just always a little something that doesn’t really feel right.
(POS is the biggest place I’ve worked with where there’s A LOT of limitations with web components)
Thanks for the feedback! Yeah, I understand things are not at 100% parity right now. However, we’re working hard behind the scenes to get ever closer there. Things like Tables are definitely on our radar for differences, and you’ll also see a lot more uniformity as time goes on. We’re working hard behind the scenes on all of this!