refactor: [M3-5181] - React Query for Events#9949
refactor: [M3-5181] - React Query for Events#9949bnussman-akamai merged 54 commits intolinode:developfrom
Conversation
|
Coverage Report: ✅ |
| : intervalMultiplier * INTERVAL, | ||
| resetEventsPolling: () => queryClient.setQueryData<number>(queryKey, 1), | ||
| }; | ||
| }; |
There was a problem hiding this comment.
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.
| "redux": "^4.0.4", | ||
| "redux-thunk": "^2.3.0", | ||
| "reselect": "^4.0.0", | ||
| "rxjs": "^5.5.6", |
There was a problem hiding this comment.
Glad we can still remove this 🎉
There was a problem hiding this comment.
Changes here aren't directly related to the ticket; should we move them to another PR?
There was a problem hiding this comment.
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
| }: EventHandlerData) => { | ||
| const linodeId = event.entity?.id; | ||
|
|
||
| // Early return to cut down the number of invalidations. |
There was a problem hiding this comment.
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.
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.
| import { StyledGravatar } from './EventRow.styles'; | ||
|
|
||
| interface ExtendedEvent extends Event { | ||
| _deleted?: string; |
There was a problem hiding this comment.
Was this property unused?
There was a problem hiding this comment.
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.
Do we want to drop this error message?
There was a problem hiding this comment.
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
| ): NotificationItem => ({ | ||
| body: <RenderNotification notification={notification} onClose={onClose} />, | ||
| countInTotal: shouldIncludeInCount, | ||
| eventId: -1, |
There was a problem hiding this comment.
Not sure if I fully understand why this was not needed before
There was a problem hiding this comment.
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.
Good call. I can make a ticket for LKE.
@dwiley-akamai Should we make one for VPC?
There was a problem hiding this comment.
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
hkhalil-akamai
left a comment
There was a problem hiding this comment.
Re-approving since first approval didn't count
jaalah-akamai
left a comment
There was a problem hiding this comment.
Great work @bnussman 🎉
jdamore-linode
left a comment
There was a problem hiding this comment.
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 📝
useEventsInfiniteQuerywas 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_deletefor example)volumeEventsHandlerfor example)useInProgressEvents📇LinodeRowfor exampleuseEventsInfiniteQuery📃EventsLanding,LinodeActivity, and the Event MenuOther mentions
rxjsdependency 🎉How to test 🧪
http://localhost:3000/eventspagepackages/manager/src/queries/events.tsand look for any issues, mistakes, or 🚩As an Author I have considered 🤔