refactor: [M3-6571] - RQ-ify Events - Part 2: Event Handlers

[hkhalil-akamai]

Description 📝

See Part 1 here: #9046.

This PR finishes off the RQ Events migration, moving all event handlers over from the old system (Redux middleware + rxjs observable) to a unified events "mega-hook".

The 2 hooks from the last PR are combined into a single hook useEventsInfiniteQuery, which handles both fetching events and allows for registering event handlers for new/updated events. It was necessary to combine the polling hook into this one because we use previously-fetched events to create a list of in-progress eventIds to poll for updates.

The event handlers themselves have been moved to two new hooks, useAppEventHandlers and useToastNotifications, from <App /> where most of them used to live (a few others were scattered around the codebase -- they are all now in one place). I decided to move them out of App to reduce clutter in that file; moving them to hooks instead of components seemed appropriate because they don't render any content.

This PR also introduces a container, withEventsInfiniteQuery that allows our class-based components to use events.

What exactly do Events do ❓

Events have a few different functions in Cloud Manager:

• Notify the user of ongoing/completed changes and updates to their account entities (Linodes, NodeBalancers, etc.)
  • These Event notifications are displayed in the Notification Menu and the Events Landing at /events.
  • Toast notifications appear when long running tasks complete (i.e., a Linode migration)
• Trigger event handlers that update locally cached data
  • E.g., when a Linode is updated in another tab, the Linodes cache is invalidated and Cloud Manager requests and displays the latest details without having to refresh the page
• Display the current status of an entity
  • E.g., when a Linode resize is in progress, this information, along with the progress will be displayed in the Linode details page

Major Changes 🔄

• Creates one RQ hook, useEventsInfiniteQuery, for retrieving events and registering event handlers
• Consolidate all event handlers to two new hooks, useAppEventHandlers and useToastNotifications
• Delete the Events Redux store and all associated files (reduces, actions, helpers, etc.)
• Remove rxjs as a dependency

How to test 🧪

1. Open two tabs of this version of the app.
2. Modify some entities in one tab and ensure those modifications are reflected in another tab (e.g., renaming/resizing/rebooting/deleting Linodes/NodeBalancers/Firewalls, etc.)
3. Perform an event that takes some time to complete and reports progress updates (e.g., resizing or migrating a Linode). Ensure both tabs receive and display updates as the event progresses and eventually completes.
4. Refresh in the middle of an in-progress event and ensure it continues to update until completion.
5. Perform some action that creates a toast notification (see useToastNotifications.tsx for examples of this, such as attaching a volume, resizing a disk, or migrating a Linode). Ensure this toast actually appears in both tabs.

Additional things to check:

• Ensure all event handlers in useAppEventHandlers are registered and invoked as expected
• Ensure all toast notifications in useToastNotifications work as expected
• Ensure the events polling interval (via resetPollingInterval) is correctly reset when adding/updating/deleting/performing actions on entities
• Ensure the NotificationMenu, EventsLanding and LinodeActivity components continue to display events as expected
• Ensure unit and E2E tests pass

[hkhalil-akamai]

1,500+ fewer LOC to maintain between Part 1 and Part 2! 🎉

[hkhalil-akamai]

We no longer need to associate the Redux store with the queryClient.

Why this was done before: event handlers used to be registered in the Redux store (via combineEventsMiddleware). Some of these handlers needed access to the queryClient (e.g., to invalidate queries when entities got updates).

Since event handlers are now handled through a hook, they can receive the queryClient using the useQueryClient hook.

[hkhalil-akamai]

Refactored this to be a hook since it doesn't render anything.

[hkhalil-akamai]

This was used to initiate the Redux-based events architecture. Now polling is automatically handled by the RQ hook.

[hkhalil-akamai]

resetEventsPolling is now exposed by the hook instead of being a global function.

[hkhalil-akamai]

There are 5 definitions of ExtendedLinode in the codebase -- combining these two since they are identical.

[hkhalil-akamai]

Migrated over from event.helpers.ts.

[hkhalil-akamai]

Noticing a couple of issues while testing:

Issue	Possible Resolution	Status
Events consumed by one tab are missed by another open tab due to the seen-based filtering used in polling	Filter based on created time instead of seen	✅
Multiple calls to /events API every polling cycle due to different polling filters	Use the same polling query and filter client-side	✅
EventsLanding re-downloads all loaded pages when new events are detected	Use 'page-zero' idea to add new events instead of reloading all events; or, reset page count after exiting EventsLanding	✅

[mjac0bs]

So I haven't looked through all 3000 lines of code, but I have tested functionality.

Notifications in two separate tabs seem to be updating across both tabs for seen/unseen and in progress events. In progress events update until completion with page refreshes. Toasts look good and are consistent across tabs.

The only thing I've noticed is that the Events Landing page seems to no longer display in progress events at the top of the list. In progress events are still displayed at the top of the notification menu, as expected.

Steps to replicate:

• Kick off a migration, since it takes some time to complete
• Perform some actions that will also trigger events while the migration is in progress
• Check the landings page and observe that the in-progress migration event is farther down the table than it is in prod, where it is at the top

Prod:

This branch:

[hkhalil-akamai]

Good eye @mjac0bs. Added sorting in-progress events to the top in EventsLanding to match NotificationMenu.

[bnussman-akamai]

PR is looking solid but I don't quite understand why the events load into the dom in batches less then 25... What am I not seeing in the code that causes this?

Screen.Recording.2023-07-17.at.9.50.45.AM.mov

[hkhalil-akamai]

PR is looking solid but I don't quite understand why the events load into the dom in batches less then 25... What am I not seeing in the code that causes this?

Screen.Recording.2023-07-17.at.9.50.45.AM.mov
@bnussman-akamai

Line 169 in EventsLanding.tsx filters out some events:

const filteredEvents = removeBlocklistedEvents(events, ['profile_update']);

[bnussman-akamai]

Great job 🎉 Not seeing any major issues!

So happy to see rxjs gone. Also impressed by the much needed clean up you were able to include in the PR (useToastNotifications, etc..)

I will do further testing when this is merged into the feature branch

[bnussman-akamai]

I think the whole idea of the toastSuccessAndFailure could be cleaned up. I think @hkhalil-akamai made some great clean up here but I think we can go further.

Rather than maintaining a switch statment, maybe we could have some kind of map?

        const toasts = {
          volume_attach: {
            eventStatus: event.status,
            failureMessage: `Error attaching Volume ${label}.`,
            successMessage: `Volume ${label} successfully attached.`,
          },
          volume_detach: {
            eventStatus: event.status,
            failureMessage: `Error detaching Volume ${label}.`,
            successMessage: `Volume ${label} successfully detached.`,
          },
        } as const;

        const toast = toasts[event.action as keyof typeof toasts];

        toastSuccessAndFailure({
          enqueueSnackbar,
          ...toast,
        });