Open zutigrm opened 2 months ago
AC ✔️
I am un-assigning myself since I have been caught up with higher priority epic issues, and will be on the PTO for few days. This notification will take a bit of a thinking it over, as it is potentially a group of notifications that are fetched from the backend, and current notifications API might need some tweaks to support this. The idea I had when initially had time to check this one, is that regular approach would potentially work, as we would register the notification in the API, and then checkRequirements
and notification component would handle the fetching and iteration over data. Something to consider was that isDismissable
is a fixed property included when notification is registered in the API, if the notifications coming from the backend are different in that regard, it won't render correctly, since isDismissable
would be applied to all with the same value either true
or false
I'm marking this blocked by #9294 as there is an ongoing discussion there regarding the module level createNotificationsStore
. This in an example of notifications that use this existing infrastructure so we need a unified spec/decision on how we want to approach this existing notifications store to bring it into the new store.
Feature Description
This issue should refactor the
AdSenseAlerts
so that it uses the new datastore infrastructure to register and queue the notification. It should also incorporate a new "layout".Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance criteria
AdSenseAlerts
component should be refactored so that it is registered and rendered (queued) using the newcore/notifications
datastore.BannerNotifications
) but only via the genericgetQueuedNotifications
selector.BannerNotification
component. Instead, it should be rendered using the newNotification
component wrapper and a simpler "layout" component that solely encapsulates its structure and design.Implementation Brief
Test Coverage
QA Brief
Changelog entry