-
Notifications
You must be signed in to change notification settings - Fork 365
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-5181] - React Query for Events #9949
refactor: [M3-5181] - React Query for Events #9949
Conversation
Coverage Report: ✅ |
: intervalMultiplier * INTERVAL, | ||
resetEventsPolling: () => queryClient.setQueryData<number>(queryKey, 1), | ||
}; | ||
}; |
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 tl;dr of this hook is that it globally keeps track of a single number (the polling interval) and exposes operations like resetting and incrementing.
It's a little bit convoluted (hacky even) using the RQ store to store this value globally (another alternative would be to use Context, or the package you mentioned). The reason I chose to do it this way was to keep the polling hook and the polling interval hook tightly coupled (e.g., resetting one would reset the other).
In the original incarnation of RQ Events this hook was necessary since multiple polling hooks were mounted and they all needed to be synchronized. Now that we only have one instance of the polling hook, it may no longer be necessary. It may be possible to have the single polling hook maintain its interval using useState
.
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.
@@ -69,7 +69,6 @@ | |||
"redux": "^4.0.4", | |||
"redux-thunk": "^2.3.0", | |||
"reselect": "^4.0.0", | |||
"rxjs": "^5.5.6", |
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.
Glad we can still remove this 🎉
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.
Me too 😮💨
packages/manager/src/GoTo.tsx
Outdated
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.
Changes here aren't directly related to the ticket; should we move them to another PR?
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.
Yeah, I probably should have done that. I chose to move some state around to reduce the number of renders caused by state changes in App.tsx
. I think the change is pretty safe so I'm okay with leaving it if everyone else is
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.
Noice 🤩
export const linodeEventsHandler = ({ | ||
event, | ||
queryClient, | ||
}: EventHandlerData) => { | ||
const linodeId = event.entity?.id; | ||
|
||
// Early return to cut down the number of invalidations. |
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 early return on lines 26-28 cuts down on a lot of repeated invalidations but has the negative consequence that Linodes may not reflect their current status accurately. For example, if a Linode is rebooted from another tab, it will still show as "Running".
It's not a major issue but might be worth discussing/capturing in separate ticket.
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.
Yeah, good point. Probably out of scope because it's Linode specific, but we definitely could improve the Linode event handlers in general. I'm making myself a note to revisit this later down the road.
@@ -14,18 +14,14 @@ import { getLinkForEvent } from 'src/utilities/getEventsActionLink'; | |||
|
|||
import { StyledGravatar } from './EventRow.styles'; | |||
|
|||
interface ExtendedEvent extends Event { | |||
_deleted?: string; |
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.
Was this property unused?
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.
Yes, it was unused. I'm not 100% sure but I think it was used way way in the past to determine if the event's entity was deleted for purposes of removing links that would lead to 404s in event messages. It would be good UX to bring this back somehow, but I can't think of a very efficient way to do it.
data-testid="linode-events-table" | ||
emptyMessage="No recent activity for this Linode." | ||
entityId={id} | ||
errorMessage="There was an error retrieving activity for this Linode." |
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.
Do we want to drop this error message?
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 think I removed it because I chose to surface the API error directly for more transparency. Do you think we should stick with this more friendly error? I'm sure it's a rare occurrence
@@ -366,6 +366,7 @@ const formatNotificationForDisplay = ( | |||
): NotificationItem => ({ | |||
body: <RenderNotification notification={notification} onClose={onClose} />, | |||
countInTotal: shouldIncludeInCount, | |||
eventId: -1, |
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.
Not sure if I fully understand why this was not needed before
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.
Not directly related to this PR, but I noticed we're missing event handlers for Kubernetes and now, VPC
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.
Good call. I can make a ticket for LKE.
@dwiley-akamai Should we make one for VPC?
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'll create a ticket to investigate whether a handler is needed. My initial thought is due to the nature of the VPC events it probably isn't, but it warrants a closer look.
edit: created M3-7649
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.
Re-approving since first approval didn't 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.
Great work @bnussman 🎉
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 a huge achievement, thanks @bnussman-akamai! Especially appreciate the thorough docs and comments, as well as the new test coverage
Co-authored-by: jdamore-linode <97627410+jdamore-linode@users.noreply.github.com>
Description 📝
useEventsInfiniteQuery
was mounted many times, which also mounted the cache updating code many times, which caused many renders to happen when event were polled. This PR fixed that by only mounting a polling hook that update the cache once.Main Additions
useEventsPoller
⏲️volume_delete
for example)volumeEventsHandler
for example)useInProgressEvents
📇LinodeRow
for exampleuseEventsInfiniteQuery
📃EventsLanding
,LinodeActivity
, and the Event MenuOther mentions
rxjs
dependency 🎉How to test 🧪
http://localhost:3000/events
pagepackages/manager/src/queries/events.ts
and look for any issues, mistakes, or 🚩As an Author I have considered 🤔