Page MenuHomePhabricator

[native] update connect farcaster prompt to be less annyoying
ClosedPublic

Authored by ginsu on Jul 7 2024, 10:37 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Dec 7, 1:11 AM
Unknown Object (File)
Mon, Nov 25, 1:52 PM
Unknown Object (File)
Mon, Nov 25, 1:22 PM
Unknown Object (File)
Mon, Nov 25, 7:01 AM
Unknown Object (File)
Nov 22 2024, 4:26 PM
Unknown Object (File)
Nov 22 2024, 9:45 AM
Unknown Object (File)
Nov 22 2024, 5:32 AM
Unknown Object (File)
Nov 10 2024, 3:09 PM
Subscribers

Details

Summary

We want to update the logic for when we show the farcaster prompt so that it is less annoying. This means we only want to show this prompt to the user just once if the user has an existing account that does not have an fid yet. We will also avoid showing the prompt to users who created new accounts and chose not to connect their farcaster account during the registration process

Linear task: https://linear.app/comm/issue/ENG-8449/rethink-farcaster-prompt-to-make-sure-its-not-annoying

Test Plan

Confirmed that the following 3 scenarios work as expected

  1. Existing user with fid => No prompt
  2. Existing user with no fid => Prompt
  3. New user who declined to connect to farcaster => No prompot

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ginsu edited the test plan for this revision. (Show Details)
ginsu added reviewers: ashoat, inka.
ginsu requested review of this revision.Jul 7 2024, 10:53 PM

shouldSkipPushPermissionAlert should probably be updated - if I understand correctly this diff makes it impossible for totalAlerts to exceed 1, is that correct?

native/account/registration/registration-server-call.js
369–375 ↗(On Diff #42094)

Why do we do this? Is this later checked somehow?

shouldSkipPushPermissionAlert should probably be updated - if I understand correctly this diff makes it impossible for totalAlerts to exceed 1, is that correct?

No everything should continue to work the same as before with shouldSkipPushPermissionAlert. We only want to update the connect farcaster alert logic. This diff will only make it impossible for the totalAlerts of the connect farcaster alert to exceed 1.

native/account/registration/registration-server-call.js
369–375 ↗(On Diff #42094)

We do this to guarantee that a new user who just registered for a new comm account won't be shown the connect farcaster prompt. In the ConnectFarcasterAlertHandler we have logic that will check if the user has a value for an fid in the synced metadata table store and if they have a value we won't show them the alert/prompt

https://github.com/CommE2E/comm/blob/master/native/components/connect-farcaster-alert-handler.react.js#L39-L47

ashoat requested changes to this revision.Jul 8 2024, 12:41 PM

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

Let me know if I'm missing something.

native/account/registration/registration-server-call.js
360–375 ↗(On Diff #42094)

We can significantly cut down on the duplicated lines here:

const fidToSave = farcasterID ?? NO_FID_METADATA;
dispatch({
  type: setSyncedMetadataEntryActionType,
  payload: {
    name: syncedMetadataNames.CURRENT_USER_FID,
    data: fidToSave,
  },
});
This revision now requires changes to proceed.Jul 8 2024, 12:41 PM

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

I think there's some confusion here. I'm not suggesting storing NO_FID_METADATA on identity.

Rather, I'm concerned that we don't have any updates to code that fetches/checks syncedMetadataNames.CURRENT_USER_FID here.

We are storing a new special value in that field, that should be treated equivalently to null/undefined. Don't we need to update the code that fetches/checks syncedMetadataNames.CURRENT_USER_FID so that it knows to treat this special value as null/undefined?

Let me know if I'm missing something!

Don't we now need to consider NO_FID_METADATA in all places we fetch the FID? It seems like it would need to be checked at every place the FID is fetched.

In the linear task we said:

Don't prompt if the FID in Redux is null NONE

Based off this I was under the impression that we only want to keep NO_FID_METADATA something that is only in redux/sqlite and not in the identity service. By keeping NO_FID_METADATA only in redux/sqlite, we would re-show the farcaster prompt to the user if they ever logged out + logged back in on native, and my thinking was that this would act as another one time nudge to the user that they should connect their farcaster account to comm.

It seems like I may have misinterpreted this point. If I did I should be able to easily update this diff so that we also have NO_FID_METADATA stored in the identity service if the user decides not to connect their farcaster account

I think there's some confusion here. I'm not suggesting storing NO_FID_METADATA on identity.

Rather, I'm concerned that we don't have any updates to code that fetches/checks syncedMetadataNames.CURRENT_USER_FID here.

We are storing a new special value in that field, that should be treated equivalently to null/undefined. Don't we need to update the code that fetches/checks syncedMetadataNames.CURRENT_USER_FID so that it knows to treat this special value as null/undefined?

Let me know if I'm missing something!

Thank you for further explaining and apologies for the confusion on my end. I will need to update useCurrentUserFID so that it knows to treat NO_FID_METADATA as null. Updating the diff right now

lib/utils/farcaster-utils.js
17

if it's null then that means the user has decided NOT to set a Farcaster association. If it's undefined, then this is a case where a user has not been prompted yet, either during registration or via the later prompt.

https://linear.app/comm/issue/ENG-8449/rethink-farcaster-prompt-to-make-sure-its-not-annoying#comment-d068720f

native/components/connect-farcaster-alert-handler.react.js
43

Moved this check into shouldSkipConnectFarcasterAlert

lib/utils/farcaster-utils.js
17

Was thinking it would be good to leave a code comment here so other devs have context about this distinction between null & undefined.

I can do this before landing if this is wanted

ashoat added inline comments.
lib/utils/farcaster-utils.js
17

Yeah seems like a good idea

lib/utils/push-alerts.js
29–30

Can we replace these with fid !== undefined?

This revision is now accepted and ready to land.Jul 9 2024, 1:51 PM

address comments + rebase before landing