-
Notifications
You must be signed in to change notification settings - Fork 361
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
refactor: M3-7034 - Event Messages Part 2 #10550
Conversation
fd6731e
to
a7a9e61
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiny change to the icon so it does not appear squished with the proper 1x1 ratio
sx={{ mb: 1, mt: 0.5 }} | ||
value={event.percent_complete ?? 0} | ||
/> | ||
)} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The progress bar was missing from the events page the whole - it's back in for consistency.
<Box alignItems="center" display="flex" gap={1}> | ||
<StyledGravatar username={username ?? ''} /> | ||
{username ?? 'Linode'} | ||
</Box> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avatar is now alongside the username in the same cell
@@ -33,7 +32,7 @@ export const EventsLanding = (props: Props) => { | |||
const { emptyMessage, entityId } = props; | |||
const flags = useFlags(); | |||
|
|||
const filter: Filter = { action: { '+neq': 'profile_update' } }; | |||
const filter = EVENT_POLLING_FILTER; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is so we not filter events API side rather than on the client. This is now consistent wherever events are fetched via useEventsInfiniteQuery
.
'image_upload', | ||
'volume_migrate', | ||
'database_resize', | ||
]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This replaces the switch at https://github.com/linode/manager/blob/develop/packages/manager/src/features/Events/eventMessageGenerator_CMR.tsx#L25-L91 since this PR is deprecating the legacy eventGenerator handler which was over-fetching and was hard to maintain.
We can now override messages at the factory level if we need to customize the message via additional queries. See events/factories/linode.tsx
right below for more details.
. | ||
</> | ||
); | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned, if we need to customize a message we can just declare a new component that can deal with fetching new data to compose the message. This way this is only called if the action/status happen in the UI. This is the biggest improvement in this PR. This cam be tested by triggering a Linode resize.
progressEventDisplay, | ||
showProgress, | ||
}; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consolidating functionality into utils to make things cleaner and reusable.
) : null | ||
); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved the v2 conditional rendering up the tree
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a big new file but it's pretty much a copy of NotificationMenu
with the exception of using the v2 hook and some styles changes. I did not really clean up this file or try to modernize it as to avoid functional regressions and keep the scope moderate.
Coverage Report: ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing work and improvements to the notification menu, events rendering and small UI tweaks like the in-progress bell indicator. Left some feedback and one curious bug but otherwise this looks great!
packages/manager/src/features/TopMenu/NotificationMenu/NotificationMenuV2.tsx
Outdated
Show resolved
Hide resolved
)} | ||
</IconButton> | ||
</TopMenuTooltip> | ||
<Popover |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a slight pre-existing flicker caused by the scroll bar disappearing when opening the notifications menu. It's not critical but it is annoying, maybe we can tackle it as part of this refactor?
Screen.Recording.2024-06-11.at.5.58.18.PM.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So i am not going to address this one in this PR cause it's a can of worms since it relates to both MUI's global handling of popovers the create menu is doing the same thing for example) and a user's system settings. What happens here is due to the overflow and padding set on the body by MUI). Not that this shouldn't be looked at, but out of scope for this ticket (will make a follow up one).
As an aside, you can use "When Scrolling" in your system settings cause the experience is better and this problem will go away.
if (prevOpen && !notificationContext.menuOpen) { | ||
// Dismiss seen notifications after the menu has closed. | ||
if (eventNotifications.length > 0) { | ||
markEventsAsSeen(eventNotifications[0].eventId); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While testing I did notice a bug with some older events not being marked as seen when opening/closing the menu but I can't replicate it anymore and this code is identical to what we already have so I'm not sure why it would be happening. Still, I will keep an eye on the unread count.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait I'm seeing it again but I have no idea why... maybe this is an API issue?
Screen.Recording.2024-06-11.at.6.04.01.PM.mov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have noticed that as well (seldomly) and was able to reproduce in production when /seen request don't seem to resolve the next event request. Strangely, triggering a new event and new notifications seem to "unblock" the faulty behavior and clearing old events. I'll keep an eye on it and perhaps open an ARB ticket to look at this if this happens a lot more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is looking good so far 😎 will revisit tomorrow
packages/manager/src/features/NotificationCenter/NotificationData/RenderEventV2.tsx
Outdated
Show resolved
Hide resolved
packages/manager/src/features/NotificationCenter/NotificationData/RenderEventV2.tsx
Outdated
Show resolved
Hide resolved
packages/manager/src/features/NotificationCenter/NotificationData/RenderEventV2.tsx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is more of a rant about previous code, not about your great work here 😅 :
I feel like there is way more code than necessary needed to render the NotificationMenu in general. There are so many layers to this Menu like NotificationSection
, useEventNotifications
, FormattedEventForDisplay
, and so on. I know most of this is carry over/copy paste from the old system, but I hope we can trim things down and un-abstact some in the future.
I might be mistaken and all of those abstractions are what we want, but I can't help but want to try to make it less convoluted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! once I clean up all the old files I will see a bit more clearly and consolidate this. This is on my list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great job @abailly-akamai - Love the new UI
Description 📝
Part 2 of the Event Messages refactor. This PR addresses primarily:
The aim of the PR is to deprecate
eventMessageGenerator_CMR
. The way it was always fetching Linode, Linode Types and Region data no matter what the event in order to hook some events and modify their message. With the new Event Messages factories we can now just build custom events as components and use them directly in factories actions so fetching is tightly to the action status.Changes 🔄
9+
💡 See the self review comments for more details
🗒️: the
time_remaining
value is inconsistently coming back from the API and being looked at. It should appear for a lot more progress events (ex, resize, migration) but is apparently currently broken. This is looked at in ARB-5127.🧪: This PR's unit test coverage is pretty basic since it will be followed by a full e2e suite dedicated to events
Preview 📷
Events Page
Notification Center
Event Bell Notification
How to test 🧪
Verification steps
(How to verify changes)
eventMessagesV2
is turned onAs an Author I have considered 🤔
Check all that apply