Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract "Subtle Notification" styling/logic to a shared SubtleNotification component #8725

Open
8 tasks
tofumatt opened this issue May 16, 2024 · 4 comments
Open
8 tasks
Labels
P2 Low priority Type: Infrastructure Engineering infrastructure & tooling

Comments

@tofumatt
Copy link
Collaborator

tofumatt commented May 16, 2024

Feature Description

We intentionally did not create a "Subtle Notification" component for the new styles of component rendered by components like https://github.com/google/site-kit-wp/blob/f5a89cf2cd5978ee012308281a2840e03192b2c4/assets/js/components/notifications/GA4AdSenseLinkedNotification.js

But now that we have a few of these "Subtle Notifications", we can see how they're used in real-world scenarios and should be able to extract the logic for them into a common, shared component (eg. SubtleNotification) that all existing notifications should move to using and new notifications can use.


Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

  • A new component for subtle notifications, eg. SubtleNotification should be created that implements the subtle notification components, with the ability to provide a header, text, and CTA actions, eg:

Screenshot 2024-05-27 at 23 10 14

  • Existing "subtle notification" components, eg. GA4AdSenseLinkedNotification, SetupSuccessSubtleNotification, and AudienceSegmentationSetupSuccessSubtleNotification, should be used to extract this new component. They should then be converted to use <SubtleNotification> instead of the existing approach.

Implementation Brief

  • Create a new component assets/js/modules/analytics-4/components/SubtleNotification.js, that has the following props:
    • title (string): Title passed through the __ function.
    • description (ReactNode): Description passed as an element to enable DOM elements such as links in the description in future.
    • onDismiss (function): Function to call to dismiss the notification.
    • additionalCTA (ReactNode|false): An optional CTA component (used for assets/js/modules/analytics-4/components/audience-segmentation/dashboard/AudienceSegmentationSetupSuccessSubtleNotification.js to show the "Show me" CTA)
    • Copy the DOM from the return statement of assets/js/modules/analytics-4/components/audience-segmentation/dashboard/AudienceSegmentationSetupSuccessSubtleNotification.js, replacing the title, description, dismiss function and additional CTA components with the values passed from the props.
  • Update each existing subtle notification, <AudienceSegmentationSetupSuccessSubtleNotification />, <GA4AdSenseLinkedNotification />, <SetupSuccessSubtleNotification /> and <PAXSetupSuccessSubtleNotification /> to use the new assets/js/modules/analytics-4/components/SubtleNotification.js instead of duplicating the DOM.
  • Keep the render logic in each existing notification component as this logic varies between each of these components.

Test Coverage

  • Create a new SubtleBanner story and VRT.

QA Brief

Changelog entry

@tofumatt tofumatt added P2 Low priority Type: Infrastructure Engineering infrastructure & tooling labels May 16, 2024
@tofumatt tofumatt self-assigned this May 16, 2024
@tofumatt tofumatt removed their assignment May 27, 2024
@benbowler benbowler assigned benbowler and tofumatt and unassigned benbowler May 28, 2024
@benbowler
Copy link
Collaborator

@tofumatt here's my first pass on the IB. We could simplify this further by also bringing the dismiss logic into the new SubtleNotification component and give it a slug. Assuming we're happy to unify event tracking.


Taking it further we could bring the render logic into the component also, but I don't see much of a benefit here as some notification render logic is more complex than others so we'd need to pass it as a boolean prop from the parent componet. I believe it's cleaner to have this logic in a component within the module it relates to and to return null here instead of rendering the component.

// Ensure resolution of the report has completed before showing this
// notification, since it should only appear when the user has no data in
// the report.
const shouldShowNotification =
// Only show this notification on the main/entity dashboard, not on the
// settings page, etc.
dashboardType &&
// Don't show this notification on the view-only dashboard.
! viewOnly &&
// Don't show this notification if `isDismissed` call is still loading
// or the user has dismissed it.
! isDismissed &&
hasFinishedResolution &&
isZeroReport( report ) &&
analyticsAndAdsenseConnectedAndLinked;

@tofumatt
Copy link
Collaborator Author

@benbowler To future-proof this one a bit, I think at least the description prop should expect a React Node rather than a string. It's minor, but probably better to specify that now. I could imagine a world where there's a "Learn more" link or "Get help" link in there alongside 1-2 CTA buttons (that tend to dismiss the notification), so better to budget for at least a more flexible description prop now.

I agree about keeping the logic to display the notification inside each component rather than it being passed as a prop. It's more awkward that way 👍🏻


Re: your idea about unifying the dismiss logic: I think it seems to make sense to consolidate that dismissal into the component, but in reality it's just one line. 🤔

Given the components themselves will already be checking that slug to see if it is dismissed to know whether they should render the notification, it probably makes sense to just let each component render as many CTA buttons at they like.

Plus, the logic to dismiss each notification isn't even totally consistent in the plugin right now. The PAX one just unsets a query arg:

I think passing onDismiss and then the: additionalCTA as an extra prop makes sense. Given it just needs to be a <Button onClick={}>Text</Button> component, as the notification itself styles the button to look correct in there, I think that's the smart approach, nice 👍🏻


If you're cool with description being a React Node instead of string I'm cool with this approach, it's simple and easy-to-use 🙂

@tofumatt tofumatt assigned benbowler and unassigned tofumatt May 28, 2024
@benbowler
Copy link
Collaborator

Thanks @tofumatt updated.

@tofumatt
Copy link
Collaborator Author

Awesome, thanks!

IB ✅

@tofumatt tofumatt removed their assignment May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 Low priority Type: Infrastructure Engineering infrastructure & tooling
Projects
None yet
Development

No branches or pull requests

2 participants