Conversation
594500d to
135d84e
Compare
3b3daf7 to
9308a57
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 177 out of 179 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| } | ||
| break | ||
| case 'team-invite-link': | ||
| useTeamsState.getState().dispatch.openInviteLink(parts[1] ?? '', parts[2] || '') | ||
| navigateAppend({name: 'teamInviteLinkJoin', params: {inviteID: parts[1] ?? '', inviteKey: parts[2] || ''}}) | ||
| return |
There was a problem hiding this comment.
In the team-invite-link deeplink case, inviteID can be an empty string when the link is malformed or missing segments (parts[1] undefined). Navigating to teamInviteLinkJoin with inviteID: '' leaves JoinFromInvite in its perpetual loading state (it only fetches details when inviteID is truthy). Consider validating parts[1] (and optionally parts[2]) and routing to keybaseLinkError (or another error UI) when required segments are missing/invalid, instead of navigating with empty params.
| type NavType = NavigatorTypeBagBase & { | ||
| ParamList: Pick<RootParamList, keyof typeof settingsDesktopTabRoutes> | ||
| ParamList: {[K in keyof typeof settingsDesktopTabRoutes]: undefined} | ||
| } |
There was a problem hiding this comment.
NavType['ParamList'] is currently declared as {[K in keyof typeof settingsDesktopTabRoutes]: undefined}, but at least some of the routes included in settingsDesktopTabRoutes accept params (e.g. the feedback route’s params type includes optional heading/feedback). This typing will incorrectly forbid passing params when navigating between settings tabs and can mask real param requirements. Consider restoring a RootParamList-based Pick<> (as before) or deriving each route’s params type from settingsDesktopTabRoutes so the tab navigator’s ParamList stays accurate.
No description provided.