An Alert is a dialog that presents users with information or collects information from the user using inputs. An alert appears on top of the app's content, and must be manually dismissed by the user before they can resume interaction with the app. It can also optionally have a header, subHeader and message.
ion-alert can be used by writing the component directly in your template. This reduces the number of handlers you need to wire up in order to present the Alert.
The isOpen property on ion-alert allows developers to control the presentation state of the Alert from their application state. This means when isOpen is set to true the Alert will be presented, and when isOpen is set to false the Alert will be dismissed.
isOpen uses a one-way data binding, meaning it will not automatically be set to false when the Alert is dismissed. Developers should listen for the ionAlertDidDismiss or didDismiss event and set isOpen to false. The reason for this is it prevents the internals of ion-alert from being tightly coupled with the state of the application. With a one way data binding, the Alert only needs to concern itself with the boolean value that the reactive variable provides. With a two way data binding, the Alert needs to concern itself with both the boolean value as well as the existence of the reactive variable itself. This can lead to non-deterministic behaviors and make applications harder to debug.
In the array of buttons, each button includes properties for its text, and optionally a handler. If a handler returns false then the alert will not automatically be dismissed when the button is clicked. All buttons will show up in the order they have been added to the buttons array from left to right. Note: The right most button (the last one in the array) is the main button.
Optionally, a role property can be added to a button, such as cancel. If a cancel role is on one of the buttons, then if the alert is dismissed by tapping the backdrop, then it will fire the handler from the button with a cancel role.
Alerts can also include several different inputs whose data can be passed back to the app. Inputs can be used as a simple way to prompt users for information. Radios, checkboxes and text inputs are all accepted, but they cannot be mixed. For example, an alert could have all radio button inputs, or all checkbox inputs, but the same alert cannot mix radio and checkbox inputs. Do note however, different types of "text" inputs can be mixed, such as url, email, text, textarea etc. If you require a complex form UI which doesn't fit within the guidelines of an alert then we recommend building the form within a modal instead.
Alert uses scoped encapsulation, which means it will automatically scope its CSS by appending each of the styles with an additional class at runtime. Overriding scoped selectors in CSS requires a higher specificity selector.
We recommend passing a custom class to cssClass in the create method and using that to add custom styles to the host and inner elements. This property can also accept multiple classes separated by spaces.
/* DOES NOT WORK - not specific enough */ .alert-wrapper{ background:#e5e5e5; } /* Works - pass "my-custom-class" in cssClass to increase specificity */ .my-custom-class.alert-wrapper{ background:#e5e5e5; }
Any of the defined CSS Custom Properties can be used to style the Alert without needing to target individual elements:
.my-custom-class{ --background:#e5e5e5; }
note
If you are building an Ionic Angular app, the styles need to be added to a global stylesheet file.
Ionic automatically sets the Alert's role to either alertdialog if there are any inputs or buttons included, or alert if there are none.
If the header property is defined for the Alert, the aria-labelledby attribute will be automatically set to the header's ID. The subHeader element will be used as a fallback if header is not defined. Similarly, the aria-describedby attribute will be automatically set to the ID of the message element if that property is defined.
It is strongly recommended that your Alert have a message, as well as either a header or subHeader, in order to align with the ARIA spec. If you choose not to include a header or subHeader, an alternative is to provide a descriptive aria-label using the htmlAttributes property.
All ARIA attributes can be manually overwritten by defining custom values in the htmlAttributes property of the Alert.
The main message to be displayed in the alert. message can accept either plaintext or HTML as a string. To display characters normally reserved for HTML, they must be escaped. For example <Ionic> would become <Ionic>