refactor: [M3-7397] - Clean up App.tsx#9897
Conversation
| }; | ||
| }, [handleMigrationEvent]); | ||
| useAdobeAnalytics(); | ||
| useNewRelic(); |
There was a problem hiding this comment.
It feels kind of wrong to have hooks that don't return anything, but I think it accomplishes what we need.
In fact, useNewRelic probably doesn't even need to be a hook, but for the sake of not making a breaking change, I made it one for now.
| const toasts: Toasts = { | ||
| backups_restore: { | ||
| failure: (e) => `Backup restoration failed for ${getLabel(e)}.`, | ||
| link: formatLink( | ||
| 'Learn more about limits and considerations.', | ||
| 'https://www.linode.com/docs/products/storage/backups/#limits-and-considerations' | ||
| ), | ||
| persistFailureMessage: true, | ||
| }, |
There was a problem hiding this comment.
I rewrote ToastNotifications.tsx to be cleaner and more extendable. The messages, links, and stuff are all the same.
abailly-akamai
left a comment
There was a problem hiding this comment.
Great cleanup! Nice to see those entry points getting some love 👍
Left a few comments for clarification and/or cleanup
| } | ||
| }) | ||
| .catch(() => { | ||
| // Do nothing; a user may have analytics script requests blocked. |
There was a problem hiding this comment.
Am wondering if anyone would care to see events for that.
There was a problem hiding this comment.
Not sure. I personally don't mind the silent failure
There was a problem hiding this comment.
Silent for the user for sure. Just wondering about collecting this info on our end so we have a better idea of the sample for those events but it would be a product decision and I doubt anyone would be interested 🤷
There was a problem hiding this comment.
We could capture a sentry exception, but I worry we'd just flood sentry with useless messages. I have a feeling lots of browsers with privacy features enabled will block Adobe Analytics
There was a problem hiding this comment.
^^ Yes, that was the problem before, though I think the error handling was at a slightly different spot in the code at the time. We don't want to flood Sentry, and before we were creating a new Sentry alert for every user and every event they clicked where analytics were disabled. Where the catch is now, I think we'd just be triggering sentry alerts for every user blocking extensions every time they load the app (rather than every time they fire a trackable event), but that's still a lot.
| filter: ({ event }) => event.action.startsWith('disk') && !event._initial, | ||
| handler: diskEventHandler, | ||
| }, | ||
| ]; |
There was a problem hiding this comment.
This does not seem to be a 1/1 with the legacy code. Can you explain what happened to the linode_migrate events? They were previously a dependency for the hook below.
There was a problem hiding this comment.
handleMigrationEvent was duplicated logic that also was in ToastNotifications. It now lives in useToastNotifications where it belongs
| export const getLabel = (event: Event) => event.entity?.label ?? ''; | ||
| export const getSecondaryLabel = (event: Event) => | ||
| event.secondary_entity?.label ?? ''; | ||
| const formatLink = (text: string, link: string, handleClick?: any) => { |
There was a problem hiding this comment.
can we type this better? also, we are not testing any hooks in the codebase, so in general return types would be nice to have in those new hooks.
There was a problem hiding this comment.
Oops, didn't see the any when I copied this code over!
There was a problem hiding this comment.
I made the hooks explicitly return null. I don't see too much value in adding an explicit return type to the function signatures. Do you think it makes sense to be explicit here?
There was a problem hiding this comment.
Ugh was commenting with my personal GH account. Yeah, agreed - not much value. I'll give it more thoughts!
|
abailly-akamai
left a comment
There was a problem hiding this comment.
Second pass: everything seems stable when testing in the browser. Tested a bunch of actions and notifications came through as expected. No regression spotted ✅
| */ | ||
| const toasts: Toasts = { | ||
| backups_restore: { | ||
| failure: (e) => `Backup restoration failed for ${getLabel(e)}.`, |
There was a problem hiding this comment.
Very small nitpick: should we end notifications with a period. For the toast notifications ive added, they have just been a statement without a period, but I can update them.
There was a problem hiding this comment.
I'm gonna leave the periods but put an item on a cafe agenda. It seems pretty inconstant throughout the app when I search for instances of enqueueSnackbar
Description 📝
App.tsxhas gotten very messy and generally hard to consume. This PR cleans upApp.tsxand related pieces. Most changes are just moving code. The largest refactoring happens inuseToastNotifications.Changes 🔄
ToastNotificationsand makes ituseToastNotifications(inspired by refactor: [M3-5181] - RQ-ify Events #9416)useAdobeAnalytics,useNewRelic,useEventHandlers, anduseGlobalKeyboardListenerto separate out logicHow to test 🧪
Verification steps
Control+Shift+Dstill workAs an Author I have considered 🤔