Page MenuHomePhabricator
Differential D11483

[native] introduce farcaster account settings profile row
ClosedPublic
Actions

Authored by ginsu on Mar 29 2024, 2:29 PM.
Tags
None
Referenced Files
F6245596: D11483.diff
Fri, Apr 25, 2:07 AM
Unknown Object (File)
Mon, Apr 21, 12:59 AM
Unknown Object (File)
Thu, Apr 17, 12:57 AM
Unknown Object (File)
Sat, Apr 12, 7:04 PM
Unknown Object (File)
Thu, Apr 3, 2:51 AM
Unknown Object (File)
Thu, Mar 27, 8:17 AM
Unknown Object (File)
Wed, Mar 26, 5:48 PM
Unknown Object (File)
Feb 27 2025, 7:33 PM
View All Files
Subscribers
ashoat
tomek

Details

Reviewers
atul
Commits
rCOMMaf0bb9f6dfcf: [native] introduce farcaster account settings profile row
Summary

this diff introduces a barebones FarcasterAccountSettings screen + all the navigational logic to get to this screen from the profiles screen. Too make this diff easier to review, subsequent diffs will handle extending FarcasterAccountSettings.

Depends on D11463

Test Plan

Please see the demo video below + tested the entire sign in + unauth flow during the hackathon

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ginsu created this revision.Mar 29 2024, 2:29 PM
Herald added subscribers: tomek, ashoat. · View Herald TranscriptMar 29 2024, 2:29 PM
ginsu edited the summary of this revision. (Show Details)Mar 29 2024, 2:32 PM
ginsu edited the test plan for this revision. (Show Details)
ginsu added a reviewer: atul.
ginsu added a parent revision: D11463: [native] introduce already connected button to farcaster connect.
ginsu added inline comments.
native/profile/profile-screen.react.js
204–209

This code lives in a class component, so that is why we are not using useMemo() here

ginsu edited the test plan for this revision. (Show Details)Mar 29 2024, 2:35 PM
ginsu attached a referenced file: F1442433: Screen Recording 2024-03-29 at 5.35.12 PM.mov. (Show Details)
ginsu added inline comments.Mar 29 2024, 2:37 PM
native/profile/profile-screen.react.js
176

Decided to gate farcasterAccountSettings behind the staffCanSee so that we can internally test this before releasing this to the public

Harbormaster completed remote builds in B27831: Diff 38564.Mar 29 2024, 2:45 PM
ginsu requested review of this revision.Mar 29 2024, 2:45 PM
ashoat added inline comments.Mar 30 2024, 12:59 PM
native/profile/profile-screen.react.js
176

I think we're gating it in two other places based on usingCommServicesAccessToken:

  1. FarcasterDataHandler
  2. The new registration flow, which contains the farcaster registration flow

Should we do the same here?

ginsu added inline comments.Apr 1 2024, 11:56 AM
native/profile/profile-screen.react.js
176

yea that makes sense, I'll update the gate so that it's based off of usingCommServicesAccessToken + __DEV__ rather than staffCanSee

ginsu updated this revision to Diff 38634.Apr 1 2024, 11:57 AM

update farcaster account gate logic

ginsu added inline comments.Apr 1 2024, 11:58 AM
native/profile/profile-screen.react.js
241–246 ↗(On Diff #38634)

This code lives in a class component, so that is why we are not using useMemo() here

ginsu added a child revision: D11484: [native] update FarcasterPrompt based on if the fid is set or not.Apr 1 2024, 12:09 PM
Harbormaster failed remote builds in B27892: Diff 38634!Apr 1 2024, 12:09 PM
ginsu updated this revision to Diff 38637.Apr 1 2024, 12:27 PM

fix eslint ci issue

ginsu added inline comments.Apr 1 2024, 12:28 PM
native/profile/profile-screen.react.js
241–246 ↗(On Diff #38637)

This code lives in a class component, so that is why we are not using useMemo() here

Harbormaster completed remote builds in B27895: Diff 38637.Apr 1 2024, 12:42 PM
atul accepted this revision.Apr 1 2024, 12:46 PM
atul added inline comments.
native/profile/profile-screen.react.js
241–246 ↗(On Diff #38637)

Thanks for noting this

This revision is now accepted and ready to land.Apr 1 2024, 12:46 PM
ginsu updated this revision to Diff 38738.Apr 3 2024, 9:24 AM

rebase before landing

Harbormaster completed remote builds in B27958: Diff 38738.Apr 3 2024, 9:43 AM
Closed by commit rCOMMaf0bb9f6dfcf: [native] introduce farcaster account settings profile row (authored by ginsu). · Explain WhyApr 3 2024, 9:49 AM
This revision was automatically updated to reflect the committed changes.
ginsu added a commit: rCOMMaf0bb9f6dfcf: [native] introduce farcaster account settings profile row.

Revision Contents
Changeset List

PathSize
native/
navigation/
2 lines
profile/
18 lines
16 lines
8 lines

Diff 38564

View Options

native/navigation/route-names.js

Show First 20 Lines • Show All 56 Lines • ▼ Show 20 Linesexport const updateRelationshipMessageSpec: UpdateRelationshipMessageSpec =
Object.freeze({ Object.freeze({
messageContentForServerDB( messageContentForServerDB(
data: data:
| LegacyUpdateRelationshipMessageData | LegacyUpdateRelationshipMessageData
| RawLegacyUpdateRelationshipMessageInfo | RawLegacyUpdateRelationshipMessageInfo
| UpdateRelationshipMessageData | UpdateRelationshipMessageData
| RawUpdateRelationshipMessageInfo, | RawUpdateRelationshipMessageInfo,
): string { ): string {
if (
data.type === messageTypes.UPDATE_RELATIONSHIP &&
tomekUnsubmitted
Not Done
Inline Actions

Do we have to check this condition?

tomek: Do we have to check this condition?
atulAuthorUnsubmitted
Done
Inline Actions

Yeah, the reason we need to check this is because updateRelationshipMessageSpec is used for both LEGACY_UPDATE_RELATIONSHIP and UPDATE_RELATIONSHIP messages.

atul: Yeah, the reason we need to check this is because `updateRelationshipMessageSpec` is used for…
atulAuthorUnsubmitted
Done
Inline Actions

JK, I think what you're saying is that data.operation === 'farcaster_mutual' would be a sufficient check since that implicitly tells us that the message type is UPDATE_RELATIONSHIP so having both is a bit redundant.

Personally prefer including the first clause since it makes things more clear IMO, but can remove if others feel otherwise

atul: JK, I think what you're saying is that `data.operation === 'farcaster_mutual'` would be a…
tomekUnsubmitted
Not Done
Inline Actions

Ok, we can keep both conditions.

tomek: Ok, we can keep both conditions.
data.operation === 'farcaster_mutual'
) {
return JSON.stringify({
operation: data.operation,
targetID: data.targetID,
creatorFID: data.creatorFID,
targetFID: data.targetFID,
});
}
return JSON.stringify({ return JSON.stringify({
operation: data.operation, operation: data.operation,
targetID: data.targetID, targetID: data.targetID,
}); });
}, },
messageContentForClientDB( messageContentForClientDB(
data: data:
▲ Show 20 Lines • Show All 238 Lines • Show Last 20 Lines
View Options

native/profile/farcaster-account-settings.react.js

Show First 20 Lines • Show All 56 Lines • ▼ Show 20 Linesexport const updateRelationshipMessageSpec: UpdateRelationshipMessageSpec =
Object.freeze({ Object.freeze({
messageContentForServerDB( messageContentForServerDB(
data: data:
| LegacyUpdateRelationshipMessageData | LegacyUpdateRelationshipMessageData
| RawLegacyUpdateRelationshipMessageInfo | RawLegacyUpdateRelationshipMessageInfo
| UpdateRelationshipMessageData | UpdateRelationshipMessageData
| RawUpdateRelationshipMessageInfo, | RawUpdateRelationshipMessageInfo,
): string { ): string {
if (
data.type === messageTypes.UPDATE_RELATIONSHIP &&
tomekUnsubmitted
Not Done
Inline Actions

Do we have to check this condition?

tomek: Do we have to check this condition?
atulAuthorUnsubmitted
Done
Inline Actions

Yeah, the reason we need to check this is because updateRelationshipMessageSpec is used for both LEGACY_UPDATE_RELATIONSHIP and UPDATE_RELATIONSHIP messages.

atul: Yeah, the reason we need to check this is because `updateRelationshipMessageSpec` is used for…
atulAuthorUnsubmitted
Done
Inline Actions

JK, I think what you're saying is that data.operation === 'farcaster_mutual' would be a sufficient check since that implicitly tells us that the message type is UPDATE_RELATIONSHIP so having both is a bit redundant.

Personally prefer including the first clause since it makes things more clear IMO, but can remove if others feel otherwise

atul: JK, I think what you're saying is that `data.operation === 'farcaster_mutual'` would be a…
tomekUnsubmitted
Not Done
Inline Actions

Ok, we can keep both conditions.

tomek: Ok, we can keep both conditions.
data.operation === 'farcaster_mutual'
) {
return JSON.stringify({
operation: data.operation,
targetID: data.targetID,
creatorFID: data.creatorFID,
targetFID: data.targetFID,
});
}
return JSON.stringify({ return JSON.stringify({
operation: data.operation, operation: data.operation,
targetID: data.targetID, targetID: data.targetID,
}); });
}, },
messageContentForClientDB( messageContentForClientDB(
data: data:
▲ Show 20 Lines • Show All 238 Lines • Show Last 20 Lines
View Options

native/profile/profile-screen.react.js

Show First 20 Lines • Show All 56 Lines • ▼ Show 20 Linesexport const updateRelationshipMessageSpec: UpdateRelationshipMessageSpec =
Object.freeze({ Object.freeze({
messageContentForServerDB( messageContentForServerDB(
data: data:
| LegacyUpdateRelationshipMessageData | LegacyUpdateRelationshipMessageData
| RawLegacyUpdateRelationshipMessageInfo | RawLegacyUpdateRelationshipMessageInfo
| UpdateRelationshipMessageData | UpdateRelationshipMessageData
| RawUpdateRelationshipMessageInfo, | RawUpdateRelationshipMessageInfo,
): string { ): string {
if (
data.type === messageTypes.UPDATE_RELATIONSHIP &&
tomekUnsubmitted
Not Done
Inline Actions

Do we have to check this condition?

tomek: Do we have to check this condition?
atulAuthorUnsubmitted
Done
Inline Actions

Yeah, the reason we need to check this is because updateRelationshipMessageSpec is used for both LEGACY_UPDATE_RELATIONSHIP and UPDATE_RELATIONSHIP messages.

atul: Yeah, the reason we need to check this is because `updateRelationshipMessageSpec` is used for…
atulAuthorUnsubmitted
Done
Inline Actions

JK, I think what you're saying is that data.operation === 'farcaster_mutual' would be a sufficient check since that implicitly tells us that the message type is UPDATE_RELATIONSHIP so having both is a bit redundant.

Personally prefer including the first clause since it makes things more clear IMO, but can remove if others feel otherwise

atul: JK, I think what you're saying is that `data.operation === 'farcaster_mutual'` would be a…
tomekUnsubmitted
Not Done
Inline Actions

Ok, we can keep both conditions.

tomek: Ok, we can keep both conditions.
data.operation === 'farcaster_mutual'
) {
return JSON.stringify({
operation: data.operation,
targetID: data.targetID,
creatorFID: data.creatorFID,
targetFID: data.targetFID,
});
}
return JSON.stringify({ return JSON.stringify({
operation: data.operation, operation: data.operation,
targetID: data.targetID, targetID: data.targetID,
}); });
}, },
messageContentForClientDB( messageContentForClientDB(
data: data:
▲ Show 20 Lines • Show All 238 Lines • Show Last 20 Lines
View Options

native/profile/profile.react.js

Show First 20 Lines • Show All 56 Lines • ▼ Show 20 Linesexport const updateRelationshipMessageSpec: UpdateRelationshipMessageSpec =
Object.freeze({ Object.freeze({
messageContentForServerDB( messageContentForServerDB(
data: data:
| LegacyUpdateRelationshipMessageData | LegacyUpdateRelationshipMessageData
| RawLegacyUpdateRelationshipMessageInfo | RawLegacyUpdateRelationshipMessageInfo
| UpdateRelationshipMessageData | UpdateRelationshipMessageData
| RawUpdateRelationshipMessageInfo, | RawUpdateRelationshipMessageInfo,
): string { ): string {
if (
data.type === messageTypes.UPDATE_RELATIONSHIP &&
tomekUnsubmitted
Not Done
Inline Actions

Do we have to check this condition?

tomek: Do we have to check this condition?
atulAuthorUnsubmitted
Done
Inline Actions

Yeah, the reason we need to check this is because updateRelationshipMessageSpec is used for both LEGACY_UPDATE_RELATIONSHIP and UPDATE_RELATIONSHIP messages.

atul: Yeah, the reason we need to check this is because `updateRelationshipMessageSpec` is used for…
atulAuthorUnsubmitted
Done
Inline Actions

JK, I think what you're saying is that data.operation === 'farcaster_mutual' would be a sufficient check since that implicitly tells us that the message type is UPDATE_RELATIONSHIP so having both is a bit redundant.

Personally prefer including the first clause since it makes things more clear IMO, but can remove if others feel otherwise

atul: JK, I think what you're saying is that `data.operation === 'farcaster_mutual'` would be a…
tomekUnsubmitted
Not Done
Inline Actions

Ok, we can keep both conditions.

tomek: Ok, we can keep both conditions.
data.operation === 'farcaster_mutual'
) {
return JSON.stringify({
operation: data.operation,
targetID: data.targetID,
creatorFID: data.creatorFID,
targetFID: data.targetFID,
});
}
return JSON.stringify({ return JSON.stringify({
operation: data.operation, operation: data.operation,
targetID: data.targetID, targetID: data.targetID,
}); });
}, },
messageContentForClientDB( messageContentForClientDB(
data: data:
▲ Show 20 Lines • Show All 238 Lines • Show Last 20 Lines