Add `inlinesize` property to `s-button`

Extensions
1

Hello, I’m in the process of migrating one of our extensions to the new Polaris web components and I’m currently having difficulty getting buttons to fill up the available space in the layout.

Previously I’d use a stack with the flexChildren property to achieve this but this is no longer available. I noticed that elsewhere an inlineSize property has been added to the button component, can we get this on the component available in POS extensions too?

Or am I missing something, is it currently possible to make a button take up the available space already?

2

I have another question, how do I programatically show a confirmation modal?

Previously I could display a Dialog / modal using the isVisible property, this is not present on the s-modal component, which means it can only be triggered by a button click by the looks of it?

3

It’s pretty important that we be able to display a UI blocking modal programmatically.

4

Hey @simon_b - thanks for flagging this as always!

From what I can tell on my end, you’re right that inlineSize isn’t currently exposed on POS s-button, even though similar button sizing support exists on other Polaris web component surfaces. So at the moment there isn’t a supported one-for-one replacement for the old Stack + flexChildren pattern that makes POS buttons fill the available inline space.

I’m going to pass this up on our end as a POS web components parity / migration gap. I definitely get why this matters when moving existing extensions over to the new components.

For the modal question: s-modal in POS also doesn’t currently have an isVisible prop like the older Dialog/modal pattern. For user-triggered flows, the intended pattern is to render the modal and open it with commandFor / command, for example:

<s-button commandFor="confirm-modal" command="--show">
  Confirm
</s-button>

<s-modal id="confirm-modal" heading="Confirm action">
  <s-text>Are you sure?</s-text>
  <s-button slot="primary-action" commandFor="confirm-modal" command="--hide">
    Continue
  </s-button>
  <s-button slot="secondary-actions" commandFor="confirm-modal" command="--hide">
    Cancel
  </s-button>
</s-modal>

For full-screen POS extension modals, shopify.action.presentModal() is still available, but it needs to be called from a user interaction like a button click or tile tap. It can’t currently be invoked during initialization or from a background/programmatic flow, so a truly programmatic UI-blocking confirmation modal isn’t supported in the same way as before.

I’ll raise both things internally though, Let me know if there’s anything else I can pass on as well or if I can clarify anything here.

6

No worries thanks @Alan_G much appreciated.

I have a workaround for both of these I think, but they aren’t ideal. For the buttons I can use percentage based inline sizing, and for the modal I can use another page/screen within my extension instead of a modal, modal / dialog would be much more appropriate though.

An example of a situation I used to use the modal for is displaying a warning message for billing purposes if we detect that they have not activated the location they are making a request from. Or presenting a confirmation prompt when the user attempts to add items to a cart that already has items in it, in this situation they would decide to either merge the items or clear the cart first, I’m not sure I can do this now. My extension is targeting pos.home.modal.render.

7

Hey @simon_b - thanks for the extra context.

For the button sizing piece, I’ve raised this as a POS Polaris web components migration/parity gap since inlineSize would be the cleaner replacement for the old full-width button behaviour.

For the modal piece, happy to raise that too. Just to clarify, you essentially want there to be the ability to have a pop up or something like that to display confirmation prompts/warnings in a modal?

For now, I agree that the separate screen/page approach is still the most reliable workaround, but I’ll pass these examples along on our end. I can’t promise a timeline, but I’ll keep this thread updated if I get more concrete info.