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

refactor: M3-7034 - Event Messages Part 2 #10550

Merged
merged 16 commits into from
Jun 14, 2024

Conversation

abailly-akamai
Copy link
Contributor

@abailly-akamai abailly-akamai commented Jun 5, 2024

Description 📝

Part 2 of the Event Messages refactor. This PR addresses primarily:

  • Progress events
  • Code cleanup
  • UI updates

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 🔄

  • Improve and optimize progress event logic
  • Implement v2 versions of hooks and components (in order for the feature to remain behind a feature flag)
  • Implement CDS guidelined (UX approved ) UI changes
    • notification pill color
    • if more than 9 unread notifications, show 9+
    • new progress pill icon
    • unseen notification border
    • relative time, time remaining copy
  • Close Notification Center when clicking on "View all events" since we land on the event page (UX approved as well)

💡 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
Screenshot 2024-06-10 at 09 33 07

Notification Center
Screenshot 2024-06-10 at 17 52 18

Event Bell Notification
Screenshot 2024-06-10 at 17 09 16

How to test 🧪

Verification steps

(How to verify changes)

  • Checkout PR and make sure the eventMessagesV2 is turned on
  • Check the of both the event page and the notification for a variety of progress events (boot, reboot, resize, migrate, clone etc)

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

Copy link
Contributor Author

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}
/>
)}
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 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>
Copy link
Contributor Author

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;
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 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',
];
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 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.

.
</>
);
};
Copy link
Contributor Author

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,
};
};
Copy link
Contributor Author

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
);
}

Copy link
Contributor Author

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

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 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.

@abailly-akamai abailly-akamai marked this pull request as ready for review June 11, 2024 01:27
@abailly-akamai abailly-akamai requested a review from a team as a code owner June 11, 2024 01:27
@abailly-akamai abailly-akamai requested review from hkhalil-akamai, jaalah-akamai and bnussman-akamai and removed request for a team June 11, 2024 01:27
Copy link

github-actions bot commented Jun 11, 2024

Coverage Report:
Base Coverage: 82.75%
Current Coverage: 82.8%

Copy link
Contributor

@hkhalil-akamai hkhalil-akamai left a 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!

)}
</IconButton>
</TopMenuTooltip>
<Popover
Copy link
Contributor

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

Copy link
Contributor Author

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.

Screenshot 2024-06-12 at 12 05 05

if (prevOpen && !notificationContext.menuOpen) {
// Dismiss seen notifications after the menu has closed.
if (eventNotifications.length > 0) {
markEventsAsSeen(eventNotifications[0].eventId);
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Member

@bnussman-akamai bnussman-akamai left a 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/Events/constants.ts Outdated Show resolved Hide resolved
packages/manager/src/features/Events/factories/linode.tsx Outdated Show resolved Hide resolved
Copy link
Member

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

Copy link
Contributor Author

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

Copy link
Contributor

@jaalah-akamai jaalah-akamai left a 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

docs/development-guide/15-api-events.md Outdated Show resolved Hide resolved
docs/development-guide/15-api-events.md Outdated Show resolved Hide resolved
docs/development-guide/15-api-events.md Outdated Show resolved Hide resolved
packages/manager/src/features/Events/utils.tsx Outdated Show resolved Hide resolved
packages/manager/src/features/Events/utils.tsx Outdated Show resolved Hide resolved
packages/manager/src/features/Events/utils.tsx Outdated Show resolved Hide resolved
@abailly-akamai abailly-akamai merged commit 6ab8240 into linode:develop Jun 14, 2024
18 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.

4 participants