chore: resolved some todos

[hemantwasthere]

…or/cleanup

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

3 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
endur-client	Ignored			Nov 6, 2025 4:07pm
endur-client-mainnet-prerelease	Ignored			Nov 6, 2025 4:07pm
endur-client-testnet	Ignored			Nov 6, 2025 4:07pm

[NeelkanthTandel]

General Feedback

1. Each feature should have its own index.tsx, which serves as the main entry point after app/[feature_name]/page.tsx.

Any dynamic rendering for tokens like BTC and STRK should be handled in the index.tsx whenever possible.

The index.tsx file should only render child components specific to BTC and STRK.

All other components should be placed inside features/[feature_name]/components.

Example – Staking Feature (Main Landing Page):

features/staking/
├── index.tsx // Entry point
└── components/
├── TokenTabContent.tsx // Dynamic tab content (rename from TokenTab if clearer)
├── Stake.tsx
├── Unstake.tsx
├── WithdrawLogs.tsx

This structure should also apply to all the pages, like Portfolio, DeFi, and Leaderboard pages (except for parts requiring dynamic rendering).

2. The DeFi page should also follow the feature-based structure.

Move it from src/components to src/features/defi, similar to other features.

3. If feature-specific types are extracted into a separate file, place them in one of the following locations: (Your call, but the same thing should be maintained for every future change)

features/[feature_name]/types
src/types/[feature].types.ts

4. No need to keep the previous things commented, you can replace that
(this is not about comments - keep comments, and add solved at the end as you are doing now).
   Not sure if this is happening everywhere, but I saw it at a couple of places, especially in info tooltip changes.

[NeelkanthTandel]

I do not see any changes. Am I missing something?

[NeelkanthTandel]

What I meant:
If a function is only used within a component, define it locally instead of passing it as a prop.

For example, handleEmail defined in checkEligibility should be moved inside eligibilityModal, since it handles the modal’s input.
Keeping such logic self-contained improves component clarity and reduces unnecessary prop dependencies.

[NeelkanthTandel]

Strk tabContent and btc, both are the same and have the same content.
Move this to TabContent (not the current one, this one will be renamed to index.tsx, make a new file), and use this TabContent two times with prop [btc and strk] here in index.tsx

[hemantwasthere]

done

[NeelkanthTandel]

This is an unintentional change, I guess.
Anyway, revert all the changes in this file.

[hemantwasthere]

done

[NeelkanthTandel]

I wanted us to use the infoTooltip component wherever there is an (i) icon
Even the icon should be in this infoTooltip component, so that we just have to use this component where required. [This icon's class can be passed as props, and there can be a default class (styles) applied to this icon]

I didn't know we had two different tooltip designs
But still, we can achieve that by using dottedBorder props or any other approach to make the infotooltip generic with a conditional design
Can we do this? Let me know if it's still confusing

[hemantwasthere]

I wanted us to use the infoTooltip component wherever there is an (i) icon Even the icon should be in this infoTooltip component, so that we just have to use this component where required. [This icon's class can be passed as props, and there can be a default class (styles) applied to this icon]

I didn't know we had two different tooltip designs But still, we can achieve that by using dottedBorder props or any other approach to make the infotooltip generic with a conditional design Can we do this? Let me know if it's still confusing

did the changes, pls review once