feat:[M3-8330] - Improve API flexibility for useToastNotification

[jaalah-akamai]

Description 📝

We need to enhance the API of this hook to increase its flexibility in handling event notifications. For example, we have a new event, tax_id_invalid. When this event is successful (indicating the tax ID is invalid), we want to display the error variant and ensure the notification persists. Currently, there's no way to easily inverse the toast variant depending on the event.

Changes 🔄

• Renamed persistFailureMessage to persist
• Added tax_id_invalid event which is feature flagged
• Added an invertVariant property to handle scenarios where a successful negative event should be represented as an error variant.
• Added new interface:

interface ToastMessage {
  link?: JSX.Element;
  message: ((event: Event) => string | undefined) | string;
  persist?: boolean;
}

Target release date 🗓️

7/22

How to test 🧪

Verification steps

(How to verify changes)

• Trigger any of the events listed in the hook
• Example: Create a volume and observe the multiple toasts that appear
• Manually add these properties to volume_create:

invertVariant: true,
persist: 'success',

• Observe the success should now be an error toast and it should be persisted.

As an Author I have considered 🤔

Check all that apply

• 👀 Doing a self review
• ❔ Our contribution guidelines
• 🤏 Splitting feature into small PRs
• ➕ Adding a changeset
• 🧪 Providing/Improving test coverage
• 🔐 Removing all sensitive information from the code and PR description
• 🚩 Using a feature flag to protect the release
• 👣 Providing comprehensive reproduction steps
• 📑 Providing or updating our documentation
• 🕛 Scheduling a pair reviewing session
• 📱 Providing mobile support
• ♿ Providing accessibility support

[github-actions]

Coverage Report: ✅
Base Coverage: 82.23%
Current Coverage: 82.26%

[jaalah-akamai]

@bnussman-akamai Good suggestions - let me know if there's anything else

[abailly-akamai]

Change makes sense! Confirming the toast status inversion ✅

will take this into consideration when getting to this refactor for the Events V2 epic

[abailly-akamai]

FWI this isn't going to remain as such when I get to this part of the event refactor. We are going to use event factories to display these messages to it's centralized and consistent.