We’re building a POS app where an action is performed by an extension rendered to the pos.home.modal.render target. If the action succeeds, we close the modal via the Navigation API. Once this has happened, we need to perform some action in our pos.home.tile.render extension. I’ve scoured the docs but haven’t found any way to communicate between the two extensions. Is there any way of achieving this? Things I’ve considered/searched for without success:
an event when the tile is made visible/the modal is closed etc.;
Thanks for the suggestion @Dylan! I’d thought the same but it seems a bit over-complex to have to make a request from one extension and a second request (or even poll) from another given that both are running in the same app. Since the intention is to respond to an event, data doesn’t really seem to be the right way to handle this.
I’ve found a workaround for now that does depend on data: our particular use case is applying a discount to the cart from within the home modal extension, so I’ve made the home tile extension subscribe to the cart and run an effect whenever its number of discounts changes. It’s not great and I’d really expect more API-oriented means to interact between different parts of the POS app, but at least this works for my specific needs at the moment
Thanks for the ideas @JordanFinners! Are websockets available in POS UI extensions? I haven’t checked, because it isn’t ideal for our app to maintain a server connection for each POS instance. I didn’t see any metafields exposed through the POS UI extension API either.
I ended up going with a workaround where I’ve hijacked the cart’s properties hash as a means of messaging between extension targets. Since the cart is subscribable and is common to the extension targets we’re building for, pushing a property into the hash triggers an update of cart.properties in other extension targets as well. This feels horribly dirty (not least because any properties get shown automatically on the cart page in the app, so we have to remove them as soon as we’ve pushed them) but unless I’m missing something, so far the POS UI extension API doesn’t allow for any “direct” communication between endpoints. This actually seems like a huge oversight if it is the case: the extension targets all run within the same application so it seems like it should be possible. Without such a mechanism, it also means that our extension targets have to either use clunky workarounds to communicate, share data/state etc., or be built to function in 100% isolation. Another example of the problems this creates is that our home tile and modal extensions require a lot of the same data which needs to be fetched from our back end; not being able to share this results in a lot of duplicated network requests which slows the app down and increases traffic to our API unnecessarily
If communication between extension targets is deliberately disallowed, it’d be great if someone from Shopify could explain why, and how we’re expected to resolve the resulting problems the decision creates as described above
Yeah, you can use them at the moment, I believe it’s an “undocumented feature” for now, but works.
If you use something like Cloudflare Durable Objects, or AWS Websockets you don’t need to maintain a server 24/7, but depends on your architecture.
With metafields they aren’t exposed right now directly in POS, but you can hit your API to get/set them for example, while keeping your app close to Shopifys data storage. As by the sounds of it you already have an API available to do this.
I can see it from both sides, that it is some workarounds for you right now. But also, with the security concerns of tiles/apps talking to each other and the way to run that code on device and be able to do some key tasks offline.
I’d thought the same but it seems a bit over-complex to have to make a request from one extension and a second request (or even poll) from another given that both are running in the same app. Since the intention is to respond to an event, data doesn’t really seem to be the right way to handle this.
