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

Add NotificationContext and useNotification hook #524

Merged
merged 1 commit into from
Nov 7, 2024

Conversation

Griffin-Sullivan
Copy link
Contributor

@Griffin-Sullivan Griffin-Sullivan commented Oct 28, 2024

Description

This PR adds a new global context for Notifications. I also added a useNotification hook to allow for easier dispatching by calling the specific method you want to use notification.success or notification.error. I also looped in the removal of notifications into this hook. You can call it like:

notifications = useNotification() // returns state for notifications
...
notifications.remove(notification.id)

image

  • I still not have tested restoring an archived version yet since I can't do it in mocked mode

There are a couple known issues at the moment:

  1. The id count gets reset to 0 whenever you change pages meaning if you switch pages quickly and get another notification they will have the same id
  2. The notification exit button looks out of place (I think it should be center aligned not in the top right corner)

How Has This Been Tested?

Merge criteria:

  • All the commits have been signed-off (To pass the DCO check)
  • The commits have meaningful messages; the author will squash them after approval or in case of manual merges will ask to merge with squash.
  • Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
  • The developer has manually tested the changes and verified that the changes work.
  • Code changes follow the kubeflow contribution guidelines.

If you have UI changes

  • The developer has added tests or explained why testing cannot be added.
  • Included any necessary screenshots or gifs if it was a UI change.
  • Verify that UI/UX changes conform the UX guidelines for Kubeflow.

Comment on lines 21 to 23
interface NotificationFunc extends NotificationTypeFunc {
remove: NotificationRemoveProps
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a little hacky. Maybe we should just have a separate hook for when we want to return all notifications and do something with them like removing one.

import { NotificationContext } from '~/app/context/NotificationContext';

const ToastNotifications: React.FC = () => {
const [notifications] = useContext(NotificationContext);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current hook only gives access to notification actions. Should we expand it to also return the notifications list? This is why I'm using useContext here.

Copy link
Contributor

@lucferbux lucferbux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tested it yet, but did a quick review, we can take a deeper look later today if you want.

@Griffin-Sullivan Griffin-Sullivan force-pushed the notifications branch 2 times, most recently from 0936ef9 to 61fd6aa Compare October 29, 2024 17:39
@Griffin-Sullivan
Copy link
Contributor Author

Ok @lucferbux addressed your comments thanks!

@Griffin-Sullivan
Copy link
Contributor Author

Ok with the newest push I have added a bunch of testing which includes some for checking the notification pops up correctly.

@@ -0,0 +1,7 @@
export class Notification {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should rename ToastNotification?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we are not using Notification, we might even refactor this in the future if this is not part of the project but reusable code, we'll see

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, just rename it and we can call it a day

modelVersionId: 2,
},
},
mockBFFResponse(mockModelVersion({})),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notice how we have to put a bunch of mockBFFResponse everywhere. We should figure out a way for all of our mockObject calls to inherently know about the BFF response so we don't have to be so explicit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great point, my first guess is to just modifify the mock objects and add a wrapper there, can you open a ticket in enhancemets to cover this?

Copy link
Contributor

@lucferbux lucferbux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks great, just a couple of nits, really great work here!

@@ -0,0 +1,7 @@
export class Notification {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we are not using Notification, we might even refactor this in the future if this is not part of the project but reusable code, we'll see

@@ -0,0 +1,7 @@
export class Notification {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment, just rename it and we can call it a day

modelVersionId: 2,
},
},
mockBFFResponse(mockModelVersion({})),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great point, my first guess is to just modifify the mock objects and add a wrapper there, can you open a ticket in enhancemets to cover this?

Comment on lines 4 to 27
export type Notification = {
id?: number;
status: AlertVariant;
title: string;
message?: React.ReactNode;
hidden?: boolean;
read?: boolean;
timestamp: Date;
};

export enum NotificationActionTypes {
ADD_NOTIFICATION = 'add_notification',
DELETE_NOTIFICATION = 'delete_notification',
}

type NotificationAction =
| {
type: NotificationActionTypes.ADD_NOTIFICATION;
payload: Notification;
}
| {
type: NotificationActionTypes.DELETE_NOTIFICATION;
payload: { id: Notification['id'] };
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move this to the types.ts file under app?

Comment on lines 4 to 27

enum NotificationTypes {
SUCCESS = 'success',
ERROR = 'error',
INFO = 'info',
WARNING = 'warning',
}

type NotificationProps = (title: string, message?: React.ReactNode) => void;

type NotificationRemoveProps = (id: number | undefined) => void;

type NotificationTypeFunc = {
[key in NotificationTypes]: NotificationProps;
};

interface NotificationFunc extends NotificationTypeFunc {
remove: NotificationRemoveProps;
}

export const useNotification = (): NotificationFunc => {
const { dispatch } = useContext(NotificationContext);
// need to move this count somewhere else since it will reset on every new useNotification instance (like switching pages)
let notificationCount = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you move the notification count to the context itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't I......

@ederign
Copy link
Member

ederign commented Nov 7, 2024

/lgtm

Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ederign, lucferbux

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@google-oss-prow google-oss-prow bot merged commit 962d135 into kubeflow:main Nov 7, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants