Telefonica/webview-bridge

Add support for the `destructive` flag in native `confirm` dialog

carlosgarciaibanez opened this issue · 5 comments

carlosgarciaibanez commented

For the Session management functionality we will use a confirmation dialog to delete the sessions selected by the user. This dialog is based on the Mistica's Confirm component. This components admits a destructive flag that is used to tell the component that the primary action implies "destruction" of entities and thus should be displayed in a special way.

The web version of the component shows the primary button with a red color, like this:
image

However, when used on a device by means of the webview bridge, the destructive semantics are lost because the flag is ignored:
image

Instead, we would expect the dialog to be displayed like this on iOS (when invoked with the destructive flag):
image

The general behavior of the component should not change, only its appearance when the flag is set to true.

atabel commented

Current status:

nativeConfirm: ({
    message: string;
    title?: string;
    acceptText: string;
    cancelText: string;
}) => Promise<boolean>;

Proposed solution:

nativeConfirm: ({
    message: string;
    title?: string;
    acceptText: string;
    cancelText: string;
+    destructive?: boolean;
}) => Promise<boolean>;

destructive is false by default.

Retrocompatibility:

Old apps will ignore the new destructive attribute, so the destructive attribute won't have any effect. Newer apps will show the primary button (the one with the accept text) red when destructive is received as true.

  • 👍2
jeprubio commented

Which red colour should we use? Just pure red for all the brands? Or should we use colorError from the brand? @atabel

nimeacuerdo commented

Which red colour should we use? Just pure red for all the brands? Or should we use colorError from the brand? @atabel

solved?

  • 👍1
jeprubio commented

Which red colour should we use? Just pure red for all the brands? Or should we use colorError from the brand? @atabel

solved?

Yup, sorry, forgot the comment, it was discussed in design-appscore and it was decided to use textLinkDanger for this in the cases when it's not defined by the OS.

  • 👍1