Skip to content
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

feat: notification modal opening logic #4132

Merged

Conversation

ilasw
Copy link
Contributor

@ilasw ilasw commented Jan 30, 2025

Changes

Requires dailydotdev/daily-api#2632

  • Cleaned coming soon experiment so context is not required anymore
  • Added modal (+Query for gifter user)
  • BootPopover logic for gifted plus
  • Added mutation for disabling gift popover at close

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-753-fe-notification-modal-ope.preview.app.daily.dev

Copy link

vercel bot commented Jan 30, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
daily-webapp ✅ Ready (Inspect) Visit Preview Feb 3, 2025 4:36pm
1 Skipped Deployment
Name Status Preview Updated (UTC)
storybook ⬜️ Ignored (Inspect) Feb 3, 2025 4:36pm

@ilasw ilasw changed the base branch from main to MI-746-gifting-plus January 30, 2025 13:03
* Received gift plus modal
*/
useEffect(() => {
if (!alerts?.shouldShowGiftPlus || !user.isPlus) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't we use boot for this instead of alerts or just was not updated yet?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added it inside the alerts object as we did for shouldShowFeedFeedback

https://github.com/dailydotdev/daily-api/blob/main/src/routes/boot.ts#L542

Copy link
Contributor

@capJavert capJavert Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should use it directly on user from useAuthContext, it will be confusing to put something that is not an alert into alerts object, it can also create invalid gql calls to alerts update mutation (because that field does not exist there)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my bad I completely missed you added it there in the API PR

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you adjust that on API? @ilasw

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I've to add to the graphorm user object? @capJavert

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm added to user in boot

Comment on lines +260 to +262
updateUserProfile({
flags: { showPlusGift: false },
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to wait for the user to close it before we turn off the flag?

Copy link
Contributor Author

@ilasw ilasw Jan 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is mandatory to wait plus don't return any promise.
But if you think is important I can change this behaviour 👀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it is more of how we should be doing it generally for our modals. Anyway, shouldn't be a blocker and we can likely keep it.

/>
<PlusList className="overflow-clip !py-0" />
</div>
<div className="flex flex-col gap-4 tablet:hidden">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need this footer at all. We should just use the drawer's close button. The issue is, I don't think it should actually be called Cancel. It should rather be called Close.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have it in design, should we drop it?
image

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably check with design/product team.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated ✔️

Copy link
Member

@sshanzel sshanzel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks amazing! Don't have anything major going on except the Close button on mobile.

ilasw and others added 3 commits January 30, 2025 18:46
Co-authored-by: Lee Hansel Solevilla <[email protected]>
Co-authored-by: Lee Hansel Solevilla <[email protected]>
Co-authored-by: Lee Hansel Solevilla <[email protected]>
Comment on lines 113 to 119
<Button
type="button"
onClick={onRequestClose}
variant={ButtonVariant.Float}
>
Close
</Button>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not need this close button after removing the props below:

drawerProps={{
displayCloseButton: false,
}}

Copy link
Member

@sshanzel sshanzel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one last thing though everything looked amazing already, hence approving 🚀

Copy link
Contributor

@capJavert capJavert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code wise don't see anything blocking, nice work! Few comments for improvement.

Comment on lines 139 to 141
flags?: {
showPlusGift?: boolean;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
flags?: {
showPlusGift?: boolean;
};
flags?: UserFlagsPublic;

Comment on lines 33 to 35
export type UserFlagsPublic = {
showPlusGift: boolean;
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export type UserFlagsPublic = {
showPlusGift: boolean;
};
export type UserFlagsPublic = Partial<{
showPlusGift: boolean;
}>;

flags are always optional so I think we can jsut do this on the type

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then below Partial can be removed

Comment on lines 72 to 74
if (!gifter || isLoading) {
return null;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non blocking

@sshanzel
Copy link
Member

sshanzel commented Feb 4, 2025

@capJavert I've now applied the non-blocking changes 🙏 will merge soon 🙌

@sshanzel sshanzel merged commit cef485d into MI-746-gifting-plus Feb 4, 2025
10 checks passed
@sshanzel sshanzel deleted the MI-753-fe-notification-modal-opening-logic branch February 4, 2025 11:24
@capJavert
Copy link
Contributor

Thanks @sshanzel !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants