feat: show toast when post is shared by user#4251
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
| setTimeout(() => { | ||
| hasShownToast.current = true; | ||
| displayToast( |
There was a problem hiding this comment.
I’m not really a fan of using setTimeout inside useEffect, but I think we should handle the case where a user lands on the page and then quickly navigates back to the home page.
I suggest adding a ref to store the timerId, then clearing the timer on unmount. We should also clear it if the userId changes to prevent issues when navigating between shared posts. Wdyt?
There was a problem hiding this comment.
+1 we have to clear timeout, it introduces memory leaks
There was a problem hiding this comment.
But toast already handles timeout internally why do you need another manual timeout?
There was a problem hiding this comment.
@rebelchris Because what I mentioned in the OP, for some reason if we pop the toast instantly it gets cleared immediately. I am assuming there's some state updates / mounting stuff going on. It's a bit of a hacky fix, but at the same time by delaying it just a little, it also ensures that the toast is visible when the user is looking at the page and it isnt shifting around.
There was a problem hiding this comment.
But you can pass a prop to keep it between page shifts, it's an option already
There was a problem hiding this comment.
Its not the issue, though. Its something else clearing it, and I haven't really figured out what 🤔
Removing the timeout works fine while the visiting user is logged in, but when the user is not, and the authbanner and all the other stuff pops in, it gets cleared early, even if I completely remove the eventlistener that is supposed to clear it early.
Here it is without timeout:
Screen.Recording.2025-05-08.at.21.59.15.mov
And here it is with 100ms timeout:
Screen.Recording.2025-05-08.at.21.58.22.mov
Not entirely sure what is causing this, but adding the small timeout and cleaning it up seems to solve the problem.
| setTimeout(() => { | ||
| hasShownToast.current = true; | ||
| displayToast( |
There was a problem hiding this comment.
But toast already handles timeout internally why do you need another manual timeout?
capJavert
left a comment
There was a problem hiding this comment.
Other then follow button it looks good.
Co-authored-by: Ante Barić <ante@kickass.website>
| interface UseToastNotification { | ||
| displayToast: (message: string, params?: NotifyOptionalProps) => void; | ||
| displayToast: ( | ||
| message: string | ReactNode, |
There was a problem hiding this comment.
ReactNode can be a string.
| message: string | ReactNode, | |
| message: ReactNode, |
|
|
||
| export interface ToastNotification { | ||
| message: string; | ||
| message: string | ReactNode; |
There was a problem hiding this comment.
| message: string | ReactNode; | |
| message: ReactNode; |
|
|
||
| const displayToast = ( | ||
| message: string, | ||
| message: string | ReactNode, |
There was a problem hiding this comment.
| message: string | ReactNode, | |
| message: ReactNode, |
Changes
TASK

DESIGN
SPEC
Not going to lie, I struggled a little bit with this one. The toast kept getting "wiped" due to state/cache updates and other weird stuff. Solve one scenario, two new ones pop up. 😭
I ended up wrapping it in a timeout to make sure the page has loaded most of its content before showing it. If any of you got any better suggestion as to how to make sure the toast does not get insta-wiped, feel free to make them.
Example:

Note that there's a bit more padding left to the avatar than there is on the design. It's because we have padding left + margin in our toast. I thought instead of creating unnecessary props or overriding, we just leave it be as is, and let design know. Let me know if this is disagreeable.
Events
Did you introduce any new tracking events?
Experiment
Did you introduce any new experiments?
Manual Testing
Caution
Please make sure existing components are not breaking/affected by this PR
Preview domain
https://mi-812.preview.app.daily.dev
Jira ticket
MI-812