Use a custom event to communicate the status of a specific process.
You can use a custom window event that the federated component sends to communicate the status of a specific process. This event helps the host application understand the result of operations handled by the component. You can use the event to trigger UI changes, update logs, or perform other actions based on the process status.
Make sure your host application is properly set up to listen for window events.
mistStatus
mistStatus
is a generic custom window event that you can use to track various processes in the InStore product modules.mistStatus event details
The
mistStatus
event includes the following properties in its detail
object:-
process
(String): specifies the process that triggered the event. The value can be one of the following:checkout
refund
deviceregistration
cashmanagement
-
status
(String): indicates the outcome of the process. The value can be one of the following:success
: the process completed successfully.cancelled
: the process was cancelled by the user or system.error
: an error occurred during the process.activated
: the process was successfully activated.
-
message
(String): a description of the error, only present when thestatus
iserror
. This property provides additional context about the failure. Usetry...catch
blocks, where necessary, to handle potential errors when processing event details.
inStoreCore-Alert
inStoreCore-Alert
is a custom window event that can trigger responses based on process steps that occur in the InStore colleague app; for example, to display toast messages. This event is available for use in modular_store
.inStoreCore-Alert event details
The
inStoreCore-Alert
event includes the following properties in its detail
object:-
message
(String): specifies text to be displayed if the event is triggered. This is any localized string that the retailer specifies. For example, "Connected to card processor," "Requesting user input," and "Authorizing card." Sample base messages are stored in InStore language bundles, or you can pull strings from an external source. -
properties
: unsupported. -
severity
(String): indicates the outcome of the process. Its value can be any one of the following:success
: the process completed successfully.info
: information is provided about the process.warning
: the process completed with a warning.error
: an error occurred during the process.
inStoreCore-receiptChoice
inStoreCore-receiptChoice
is a custom window event that can generate a receipt by using the method that a user selected in the InStore colleague app. The methods are activated in the InStore colleague app by using any one of the following items:Receipt_Print_Options
administration parameter- API override of the administration parameter
inStoreCore-receiptChoice event details
The
inStoreCore-receiptChoice
event includes the following properties in its detail
object:-
choice
(list): specifies the receipt delivery methods requested by a user. This is an array that can contain a maximum of four strings, which can be any of the following values:Paper
: the receipt is intended for the printer that is assigned to the current workstation.Email
: the receipt is intended for the email address contained in the cart.Text
: the receipt is intended for the text number contained in the cart.None
: no receipt is generated. This option overrides any other option(s) selected.
inStoreCore-screenChange
inStoreCore-screenChange
is a custom window event that can record a user's path through the colleague app.inStoreCore-screenChange event details
The
inStoreCore-screenChange
event includes the following properties in its detail
object:screen
(String): activates a listing of the pages that the user has traversed. For more information, see the list of pages.
Pages tracked by the inStoreCore-screenChange event
You can set up a listener for the
inStoreCore-screenChange
event to track user navigation through the following pages of the InStore colleague app:Payments
- CancelPayment
- CashCollection
- CashDrawerPrompt
- ChangeDue
- CreditProcessing
- Exit
- GiftCardEntry
- GiftCardProcessing
- PaymentEntry
- POAConfirmation
- PayByLinkEntry
- PayByLinkProcessing
- ReceiptSelection
- SelectTestCard
- SignatureVerification
- WalletCodeEntry
- WalletProcessing
Refunds
- CashDrawerPrompt
- CancelRefund
- Exit
- RefundCash
- RefundCredit
- RefundOptions
- RefundPOA
- RefundReceipt
- RefundVoucher
- RefundWallet
Device Management
- DeviceDefinition
- DeviceList
- EditDevice
- Exit
Cash Management
- BankDeposit
- CashAudit
- CashCount
- ConfirmTransfer
- CountAcceptance
- DrawerSelection
- Exit
- ModifyTransfer
- OpenDrawer
- PayIn
- PayOut
- RejectTransfer
- RejectTransferFinish
- ReserveInstructions
- SafeDeposit
- TransferAmount
- TransferIn
- TransferOut
Example usage
You can use the following convention to listen for and handle custom InStore events in your host application. The
mistStatus
event is shown as an example:window.addEventListener('mistStatus', (event) => {
const { process, status, message } = event.detail;
switch (status) {
case 'success':
console.log(`Process ${process} completed successfully.`);
break;
case 'cancelled':
console.log(`Process ${process} was cancelled.`);
break;
case 'error':
console.error(`Process ${process} failed: ${message}`);
break;
case 'activated':
console.log(`Process ${process} was activated.`);
break;
default:
console.log(`Unknown status: ${status}`);
}
});