The ui-save-bar documentation has gone

App Bridge
,
23

Hi @TobiasDalhof,

For handling discard confirmation, there’s an example here:

For loading/disabled button states, thanks for flagging that’s missing from the docs. I’ll look into adding an example for that.

24

Thank you for updating the docs @Paige-Shopify .

But this also comes back to my original question. Can you please confirm that the UI custom components, (e.g. <ui-save-bar> and <ui-modal>) are safe to be using and we won’t be forced away from them in the near future?

In a previous message you said that “<ui-save-bar> is still a legitimate way to work with the API for now, but we encourage you to adopt the new approach using the data-save-bar attribute.”

Plus, It looks like all of the documentation for these components are gone. It would be nice to know what options and parameters we have with those components if they are legitimate.

25

Hi @Station_Team, sorry for the delayed reply.

Both <ui-save-bar> and <ui-modal> are still supported and won’t be removed in the near future. I’ll look into getting documentation for both components back up.

While I have you, are there any gaps in the newer components that would prevent you from adopting them? We have <s-modal> and <s-app-window> as alternatives, and I want to make sure they cover your use cases.

26

Hi @Paige-Shopify,

Yes, there are definitely gaps in the newer components that are preventing us from adopting them.

For modals specifically, <ui-modal> is necessary any time there isn’t a one to one user click from a Polaris Web Component that allows a commandFor attribute. This includes any case where the modal should be shown conditionally in a user flow. Here are a few blockers we’ve run into, but I’m sure there are hundreds of other cases.

  • We use a modal for code editing that needs to be opened/triggered from a rich text editor (with custom buttons). For what it’s worth, text inputs seem to be broken in <ui-modal> and we have had to add custom input event listeners for the text area.
  • Opening modals seem to not work from links in action drop-downs.
  • We are using a modal as a custom discard confirmation from the <ui-save-bar> which doesn’t use <s-button>.
  • In one case we have to show a modal as part of a save confirmation which means opening it conditionally from the onSubmit handler.
  • Changing the command or commandFor attributes declaratively causes focus issues in <s-text-area> components (the last textarea can’t be focused because every time it’s clicked focus is sent to the modal or button. I’m not sure which). We’re using <ui-modal> with conditional open as a workaround.
  • Whenever a redirect happens as part of the action, opening the modal programmatically is required. We aren’t doing this anymore, but we used to show a modal explaining what had changed when a user was redirected back to the app after downgrade.

I hope that helps.

While I understand the goal is to just make everything happen automatically, in the real world it is really valuable for developers to be able to have programmatic control over these components.

Let me know if I can supply any other info.

27

@Station_Team Wow, really appreciate the time you took to put this feedback together. Thank you!

28

You’re very welcome @Paige-Shopify. Happy to help!