Enable basic profile configuration functionality#418
Enable basic profile configuration functionality#418akaia-shadowfox merged 139 commits intostagingfrom
Conversation
…into 317-bug-fix-project-registration-fllow
…into 19012025-wallet-context
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis update introduces a major refactor and expansion of the profile management system, transitioning from a "Profile Setup" to a "Profile Configuration" paradigm. It adds support for non-fungible token (NFT) profile images, updates form components and schemas, restructures token hooks for fungible tokens, and enables the profile configuration feature flag in staging and production. Numerous legacy files are removed, and new utilities, types, and modules are introduced for improved normalization, validation, and extensibility. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant ProfileEditor
participant SocialProfileHook
participant NFTClient
participant PinataUpload
participant FormSchema
User->>ProfileEditor: Open profile editor
ProfileEditor->>SocialProfileHook: Fetch profile data
SocialProfileHook->>NFTClient: (if NFT image) Fetch NFT metadata
SocialProfileHook-->>ProfileEditor: Return avatar/cover URLs
User->>ProfileEditor: Upload new image
ProfileEditor->>PinataUpload: Upload image to IPFS
PinataUpload-->>ProfileEditor: Return image URL
User->>ProfileEditor: Submit form
ProfileEditor->>FormSchema: Validate with profileConfigurationSchema
FormSchema-->>ProfileEditor: Validation result
ProfileEditor-->>User: Show success/failure
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (8)
🚧 Files skipped from review as they are similar to previous changes (5)
🧰 Additional context used🧬 Code Graph Analysis (2)src/entities/list/components/ListDetails.tsx (1)
src/entities/list/components/ListCard.tsx (2)
🔇 Additional comments (5)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 9
🔭 Outside diff range comments (4)
src/features/profile-configuration/components/AddFundingSourceModal.tsx (1)
51-51: Critical: Form submission logic is commented out.The dispatch logic for adding and updating funding sources is commented out, making this modal non-functional. This will result in data not being saved when users submit the form.
Please uncomment and implement the actual dispatch logic:
- // dispatch.projectEditor.addFundingSource(data); + dispatch.projectEditor.addFundingSource(data);- // dispatch.projectEditor.updateFundingSource({ - // fundingSourceData: data, - // index: editFundingIndex, - // }); + dispatch.projectEditor.updateFundingSource({ + fundingSourceData: data, + index: editFundingIndex, + });Also applies to: 65-68
src/features/profile-configuration/components/repositories-section.tsx (2)
72-72: Critical: Repository changes are not being handled.The
onChangeHandlerpassed to theRepocomponent is an empty function, meaning repository URL changes won't be saved or propagated to the parent component.The component needs proper change handling. Either:
- Implement the commented-out state management logic, or
- Use the
onChangeprop that's already passed to the component:return values?.map((repo, index) => ( - <Repo key={repo} repo={repo} index={index} onChangeHandler={() => {}} /> + <Repo key={repo} repo={repo} index={index} onChangeHandler={(repoIndex, value) => { + if (onChange) { + const updatedRepos = [...(values || [])]; + updatedRepos[repoIndex] = value; + onChange(updatedRepos); + } + }} /> ));
49-69: Remove commented code or implement it.The large block of commented state management code should either be implemented or removed. Keeping dead code reduces maintainability.
If this functionality is needed, implement it properly. Otherwise, remove the commented code:
- // const [repos, setRepos] = useState(repositories.length > 0 ? repositories : [""]); - - // useEffect(() => { - // setRepos(repositories); - // }, [repositories]); - - // const onChangeHandler = useCallback( - // (repoIndex: number, value: string) => { - // const updatedState = [...repositories]; - // updatedState[repoIndex] = value; - // setRepos(updatedState); - // dispatch.projectEditor.updateRepositories(updatedState); - // }, - // [repositories], - // ); - - // useEffect(() => { - // if (onChange) { - // onChange(repos); - // } - // }, [repos, onChange]);src/features/profile-configuration/components/editor.tsx (1)
213-257: Commented code sections should be addressed.Large sections of code are commented out (smart contracts, funding sources, repositories). Consider either removing these sections if they're not needed, or creating a tracking issue if they'll be implemented later.
Would you like me to help create a tracking issue for these commented features or determine if they should be removed?
🧹 Nitpick comments (17)
src/entities/list/components/AccountCard.tsx (1)
65-67: Avoid unnecessary effect re-runs
registrationStatusis included in the dependency array of this effect, yet the effect’s sole purpose is to set that very state.
Removing it prevents one redundant render and eliminates the risk of an unintended loop.-useEffect(() => { - setRegistrationStatus(RegistrationStatus[dataForList.status]); -}, [dataForList, registrationStatus]); +useEffect(() => { + setRegistrationStatus(RegistrationStatus[dataForList.status]); + // `registrationStatus` intentionally omitted – we only react to `dataForList` +}, [dataForList]);src/pages/pot/[potId]/payouts.tsx (1)
59-60: Token decimals fallback: safe but may flash
token?.metadata.decimals ?? NATIVE_TOKEN_DECIMALSprevents crashes while metadata loads, yet the first render shows values with the fallback decimals and will re-render once token data arrives. If visual flicker is undesirable, gate rendering untiltokenis available or pre-seed SWR with native token metadata.src/common/contracts/tokens/fungible/client.ts (1)
9-9: Fix TypeScript type usage for better type safety.Using
{}as a generic type parameter is discouraged as it means "any non-nullable value" rather than an empty object.Replace the empty object type with a more explicit type:
- .view<{}, FungibleTokenMetadata>("ft_metadata") + .view<Record<string, never>, FungibleTokenMetadata>("ft_metadata")Alternatively, if no parameters are expected, you could use
void:- .view<{}, FungibleTokenMetadata>("ft_metadata") + .view<void, FungibleTokenMetadata>("ft_metadata")src/entities/_shared/account/utils/linktree.ts (1)
9-12: Consider type consistency in return values.The function can return either
string | undefined(from regex capture) orstring(original URL), which creates inconsistent return types. Consider explicitly handling the undefined case from regex extraction.- return ACCOUNT_PROFILE_URL_PATTERNS[key].test(url) - ? ACCOUNT_PROFILE_URL_PATTERNS[key].exec(url)?.at(1) - : url; + return ACCOUNT_PROFILE_URL_PATTERNS[key].test(url) + ? ACCOUNT_PROFILE_URL_PATTERNS[key].exec(url)?.at(1) ?? url + : url;src/common/contracts/tokens/non-fungible/hooks.ts (1)
18-21: Consider improving error handling and parameter validation.The fetcher function has a few areas for improvement:
- Parameter validation: The destructured parameters
account_idandtoken_idaren't validated before use- Error handling: Catching all errors and returning
undefinedmight hide important contract-related errors that could be useful for debuggingConsider this more robust implementation:
- ([_queryKeyHead, account_id, token_id]) => - nftContractClient - .nft_token({ contractAccountId: account_id, tokenId: token_id }) - .catch(() => undefined), + ([_queryKeyHead, account_id, token_id]) => { + if (!account_id || !token_id) { + throw new Error('Missing required parameters for NFT token lookup'); + } + return nftContractClient + .nft_token({ contractAccountId: account_id, tokenId: token_id }) + .catch((error) => { + console.warn('Failed to fetch NFT token:', error); + return undefined; + }); + },src/entities/_shared/account/components/profile-images.tsx (1)
39-41: Consider memoizing contentClassName for performance.Moving the
contentClassNameconstant outside the component removes memoization, which could cause unnecessary re-renders if this string was previously memoized. However, since it's a static string, this change is acceptable and simplifies the code.src/features/profile-configuration/components/funding-sources.tsx (1)
108-110: Address the commented out delete functionality.The delete handler contains a commented out dispatch call, which means the delete functionality is not currently working.
Do you want me to help implement the delete functionality or create an issue to track this incomplete feature?
src/entities/_shared/account/hooks/social-image.ts (2)
22-26: Optimize NFT hook to avoid unnecessary calls.The NFT contract hook will still make network calls with NOOP_STRING values when
nftParamsis null. Consider using more specific conditions to prevent this.const { data: nft } = nftContractHooks.useToken({ - enabled: nftParams !== null, + enabled: nftParams !== null && !!nftParams.contractId && !!nftParams.tokenId, contractAccountId: nftParams?.contractId ?? NOOP_STRING, tokenId: nftParams?.tokenId ?? NOOP_STRING, });
31-31: Consider making IPFS gateway configurable.The IPFS URL is hardcoded to use
ipfs.near.socialgateway. Consider making this configurable for better flexibility and resilience.Consider extracting the IPFS gateway to a constant:
+ const IPFS_GATEWAY = "https://ipfs.near.social/ipfs/"; const rawImageSrc = useMemo(() => { if (typeof data !== "string") { return ( - data?.url ?? (data?.ipfs_cid ? `https://ipfs.near.social/ipfs/${data?.ipfs_cid}` : null) + data?.url ?? (data?.ipfs_cid ? `${IPFS_GATEWAY}${data?.ipfs_cid}` : null) ); } else return data; }, [data]);src/entities/_shared/token/hooks/fungible.ts (1)
57-57: Inconsistent flag naming convention.Lines 57 and 84 still use
disabledflags while other hooks have been updated to useenabledflags. This inconsistency could cause confusion.Consider updating these for consistency:
} = coingeckoHooks.useNativeTokenUsdPrice({ - disabled: !enabled || tokenId !== NATIVE_TOKEN_ID, + enabled: enabled && tokenId === NATIVE_TOKEN_ID, });} = intearTokenIndexerHooks.useTokenUsdPrice({ - disabled: !enabled || !isValidFtContractAccountId, + enabled: enabled && isValidFtContractAccountId, tokenId, });Also applies to: 84-84
src/features/profile-configuration/components/linktree-section.tsx (1)
34-34: Remove unnecessary empty fragments.The empty fragments in
labelExtensionserve no purpose and should be removed as flagged by the linter.- labelExtension={<></>} + labelExtension=""Apply this pattern to all four form fields (lines 34, 50, 66, 82).
Also applies to: 50-50, 66-66, 82-82
src/common/contracts/tokens/non-fungible/client.ts (2)
17-21: Consider improving error handling for better debugging.While the current error suppression pattern works, it might hide useful debugging information. Consider logging errors or providing more context about failures.
export const nft_token = ({ contractAccountId, tokenId }: NonFungibleTokenLookupParams) => nearProtocolClient.naxiosInstance .contractApi({ contractId: contractAccountId }) .view<NftTokenArgs, NonFungibleToken>("nft_token", { args: { token_id: tokenId } }) - .catch(() => undefined); + .catch((error) => { + console.debug(`Failed to fetch NFT token ${tokenId} from ${contractAccountId}:`, error); + return undefined; + });
26-30: Apply consistent error handling pattern.The same error handling improvement should be applied to
nft_metadatafor consistency.export const nft_metadata = ({ contractAccountId }: ByContractAccountId) => nearProtocolClient.naxiosInstance .contractApi({ contractId: contractAccountId }) .view<Record<string, never>, NonFungibleTokenContractMetadata>("nft_metadata") - .catch(() => undefined); + .catch((error) => { + console.debug(`Failed to fetch NFT metadata from ${contractAccountId}:`, error); + return undefined; + });src/features/profile-configuration/models/deprecated.ts (1)
42-101: Note: State mutation patterns in deprecated code.While this code is deprecated, for reference purposes: the reducers appear to directly mutate state properties (e.g.,
state.daoProjectProposal = daoProjectProposal). This pattern suggests Immer usage, but direct mutations without Immer would be problematic in Redux/Rematch.src/features/profile-configuration/components/editor.tsx (1)
33-279: Consider breaking down this large component.The
ProfileEditorcomponent is quite large and handles many responsibilities. Consider extracting some sections into smaller, focused components for better maintainability and testing.For example, the form fields section could be extracted into a separate component like
ProfileFormFields.src/features/profile-configuration/hooks/forms.ts (1)
22-177: Consider splitting this complex hook.The
useProfileFormhook handles many responsibilities. Consider extracting some logic into smaller, focused hooks (e.g.,useProfileDefaults,useProfileValidation) for better maintainability and testing.src/layout/profile/components/team.tsx (1)
44-47: Improve type safety for team member extraction.The
useMemocomputation could benefit from better type safety sinceextractProfileTeamMemberscan return different types (array or undefined).const teamMemberAccountIds = useMemo( - () => (profile === undefined ? [] : (extractProfileTeamMembers(profile) ?? [])), + () => { + if (!profile) return []; + const members = extractProfileTeamMembers(profile); + return Array.isArray(members) ? members : []; + }, [profile], );
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (100)
.vscode/settings.json(1 hunks)src/common/_config/production.env-config.ts(1 hunks)src/common/_config/staging.env-config.ts(1 hunks)src/common/api/near-social-indexer/hooks.ts(1 hunks)src/common/blockchains/near-protocol/hooks.ts(4 hunks)src/common/constants.ts(1 hunks)src/common/contracts/tokens/fungible/client.ts(1 hunks)src/common/contracts/tokens/fungible/hooks.ts(1 hunks)src/common/contracts/tokens/index.ts(1 hunks)src/common/contracts/tokens/non-fungible/client.ts(1 hunks)src/common/contracts/tokens/non-fungible/hooks.ts(1 hunks)src/common/contracts/tokens/non-fungible/index.ts(1 hunks)src/common/contracts/tokens/non-fungible/interfaces.ts(1 hunks)src/common/lib/object.ts(2 hunks)src/common/services/images.ts(0 hunks)src/common/services/pinata/hooks.ts(1 hunks)src/common/types.ts(2 hunks)src/common/ui/form/components/text.tsx(3 hunks)src/common/ui/layout/components/molecules/multi-select.tsx(5 hunks)src/common/ui/layout/svg/CameraIcon.tsx(0 hunks)src/common/ui/layout/svg/camera.tsx(0 hunks)src/entities/_shared/account/components/AccountFollowStats.tsx(2 hunks)src/entities/_shared/account/components/profile-images.tsx(2 hunks)src/entities/_shared/account/constants.ts(2 hunks)src/entities/_shared/account/hooks/social-image.ts(1 hunks)src/entities/_shared/account/hooks/social-profile.ts(2 hunks)src/entities/_shared/account/index.ts(1 hunks)src/entities/_shared/account/types.ts(1 hunks)src/entities/_shared/account/utils/linktree.ts(1 hunks)src/entities/_shared/index.ts(0 hunks)src/entities/_shared/token/components/balance.tsx(2 hunks)src/entities/_shared/token/components/icons.tsx(2 hunks)src/entities/_shared/token/components/selector.tsx(3 hunks)src/entities/_shared/token/components/value-summary.tsx(2 hunks)src/entities/_shared/token/hooks/_deprecated.ts(1 hunks)src/entities/_shared/token/hooks/fungible.ts(6 hunks)src/entities/_shared/token/index.ts(1 hunks)src/entities/campaign/components/CampaignBanner.tsx(5 hunks)src/entities/campaign/components/CampaignDonorsTable.tsx(1 hunks)src/entities/campaign/components/CampaignProgressBar.tsx(2 hunks)src/entities/campaign/components/CampaignSettings.tsx(2 hunks)src/entities/campaign/components/editor.tsx(2 hunks)src/entities/campaign/hooks/forms.ts(2 hunks)src/entities/list/components/AccountCard.tsx(1 hunks)src/entities/list/components/ListAccounts.tsx(1 hunks)src/entities/list/hooks/registrations.ts(1 hunks)src/entities/post/components/PostEditor.tsx(2 hunks)src/entities/pot/components/PotCard.tsx(2 hunks)src/entities/pot/components/PotDonationEntry.tsx(2 hunks)src/entities/pot/components/PotDonationStats.tsx(3 hunks)src/entities/voting-round/components/WinnerRow.tsx(2 hunks)src/entities/voting-round/hooks/results.ts(2 hunks)src/entities/voting-round/hooks/voter-profile.ts(2 hunks)src/entities/voting-round/model/types.ts(1 hunks)src/features/donation/components/campaign-success-share.tsx(1 hunks)src/features/donation/components/group-allocation-recipients.tsx(2 hunks)src/features/donation/components/group-allocation-success.tsx(2 hunks)src/features/donation/components/group-allocation.tsx(2 hunks)src/features/donation/components/single-recipient-allocation.tsx(2 hunks)src/features/donation/components/single-recipient-success-share.tsx(1 hunks)src/features/donation/components/single-recipient-success.tsx(2 hunks)src/features/donation/components/user-entrypoints.tsx(2 hunks)src/features/donation/hooks/form.ts(2 hunks)src/features/donation/models/effects/campaign-ft-donation.ts(10 hunks)src/features/donation/models/effects/direct-ft-donation.ts(8 hunks)src/features/pot-application/hooks/clearance.ts(2 hunks)src/features/profile-configuration/components/AddFundingSourceModal.tsx(3 hunks)src/features/profile-configuration/components/contract-modal.tsx(1 hunks)src/features/profile-configuration/components/contracts-section.tsx(3 hunks)src/features/profile-configuration/components/dao-progress.tsx(1 hunks)src/features/profile-configuration/components/editor-elements.tsx(4 hunks)src/features/profile-configuration/components/editor.tsx(10 hunks)src/features/profile-configuration/components/funding-sources.tsx(2 hunks)src/features/profile-configuration/components/image-upload.tsx(1 hunks)src/features/profile-configuration/components/linktree-section.tsx(1 hunks)src/features/profile-configuration/components/repositories-section.tsx(2 hunks)src/features/profile-configuration/hooks/forms.ts(2 hunks)src/features/profile-configuration/index.ts(1 hunks)src/features/profile-configuration/models/deprecated.ts(1 hunks)src/features/profile-configuration/models/effects.ts(3 hunks)src/features/profile-configuration/models/schemas.ts(2 hunks)src/features/profile-configuration/models/types.ts(1 hunks)src/features/profile-configuration/types.ts(1 hunks)src/features/profile-configuration/utils/normalization.ts(1 hunks)src/features/profile-setup/components/image-upload.tsx(0 hunks)src/features/profile-setup/components/linktree-section.tsx(0 hunks)src/features/profile-setup/index.ts(0 hunks)src/features/profile-setup/models/deprecated.ts(0 hunks)src/features/profile-setup/models/types.ts(0 hunks)src/features/profile-setup/types.ts(0 hunks)src/features/profile-setup/utils/normalization.ts(0 hunks)src/features/proportional-funding/components/payout-manager.tsx(2 hunks)src/layout/profile/_deprecated/DonationItem.tsx(3 hunks)src/layout/profile/components/summary.tsx(2 hunks)src/layout/profile/components/team.tsx(2 hunks)src/pages/pot/[potId]/applications.tsx(1 hunks)src/pages/pot/[potId]/payouts.tsx(2 hunks)src/pages/profile/[accountId]/edit.tsx(2 hunks)src/pages/profile/[accountId]/home.tsx(1 hunks)src/pages/register.tsx(2 hunks)
💤 Files with no reviewable changes (11)
- src/features/profile-setup/index.ts
- src/features/profile-setup/types.ts
- src/entities/_shared/index.ts
- src/common/ui/layout/svg/camera.tsx
- src/features/profile-setup/utils/normalization.ts
- src/common/ui/layout/svg/CameraIcon.tsx
- src/features/profile-setup/models/types.ts
- src/common/services/images.ts
- src/features/profile-setup/components/image-upload.tsx
- src/features/profile-setup/components/linktree-section.tsx
- src/features/profile-setup/models/deprecated.ts
🧰 Additional context used
🧬 Code Graph Analysis (45)
src/entities/_shared/token/components/value-summary.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/features/proportional-funding/components/payout-manager.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/voting-round/components/WinnerRow.tsx (2)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/features/pot-application/hooks/clearance.ts (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/features/donation/components/single-recipient-allocation.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/campaign/hooks/forms.ts (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/_shared/token/components/balance.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/_shared/token/components/icons.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/features/donation/hooks/form.ts (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/post/components/PostEditor.tsx (1)
src/entities/_shared/account/hooks/social-profile.ts (1)
useAccountSocialProfile(10-41)
src/pages/register.tsx (1)
src/features/profile-configuration/components/editor.tsx (1)
ProfileEditor(33-279)
src/pages/pot/[potId]/payouts.tsx (2)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/entities/pot/components/PotCard.tsx (3)
src/common/api/indexer/internal/client.generated.ts (1)
Pot(775-895)src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/common/services/pinata/hooks.ts (1)
src/common/services/pinata/client.ts (1)
upload(17-20)
src/common/types.ts (1)
src/common/contracts/core/voting/interfaces.ts (1)
AccountId(1-1)
src/layout/profile/components/summary.tsx (1)
src/features/donation/components/user-entrypoints.tsx (1)
DonateToAccountButton(43-58)
src/entities/_shared/account/utils/linktree.ts (2)
src/entities/_shared/account/types.ts (1)
AccountProfileLinktreeKey(21-21)src/entities/_shared/account/constants.ts (1)
ACCOUNT_PROFILE_URL_PATTERNS(29-34)
src/entities/campaign/components/CampaignSettings.tsx (2)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/entities/voting-round/hooks/results.ts (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/campaign/components/CampaignProgressBar.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/features/profile-configuration/components/contract-modal.tsx (1)
src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)
src/common/contracts/tokens/fungible/client.ts (3)
src/common/types.ts (2)
ByTokenId(111-116)ByAccountId(42-44)src/common/blockchains/near-protocol/index.ts (1)
nearProtocolClient(6-6)src/common/contracts/tokens/fungible/interfaces.ts (1)
FungibleTokenMetadata(1-9)
src/features/profile-configuration/models/types.ts (1)
src/features/profile-configuration/models/schemas.ts (2)
profileConfigurationSchema(31-61)addFundingSourceSchema(5-27)
src/common/api/near-social-indexer/hooks.ts (2)
src/common/types.ts (2)
ByAccountId(42-44)ConditionalActivation(90-92)src/common/api/near-social-indexer/client.ts (1)
nearSocialClient(15-18)
src/layout/profile/_deprecated/DonationItem.tsx (1)
src/entities/_shared/account/hooks/social-profile.ts (1)
useAccountSocialProfile(10-41)
src/entities/_shared/token/components/selector.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (2)
useFungibleToken(35-195)useFungibleTokenAllowlist(16-28)
src/entities/pot/components/PotDonationStats.tsx (2)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/entities/_shared/account/components/profile-images.tsx (2)
src/entities/_shared/account/hooks/social-profile.ts (1)
useAccountSocialProfile(10-41)src/entities/_shared/account/constants.ts (1)
ACCOUNT_PROFILE_COVER_IMAGE_PLACEHOLDER_SRC(19-20)
src/entities/_shared/account/hooks/social-image.ts (3)
src/common/contracts/social-db/client.ts (1)
NEARSocialUserProfile(58-81)src/common/contracts/tokens/non-fungible/index.ts (1)
nftContractHooks(7-7)src/common/constants.ts (1)
NOOP_STRING(161-161)
src/features/profile-configuration/models/effects.ts (4)
src/common/types.ts (1)
ByAccountId(42-44)src/features/profile-configuration/types.ts (1)
ProfileConfigurationMode(1-1)src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)src/features/profile-configuration/utils/normalization.ts (1)
profileConfigurationInputsToSocialDbFormat(15-41)
src/features/donation/components/single-recipient-success.tsx (1)
src/entities/_shared/token/hooks/fungible.ts (1)
useFungibleToken(35-195)
src/entities/_shared/account/hooks/social-profile.ts (2)
src/entities/_shared/account/hooks/social-image.ts (1)
useAccountSocialImageSrc(14-44)src/entities/_shared/account/constants.ts (2)
ACCOUNT_PROFILE_IMAGE_PLACEHOLDER_SRC(14-15)ACCOUNT_PROFILE_COVER_IMAGE_PLACEHOLDER_SRC(19-20)
src/common/contracts/tokens/non-fungible/interfaces.ts (1)
src/common/types.ts (1)
AccountId(40-40)
src/features/profile-configuration/components/funding-sources.tsx (1)
src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)
src/features/donation/components/user-entrypoints.tsx (2)
src/common/types.ts (1)
ByAccountId(42-44)src/features/donation/hooks/user-flow.ts (1)
useDonationUserFlow(15-44)
src/features/profile-configuration/models/schemas.ts (1)
src/entities/_shared/account/constants.ts (1)
ACCOUNT_PROFILE_DESCRIPTION_MAX_LENGTH(10-10)
src/features/profile-configuration/components/linktree-section.tsx (2)
src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)src/common/ui/form/components/text.tsx (1)
TextField(30-163)
src/common/contracts/tokens/non-fungible/client.ts (3)
src/common/contracts/tokens/non-fungible/interfaces.ts (3)
NonFungibleTokenLookupParams(116-119)NonFungibleToken(110-114)NonFungibleTokenContractMetadata(71-108)src/common/blockchains/near-protocol/index.ts (1)
nearProtocolClient(6-6)src/common/types.ts (1)
ByContractAccountId(46-48)
src/common/contracts/tokens/non-fungible/hooks.ts (3)
src/common/contracts/tokens/non-fungible/interfaces.ts (1)
NonFungibleTokenLookupParams(116-119)src/common/types.ts (1)
ConditionalActivation(90-92)src/common/constants.ts (2)
IS_CLIENT(12-12)CONTRACT_SWR_CONFIG(165-169)
src/entities/_shared/token/hooks/fungible.ts (3)
src/common/types.ts (2)
ConditionalActivation(90-92)LiveUpdateParams(94-96)src/entities/_shared/token/types.ts (2)
TokenQuery(13-15)TokenQueryResult(17-24)src/common/constants.ts (1)
NATIVE_TOKEN_ID(115-115)
src/common/blockchains/near-protocol/hooks.ts (2)
src/common/types.ts (3)
ConditionalActivation(90-92)ByAccountId(42-44)LiveUpdateParams(94-96)src/common/constants.ts (2)
NATIVE_TOKEN_ID(115-115)IS_CLIENT(12-12)
src/features/profile-configuration/components/contracts-section.tsx (1)
src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)
src/features/profile-configuration/models/deprecated.ts (3)
src/common/types.ts (1)
ByAccountId(42-44)src/common/contracts/social-db/client.ts (1)
NEARSocialUserProfile(58-81)src/features/profile-configuration/models/types.ts (2)
ProfileConfigurationInputs(5-5)AddFundingSourceInputs(7-7)
src/common/contracts/tokens/fungible/hooks.ts (2)
src/common/types.ts (4)
ByTokenId(111-116)ConditionalActivation(90-92)ByAccountId(42-44)LiveUpdateParams(94-96)src/common/constants.ts (2)
IS_CLIENT(12-12)CONTRACT_SWR_CONFIG(165-169)
src/features/profile-configuration/components/repositories-section.tsx (1)
src/features/profile-configuration/models/types.ts (1)
ProfileConfigurationInputs(5-5)
🪛 Biome (1.9.4)
src/common/contracts/tokens/fungible/client.ts
[error] 9-9: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
src/features/profile-configuration/components/linktree-section.tsx
[error] 34-34: Avoid using unnecessary Fragment.
A fragment is redundant if it contains only one child, or if it is the child of a html element, and is not a keyed fragment.
(lint/complexity/noUselessFragments)
[error] 50-50: Avoid using unnecessary Fragment.
A fragment is redundant if it contains only one child, or if it is the child of a html element, and is not a keyed fragment.
(lint/complexity/noUselessFragments)
[error] 66-66: Avoid using unnecessary Fragment.
A fragment is redundant if it contains only one child, or if it is the child of a html element, and is not a keyed fragment.
(lint/complexity/noUselessFragments)
[error] 82-82: Avoid using unnecessary Fragment.
A fragment is redundant if it contains only one child, or if it is the child of a html element, and is not a keyed fragment.
(lint/complexity/noUselessFragments)
src/common/contracts/tokens/non-fungible/client.ts
[error] 29-29: Don't use '{}' as a type.
Prefer explicitly define the object shape. '{}' means "any non-nullable value".
(lint/complexity/noBannedTypes)
🔇 Additional comments (123)
.vscode/settings.json (1)
84-85: Addition of domain-specific terms looks goodIncluding “Metaverse” and “Mochi” in the custom dictionary will prevent false-positive spell-check warnings during development. 👍
src/features/donation/models/effects/campaign-ft-donation.ts (1)
69-70: Comment-only changes acknowledgedThe switch from
*?to**inside the block-comments is purely cosmetic and has no runtime effect. Nothing else changed, so there are no concerns from a correctness, performance, or security standpoint.Also applies to: 83-85, 95-97, 109-111, 136-138, 155-157, 174-176, 192-194, 210-212, 265-267
src/features/donation/models/effects/direct-ft-donation.ts (1)
61-63: Comment-only changes acknowledgedSame here—the prefix tweak in the JSDoc blocks is non-functional. The underlying multicall logic remains intact.
Also applies to: 75-77, 87-89, 113-115, 132-134, 151-153, 169-171, 223-225
src/common/types.ts (1)
46-48: LGTM! Clean type additions that follow existing patterns.Both
ByContractAccountIdandLiveUpdateParamsare well-structured type definitions that maintain consistency with existing patterns in the file. The additions support the profile configuration functionality without introducing breaking changes.Also applies to: 94-96
src/common/lib/object.ts (1)
1-1: LGTM! Well-implemented utility function for data normalization.The
nullifyEmptyStringsfunction correctly usesmapValuesfrom remeda to transform empty strings to null values. The logic is sound and follows good patterns for data normalization, particularly useful for form data processing.Also applies to: 50-54
src/entities/_shared/account/constants.ts (3)
10-10: LGTM! Reasonable description length limit.The
ACCOUNT_PROFILE_DESCRIPTION_MAX_LENGTHconstant of 1500 characters provides a good balance between allowing detailed descriptions while preventing excessively long content.
14-15: LGTM! Good migration to IPFS for placeholder images.Moving from local asset endpoints to IPFS URLs improves decentralization and reduces dependency on local assets. The URLs are properly structured and should provide reliable access to placeholder images.
Also applies to: 19-20
31-33: Regex patterns look correct but verify the website pattern.The updates are accurate:
- Twitter regex correctly includes both
x.comandtwitter.comdomains- Telegram regex properly uses
t.meinstead of the incorrectt.com- Website regex
^(?:https?:\/\/)?([^/]+)$accepts any domain after optional protocolHowever, the website regex might be too permissive as it accepts any non-slash characters as a domain, potentially allowing invalid domains like
localhostor malformed URLs.Consider testing the website regex with edge cases:
#!/bin/bash # Test website regex pattern with various inputs echo "Testing website regex pattern..." # Test cases test_urls=( "https://example.com" "http://example.com" "example.com" "localhost" "192.168.1.1" "invalid..domain" "" "https://" ) for url in "${test_urls[@]}"; do if [[ "$url" =~ ^(https?://)?([^/]+)$ ]]; then echo "✓ '$url' matches" else echo "✗ '$url' does not match" fi donesrc/entities/voting-round/model/types.ts (1)
2-2: LGTM! Good refactoring to use more specific imports.The import path update from
"@/entities/_shared"to"@/entities/_shared/token"improves code organization by using more specific imports for token-related types, aligning with the broader modularization effort.src/entities/list/components/ListAccounts.tsx (1)
6-6: LGTM! Consistent refactoring to use more specific imports.The import path update from
"@/entities/_shared"to"@/entities/_shared/account"follows the same modularization pattern seen across the codebase, improving organization by using more specific imports for account-related constants.src/features/donation/components/single-recipient-success-share.tsx (1)
16-16: Import-path migration looks correct, but double-check repo-wide consistency
useAccountSocialProfileis now imported from the new@/entities/_shared/accountbarrel – good.
Please run a quick check to ensure no lingering references to the old root module remain; stray imports will break the TS build.#!/usr/bin/env bash # Detect obsolete imports that still point to the old barrel. rg --line-number --fixed-strings '"@/entities/_shared"' | head -n 20src/entities/list/components/AccountCard.tsx (1)
34-34: Moved import path – confirm all symbols are re-exported
ACCOUNT_LIST_REGISTRATION_STATUS_OPTIONS,AccountHandle,AccountProfileCover, andAccountProfilePicturemust all be exported from@/entities/_shared/account.
If any were missed in the re-export, this will surface as a compile-time error.src/pages/profile/[accountId]/home.tsx (1)
15-15: Import path update acknowledgedThe switch to the
accountsub-module aligns with the repo’s new structure.src/pages/pot/[potId]/applications.tsx (1)
17-17: Type imports updated – looks goodNo behavioural impact; compile-time only.
src/entities/list/hooks/registrations.ts (1)
6-9: Hook import path migrated successfullyNothing else to flag here.
src/entities/_shared/account/types.ts (1)
48-48: LGTM! JSDoc formatting improvement.Good catch on the JSDoc comment formatting - changing from
*?to**follows standard conventions.src/features/donation/components/group-allocation-success.tsx (1)
23-23: Migration to useFungibleToken looks correct.The import and hook usage have been properly updated to use the new
useFungibleTokenhook with the correct API parameters.Also applies to: 66-66
src/entities/_shared/token/hooks/_deprecated.ts (1)
6-6: Deprecated hook properly updated.Good practice updating the deprecated hook's references and documentation to point to the new
useFungibleTokenhook.Also applies to: 9-9
src/features/pot-application/hooks/clearance.ts (1)
11-11: Migration correctly implemented.The
useFungibleTokenhook is properly called with bothbalanceCheckAccountIdandtokenIdparameters, matching the new API.Also applies to: 34-37
src/entities/voting-round/hooks/voter-profile.ts (1)
10-10: Migration looks correct, but consider the type assertion.The migration to
useFungibleTokenis properly implemented with theenabledparameter preventing execution whentokenIdis undefined. The type assertiontokenId as TokenIdis acceptable here since the hook only runs whentokenId !== undefined.Also applies to: 37-40
src/features/profile-configuration/components/dao-progress.tsx (1)
5-5: LGTM! Component renaming aligns with profile configuration migration.The renaming from
ProfileSetupDaoProgresstoProfileConfigurationDaoProgressis consistent with the broader refactoring to standardize "ProfileConfiguration" terminology across the codebase.src/features/proportional-funding/components/payout-manager.tsx (2)
10-10: LGTM! Hook import updated for token refactoring.The migration from
useTokentouseFungibleTokenaligns with the broader token hook refactoring across the codebase.
26-28: LGTM! Hook usage maintains compatible interface.The
useFungibleTokenhook call uses the same parameters and returns compatible data structure with the expectedisMetadataLoadinganddataproperties.src/features/donation/components/campaign-success-share.tsx (1)
15-15: LGTM! Import path updated for better modularization.The change from
"@/entities/_shared"to"@/entities/_shared/account"reflects improved code organization by importing from more specific submodules rather than the shared root.src/common/_config/production.env-config.ts (1)
68-68: Profile configuration feature enabled in production.This change enables the profile configuration feature for production users. Ensure that the feature has been thoroughly tested and all related components are ready for production use.
Consider verifying that all profile configuration components and functionality work correctly in the production environment before this change is deployed.
src/entities/_shared/token/components/value-summary.tsx (2)
8-8: LGTM! Import updated for token hook refactoring.The import change from
"../hooks/data"to"../hooks/fungible"aligns with the token hook refactoring to use more specific fungible token handling.
22-22: LGTM! Hook usage maintains compatible interface.The
useFungibleTokenhook call maintains the same interface and returns compatible data structure with the expecteddataproperty containing token metadata.src/common/constants.ts (1)
171-176: Deprecation note is updated, but the symbol is still exported – check for lingering usages
SUPPORTED_FTSis explicitly marked as deprecated yet remains in the public surface. Before the next release, consider:
- Auditing the codebase for any runtime references.
- Migrating callers to
useFungibleTokenAllowlist.- Moving the constant behind an
__INTERNAL__namespace or deleting it when no longer needed.#!/bin/bash # List all remaining references to the deprecated constant (case-sensitive). rg --no-heading --line-number 'SUPPORTED_FTS' | grep -v 'common/constants.ts'src/common/contracts/tokens/index.ts (1)
2-2: ```shell
#!/bin/bashCheck for duplicate named exports in fungible and non-fungible index.ts barrels
declare -A export_counts
for module in fungible non-fungible; do
barrel="src/common/contracts/tokens/${module}/index.ts"
if [[ ! -f "$barrel" ]]; then
echo "⚠️ File not found: $barrel" >&2
continue
fi1) Direct exports: const, let, var, function, class, enum, type, interface
ast-grep --pattern 'export $modifier? (const|let|var|function|class|enum|type|interface) $name' "$barrel"
| awk '{print $NF}'
| while read name; do
export_counts["$name"]=$((export_counts["$name"] + 1))
done2) Re-export lists: export { A, B as C }
rg -h "export {[^}]+}" "$barrel"
| sed -E 's/.{([^}]+)}./\1/'
| tr ',' '\n'
| sed -E 's/ as [^,]+//g; s/ //g'
| while read name; do
export_counts["$name"]=$((export_counts["$name"] + 1))
done
donePrint any export names appearing in both modules (count > 1)
for name in "${!export_counts[@]}"; do
if [[ ${export_counts[$name]} -gt 1 ]]; then
echo "$name"
fi
done | sort</details> <details> <summary>src/entities/_shared/token/index.ts (1)</summary> `8-8`: **Barrel target switched – sweep for stale `hooks/data` imports** Down-stream imports referencing `"@/entities/_shared/token/hooks/data"` will now break. A quick grep will catch stragglers. ```shell #!/bin/bash rg --no-heading --line-number '"@/entities/_shared/token/hooks/data"'src/features/profile-configuration/types.ts (1)
1-1: LGTM – concise, future-proof union typeStraightforward alias. Documenting the allowed modes in JSDoc would aid IDE hover, but that’s optional.
src/pages/pot/[potId]/payouts.tsx (1)
31-31: Updated import aligns with new hook nameThe barrel now provides both
TokenIconanduseFungibleToken; import shape is correct. No further action.src/common/_config/staging.env-config.ts (1)
68-68: LGTM: Feature flag activation for profile configurationThe ProfileConfiguration feature flag has been correctly enabled in the staging environment, aligning with the broader refactor from profile setup to profile configuration.
src/entities/voting-round/components/WinnerRow.tsx (2)
17-17: LGTM: Consistent hook migrationThe import has been correctly updated to use the more specific
useFungibleTokenhook as part of the systematic token hook refactor.
34-34: LGTM: Hook usage updated correctlyThe hook call has been properly migrated to
useFungibleTokenwith the same parameter pattern. The hook defaults (enabled: true,live: false) are appropriate for this use case.src/entities/_shared/token/components/balance.tsx (2)
5-5: LGTM: Hook import updatedThe import has been correctly updated to use the more specific
useFungibleTokenhook.
14-18: LGTM: Improved balance component with live updatesThe hook migration is well-executed with the addition of
live: true, which is perfect for a balance component where users expect real-time updates. The parameter structure is correct and maintains the existing functionality while adding enhanced capabilities.src/features/profile-configuration/index.ts (1)
1-1: LGTM: Clean barrel export patternThe export statement follows standard module organization practices, properly exposing the editor components through the feature's main entry point.
src/features/donation/components/single-recipient-allocation.tsx (2)
26-26: LGTM: Consistent token hook migrationThe import has been correctly updated to use
useFungibleTokenas part of the systematic refactor to more specific token hooks.
49-52: LGTM: Hook usage properly migratedThe hook call has been correctly updated to use
useFungibleTokenwith appropriate parameters. ThetokenIdandbalanceCheckAccountIdparameters maintain the existing functionality while leveraging the enhanced capabilities of the new hook.src/entities/campaign/hooks/forms.ts (1)
15-15: LGTM! Clean token hook refactor.The migration from
useTokentouseFungibleTokenis well-executed and maintains API compatibility. The hook call correctly passes thetokenIdparameter and the returned data structure remains consistent for accessingtoken?.metadata.decimals.Also applies to: 67-69
src/pages/register.tsx (1)
12-12: LGTM! Successful migration to new profile configuration system.The replacement of
ProfileSetupFormwithProfileEditormaintains the same props interface while providing enhanced functionality. The component correctly receives all required props (mode,accountId,isDaoRepresentative,onSuccess,onFailure).Also applies to: 99-104
src/entities/_shared/account/index.ts (1)
24-24: LGTM! Proper exposure of linktree utilities.The export addition follows the established pattern and provides necessary utilities for social link normalization across the profile configuration features.
src/entities/post/components/PostEditor.tsx (1)
14-17: LGTM! Correct implementation with accessibility improvement.The update to use
avatar.urlcorrectly implements the newuseAccountSocialProfilehook interface. The improvement of the alt text from an empty string to "Your avatar" enhances accessibility compliance.Also applies to: 39-40
src/entities/_shared/token/components/icons.tsx (1)
8-8: LGTM! Consistent token hook refactor implementation.The migration from
useTokentouseFungibleTokenis correctly implemented, maintaining the same interface for accessing token metadata properties (icon,name,symbol).Also applies to: 32-32
src/entities/pot/components/PotCard.tsx (1)
9-9: LGTM: Consistent token hook refactorThe migration from
useTokentouseFungibleTokenis correctly implemented:
- Import statement properly updated
- JSDoc documentation updated to reflect the new hook capabilities
- Hook usage maintains the same interface with
tokenId: NATIVE_TOKEN_IDThis change aligns with the broader codebase refactor to use more specific fungible token hooks.
Also applies to: 24-24, 27-27
src/features/donation/components/single-recipient-success.tsx (1)
21-21: LGTM: Token hook refactor correctly appliedThe migration to
useFungibleTokenis properly implemented:
- Import statement correctly updated to include
useFungibleTokenfrom the shared token module- Hook usage maintains the same
{ tokenId }parameter structure- No breaking changes to the component logic
Also applies to: 92-92
src/entities/campaign/components/CampaignDonorsTable.tsx (1)
13-13: LGTM: Consistent token hook migrationThe refactor to
useFungibleTokenis correctly implemented:
- Import statement properly consolidates
TokenIconanduseFungibleTokenfrom the shared token module- Hook usage preserves the existing fallback logic (
campaign?.ft_id ?? NATIVE_TOKEN_ID)- No changes to component behavior or data flow
Also applies to: 20-20
src/entities/pot/components/PotDonationEntry.tsx (1)
59-59: LGTM: Avatar data structure update correctly appliedThe changes properly update avatar image access from direct string properties to nested object structure:
donorProfile.avatarSrc→donorProfile.avatar.urlrecipientProfile.avatarSrc→recipientProfile.avatar.urlThis change is consistent with the broader profile image refactor mentioned in the AI summary. The implementation assumes
useAccountSocialProfilereturns the expected nested structure.Also applies to: 71-71
src/entities/campaign/components/editor.tsx (1)
17-17: LGTM: Comprehensive token hook migrationThe migration to
useFungibleTokenis well-implemented:
- Import statement correctly updated to use the new hook
- Hook usage makes proper use of both
tokenIdandbalanceCheckAccountIdparameters- Preserves the existing token selection logic with fallback chain (
existingData?.ft_id ?? ftId ?? NATIVE_TOKEN_ID)- Enables balance checking functionality for the wallet user
This demonstrates good utilization of the enhanced capabilities provided by
useFungibleToken.Also applies to: 52-55
src/features/donation/components/group-allocation.tsx (2)
24-29: LGTM: Import refactoring improves modularityThe change from
useTokentouseFungibleTokenand the more specific import path enhances code clarity and module organization.
59-62: LGTM: Hook usage maintains compatibilityThe transition to
useFungibleTokenpreserves the existing API while providing more specialized token handling functionality.src/features/donation/hooks/form.ts (2)
16-16: LGTM: Consistent import refactoringThe import change aligns with the systematic refactoring to use more specific token hooks.
134-137: LGTM: Hook refactoring maintains API consistencyThe
useFungibleTokenusage preserves the same parameter structure and return value handling as the previoususeTokenimplementation.src/entities/voting-round/hooks/results.ts (2)
11-11: LGTM: Import refactoring follows established patternThe change to
useFungibleTokenimport is consistent with the codebase-wide refactoring to more specific token handling.
26-33: LGTM: Hook refactoring preserves complex conditional logicThe transition to
useFungibleTokenmaintains the existing conditional enablement and tokenId selection logic without any functional changes.src/entities/campaign/components/CampaignSettings.tsx (2)
14-14: LGTM: Consistent token hook import refactoringThe import change to
useFungibleTokenaligns with the systematic migration to specialized token hooks across the application.
64-64: LGTM: Hook usage maintains fallback logicThe
useFungibleTokencall preserves the existing fallback toNATIVE_TOKEN_IDand maintains the same usage pattern.src/features/donation/components/group-allocation-recipients.tsx (2)
8-9: LGTM: Import refactoring improves module organizationBoth import changes enhance code organization:
AccountListItemis properly sourced from the account module, anduseFungibleTokenfollows the established token hook refactoring pattern.
28-31: LGTM: Hook refactoring maintains existing functionalityThe transition to
useFungibleTokenpreserves the same parameter structure and doesn't impact the token data usage throughout the component.src/entities/campaign/components/CampaignProgressBar.tsx (1)
12-12: LGTM! Clean migration to fungible token hook.The import and usage update from
useTokentouseFungibleTokenis consistent with the systematic refactor across the codebase. The hook interface remains compatible and the change maintains the existing functionality.Also applies to: 34-34
src/entities/pot/components/PotDonationStats.tsx (1)
9-9: LGTM! Consistent migration to fungible token hook.The migration from
useTokentouseFungibleTokenis properly implemented with native token ID usage. Both hook calls maintain the expected functionality for fetching native token data.Also applies to: 27-27, 81-81
src/entities/_shared/token/components/selector.tsx (1)
15-15: LGTM! Comprehensive migration to fungible token hooks.The migration to
useFungibleTokenanduseFungibleTokenAllowlistis properly implemented. The hook usage patterns remain consistent with the previous implementation while adopting the new fungible token-specific naming convention.Also applies to: 29-32, 71-73
src/common/contracts/tokens/fungible/client.ts (1)
1-1: LGTM! Structural improvement for HTTP client access.The change to access
naxiosInstancethroughnearProtocolClientimproves consistency with the architectural pattern used in other token client modules.Also applies to: 7-7, 13-13
src/pages/profile/[accountId]/edit.tsx (1)
12-12: LGTM! Clean migration from profile setup to profile configuration.The replacement of
ProfileSetupFormwithProfileEditormaintains the same component interface and props, ensuring a smooth transition to the new profile configuration system.Also applies to: 104-109
src/layout/profile/_deprecated/DonationItem.tsx (3)
1-1: LGTM: Import change aligns with Big.js usage patterns.The change from default import to named import is correct and consistent with modern JavaScript practices.
106-108: LGTM: Hook destructuring updated to match new API.The change from
avatarSrctoavatarcorrectly aligns with the refactoreduseAccountSocialProfilehook that now returns image objects instead of direct URL strings.
115-115: LGTM: Image source updated to use new avatar structure.The change to
avatar.urlis consistent with the new hook API structure that provides avatar and cover objects containing URLs.src/entities/_shared/account/utils/linktree.ts (1)
7-13: LGTM: Well-structured URL extraction utility.The function correctly uses regex patterns to extract identifiers from URLs and handles edge cases appropriately. The logic to return the first captured group or the original URL is sound.
src/entities/campaign/components/CampaignBanner.tsx (3)
19-19: LGTM: Hook refactoring aligns with codebase modernization.The change from
useTokentouseFungibleTokenis consistent with the broader token hook refactoring across the codebase for better semantic clarity.
110-113: LGTM: CSS class improvements enhance readability.The use of
cnutility for class composition and the simplified flex/text styling improve code maintainability.
183-188: LGTM: Consistent notification styling with cn utility.The refactoring to use the
cnutility for class name composition improves readability and maintainability without changing functionality.src/entities/_shared/account/components/AccountFollowStats.tsx (4)
1-1: LGTM: Import added for memoization.The useMemo import is correctly added to support the new memoized followPageUrl.
11-17: LGTM: Defensive programming with default empty arrays.Providing default empty arrays prevents potential undefined errors and makes the component more robust.
19-22: LGTM: Memoized URL construction improves performance.The memoization of followPageUrl prevents unnecessary recalculations and provides a proper base URL for Near Social profile links.
26-31: LGTM: Enhanced user experience with functional external links.The conditional rendering and external links to Near Social profile pages with appropriate query parameters provide better functionality. Opening in new tabs is appropriate for external navigation.
src/common/services/pinata/hooks.ts (2)
53-53: LGTM: New callback enhances file upload flexibility.The
handleFileBufferChangecallback provides an alternative interface for file uploads while maintaining consistency with the existing upload logic and error handling patterns.
57-57: LGTM: Consistent API extension.The new callback is properly included in the return object, maintaining API consistency and providing users with both input change and buffer change options.
src/features/profile-configuration/models/types.ts (1)
1-7: LGTM! Clean type definitions using schema derivation.The type definitions are well-structured and follow the established pattern of deriving TypeScript types from validation schemas using the
FromSchemautility. This ensures type safety and consistency between validation logic and type definitions.src/common/contracts/tokens/non-fungible/hooks.ts (1)
14-16: LGTM! Proper conditional SWR key generation.The conditional key generation correctly checks both the
enabledflag andIS_CLIENTto prevent unnecessary requests on the server side or when disabled.src/common/contracts/tokens/non-fungible/index.ts (1)
1-7: LGTM! Clean module organization following established patterns.The index file properly organizes the NFT module exports with clear namespace separation for client and hooks, while making types and interfaces directly available. This follows the established pattern used in other token modules.
src/common/api/near-social-indexer/hooks.ts (2)
6-6: LGTM! Added necessary import for the updated client usage.The addition of
nearSocialClientimport supports the updated hook implementation.
13-18: LGTM! Improved API usage with direct key queries.The changes improve the hook by:
- Using a dynamic SWR key with template literals for better cache management
- Switching from POST requests to direct
keysqueries withvaluesOnlyflag- Maintaining the same result format with
Object.keys(result)This aligns with the newer client interface and should be more efficient.
src/layout/profile/components/summary.tsx (3)
24-24: LGTM! Updated import to include the new donation button component.The import correctly adds
DonateToAccountButtonwhile keeping the existinguseDonationUserFlowimport.
196-206: LGTM! Improved conditional rendering with explicit null check.The change from optional chaining (
fundingAccount?.) to explicit existence check (fundingAccount &&) makes the conditional rendering more explicit and clear.
209-209: LGTM! Replaced manual button with reusable component.The replacement of manual donation button logic with the
DonateToAccountButtoncomponent improves code reusability and maintainability. Thevariant="brand-filled"prop properly customizes the button appearance for this context.src/common/ui/form/components/text.tsx (1)
25-25: LGTM! Well-implemented inputExtension styling support.The changes correctly add support for customizable
inputExtensionstyling:
- Consistent property naming in the
classNamestype- Proper use of the
cnutility for class composition- Correct dependency array update in the
useMemohookAlso applies to: 90-93, 103-103
src/features/donation/components/user-entrypoints.tsx (1)
4-4: LGTM! Clean enhancement to button component flexibility.The changes properly add variant support to
DonateToAccountButton:
- Correct TypeScript typing using
Pick<ButtonProps, "variant">- Sensible default fallback to
"standard-outline"- Maintains backward compatibility while enabling customization
Also applies to: 41-58
src/features/profile-configuration/components/contract-modal.tsx (2)
17-17: LGTM! Consistent renaming from ProfileSetup to ProfileConfiguration.The type imports and component renaming are consistent with the broader refactoring effort from "ProfileSetup" to "ProfileConfiguration" paradigm.
Also applies to: 20-29
16-16: Verify the import path change for CustomInput.The import path changed from
"./form-elements"to"./editor-elements". Please ensure thatCustomInputis correctly exported from the new location.#!/bin/bash # Description: Verify that CustomInput is exported from the new location # Expected: CustomInput should be found in editor-elements file fd "editor-elements" --type f --exec grep -l "CustomInput" {}src/entities/_shared/account/hooks/social-profile.ts (1)
8-8: To be sure no references to the old properties remain, let’s search the entire codebase foravatarSrcorbackgroundSrc.#!/bin/bash # Description: Look for any remaining usages of the old return properties rg -n "(avatarSrc|backgroundSrc)" --glob "*.[jt]s*"src/common/ui/layout/components/molecules/multi-select.tsx (2)
69-69: LGTM! Important dependency array fixes.The updated dependency arrays correctly include all referenced variables:
- Line 69: Added missing
onValueChangeandvaluedependencies- Line 119: Added missing
onValueChangedependencyThese fixes prevent potential stale closure bugs where callbacks wouldn't update when dependencies change.
Also applies to: 119-119
137-137: LGTM! Clean styling updates.The styling changes improve the component's visual consistency:
- Removed unnecessary
space-y-2utility- Updated border color to neutral gray
- Improved border radius and padding
- Enhanced className readability without functional changes
Also applies to: 160-160, 241-244
src/features/profile-configuration/models/schemas.ts (1)
31-45: Schema structure and validation rules look good.The renaming to
profileConfigurationSchemaand the field updates are well-implemented. MakingprofileImageoptional and using the imported constant for description max length improves maintainability.src/entities/_shared/account/components/profile-images.tsx (2)
18-31: Component correctly adapts to new data structure.The update to use
avatar.urlproperly aligns with the refactoreduseAccountSocialProfilehook that returns avatar and cover objects instead of simple strings.
47-66: Cover component implementation looks correct.The component properly uses the new
cover.urlstructure and maintains the same functionality with improved code clarity.src/features/profile-configuration/components/image-upload.tsx (1)
22-40: File upload implementation looks solid.The component properly handles file uploads with appropriate callbacks, error handling via toast notifications, and loading states. The use of
useCallbackfor the success handlers is a good practice.src/features/profile-configuration/models/effects.ts (2)
58-85: Conditional social actions logic is well-implemented.The conditional inclusion of auto-follow and star actions only during "register" mode is a logical improvement. This prevents these actions from being repeated during profile updates, which makes sense from a user experience perspective.
18-21: Type updates and imports look correct.The renaming to
ProfileConfigurationMode,ProfileConfigurationInputs, and the updated normalization function import align well with the broader refactoring effort.src/features/profile-configuration/components/funding-sources.tsx (1)
100-107: Type renaming is consistent and correct.The updates from
ProfileSetupInputsandProfileSetupFundingSourcesTableto theirProfileConfigurationcounterparts are consistent with the broader refactoring effort.src/features/profile-configuration/components/AddFundingSourceModal.tsx (1)
3-3: LGTM! Good refactoring of imports and types.The transition from ProfileSetup to ProfileConfiguration naming is consistent, and using TextAreaField from the common UI library improves standardization.
Also applies to: 16-16
src/entities/_shared/account/hooks/social-image.ts (1)
14-44: Well-designed hook with good performance optimization.The hook effectively handles multiple image source types with proper memoization to prevent unnecessary recalculations. The prioritization logic (NFT media → raw image → fallback) is sound.
src/features/profile-configuration/components/repositories-section.tsx (1)
6-7: LGTM! Consistent import updates.The import changes from
form-elementstoeditor-elementsand the type update toProfileConfigurationInputsare consistent with the overall refactoring.src/features/profile-configuration/components/editor-elements.tsx (2)
4-4: Excellent refactoring to standardize UI components.The transition from custom label components to the shared
FormLabelcomponent improves consistency across the application and reduces code duplication.Also applies to: 60-63, 111-114
1-1: Good cleanup of unused imports.Removing the unused
CSSPropertiesandTextareaimports keeps the code clean.src/entities/_shared/token/hooks/fungible.ts (2)
35-40: Excellent addition of live update support.The new
liveparameter enables real-time balance updates, which is valuable for token balance displays. The parameter is properly typed and defaults tofalsefor backward compatibility.
16-16: Good hook renaming for clarity.Renaming
useTokenAllowlisttouseFungibleTokenAllowlistmakes the hook's purpose more explicit and distinguishes it from potential non-fungible token allowlists.src/features/profile-configuration/components/linktree-section.tsx (2)
9-18: Well-designed reusable component.The
FieldInputExtensioncomponent provides consistent styling for URL prefixes across all social media fields. Good use of utility classes and proper prop handling.
24-92: Consistent form field implementation.The component follows a clean, consistent pattern for all social media platforms with appropriate input extensions and placeholders. The integration with react-hook-form is properly implemented.
src/features/profile-configuration/components/contracts-section.tsx (2)
23-38: Well-implemented styled Label component.The Label component provides a clean abstraction for consistent paragraph styling with proper prop handling and style overrides.
200-208: Consistent renaming from ProfileSetup to ProfileConfiguration.The type and component name changes align with the broader refactor across the profile configuration feature. The functionality remains unchanged.
src/common/contracts/tokens/non-fungible/interfaces.ts (1)
1-120: Excellent implementation of NEP-177 NFT interfaces.The interfaces correctly implement the NEAR NFT standard with:
- Proper nullable field types for optional metadata
- Comprehensive documentation with standard references
- Consistent typing using AccountId from common types
- Well-structured separation of token, contract metadata, and lookup params
src/common/contracts/tokens/fungible/hooks.ts (2)
13-18: Improved API withenabledflag.The change from
disabledtoenabledprovides a more intuitive API while maintaining the same functionality with proper default values.
20-40: Well-implemented live update control.The
liveparameter provides granular control over SWR revalidation behavior:
- When
live=false: Disables automatic revalidation (stale, focus, reconnect)- When
live=true: Uses default SWR behavior- Proper conditional spreading of SWR options
src/features/profile-configuration/utils/normalization.ts (2)
8-13: Clean functional approach to URL normalization.The
stripLinktreefunction usesevolveeffectively to apply consistent URL extraction across all social platforms. Good use of the functional programming paradigm.
15-41: Well-structured data transformation function.The
profileConfigurationInputsToSocialDbFormatfunction handles:
- Standard NEAR Social fields with proper conditional inclusion
- Clean functional pipeline for linktree normalization
- Appropriate JSON serialization for complex POTLOCK fields
- Proper handling of optional fields to avoid undefined values
src/common/blockchains/near-protocol/hooks.ts (2)
22-37: Excellent refactoring fromdisabledtoenabledpattern.The change from a
disabledflag to anenabledflag is more intuitive and aligns with common patterns. The SWR key function properly returnsnullwhen disabled, which correctly prevents the fetch.
39-65: Well-implemented live updates and client-side protection.The addition of the
liveparameter to control SWR revalidation behavior is a good enhancement. TheIS_CLIENTcheck prevents server-side execution issues. The conditional SWR options configuration is clean and effective.src/features/profile-configuration/models/deprecated.ts (1)
1-4: Ensure removal before release as indicated by TODO.The file is properly marked as deprecated with appropriate warnings. Make sure to remove this file before the final release as indicated by the TODO comment.
src/features/profile-configuration/components/editor.tsx (1)
83-93: Good memoization of submit button label.The
submitButtonLabelis properly memoized with correct dependencies, which optimizes re-renders.src/features/profile-configuration/hooks/forms.ts (1)
41-49: Smart NFT-aware image handling.The logic to handle NFT vs regular images is well-implemented, only using the URL when it's not an NFT. This prevents issues with NFT image display.
src/layout/profile/components/team.tsx (2)
1-10: LGTM on import additions.The new imports align well with the refactoring objectives and follow proper conventions.
57-71: LGTM on the team member rendering logic.The inline rendering approach is clean and the conditional logic properly handles both empty and populated states. The accessibility attributes and styling are appropriately applied.
Summary by CodeRabbit
New Features
Enhancements
Bug Fixes
Refactor
Chores