Extract Settings screen logic into a dedicated `useSettingsScreen` hook

[D240021]

🔖 Title
Extract Settings screen logic into a dedicated useSettingsScreen hook

---

📄 Description
SettingsScreen currently mixes UI rendering with internal state and behavior (preferences state, toggle handlers, and animated toggle behavior). This issue introduces a dedicated hook to centralize screen logic and keep the screen component focused on presentation.

Create a useSettingsScreen hook that encapsulates all non-visual logic currently inside components/pages/SettingsScreen.tsx. After the refactor, SettingsScreen should keep only visual structure and bindings to values/handlers returned by the hook.

Scope includes extracting state, handlers, and any related logic into the hook while preserving existing behavior and UX. Scope excludes redesigning the settings UI, changing copy/content, or altering navigation flow beyond keeping the current onBack behavior.

Regression constraints:

• Preserve all current toggle behavior and initial preference values.
• Preserve current animation behavior for custom toggles.
• Preserve current onBack behavior and accessibility labels/roles.
• Follow existing TypeScript and hooks conventions in the repository.
• Avoid introducing any unless strictly justified.

Pull request (definition of done): The implementer must open the PR with the repository PR template fully completed, stating which parts of this issue were completed, checklist per what was done, screenshots/test evidence when required, and a link to this issue. Do not leave required sections empty.

Current structure:

• components/pages/SettingsScreen.tsx: contains both presentation and logic (prefs state, togglePref, animation setup in CustomToggle via Animated.Value and useEffect).

Target structure:

• hooks/settings/use-settings-screen.ts (or project-standard equivalent): exposes typed state and handlers required by SettingsScreen and the toggle UI behavior.
• components/pages/SettingsScreen.tsx: visual-only component consuming values and callbacks from useSettingsScreen.
• Optional: if needed for clarity, keep CustomToggle as a presentational component and pass in already-prepared values/handlers from the hook contract.

---

✅ Tasks to complete

• Review repository conventions and existing hook patterns in hooks/invest/use-invest.ts and hooks/auth/*
• Create useSettingsScreen hook with a typed return contract (interface/type) for all logic consumed by SettingsScreen
• Move current preferences state and toggle handler logic from components/pages/SettingsScreen.tsx into the new hook
• Move/organize toggle-related behavior so SettingsScreen remains presentation-focused
• Refactor components/pages/SettingsScreen.tsx to consume only hook outputs and render UI
• Keep TypeScript strictness and avoid any unless justified
• Add or update tests for extracted hook logic if test coverage exists for this area; otherwise add minimal targeted tests where feasible
• Lint and tests passing; fix regressions introduced by this change
• Open PR with the full repo template: specify what was completed for this issue, checklist/screenshots per template, and link to this issue
• Manual regression: open Settings screen, toggle each switch multiple times, confirm animations and labels still behave the same, and verify back navigation still works

---

📚 Documentation/context for AI

• components/pages/SettingsScreen.tsx
• hooks/invest/use-invest.ts
• hooks/auth/use-create-account.ts
• hooks/auth/use-sign-in.ts
• components/shared/MainLayout.tsx
• theme/colors.json
• Repository PR template (.github/pull_request_template.md or equivalent location)

---

🗒️ Additional notes

• Keep the change focused on separation of concerns (logic vs. UI), not feature expansion.
• Minimal internal refactors are allowed only if needed to support clean hook extraction.
• Do not modify unrelated screens or shared layout behavior.
• PRs with incomplete template sections are not acceptable.

---

🎨 Design Reference

No design changes requested; keep current visual output unchanged.

[Arome8240]

@Arome8240 has applied to work on this issue as part of the Stellar Wave Program's 3rd wave.

Hello, I'm a smart contract and full stack developer, open for contributions. contributed to over 20 project on OnlyDust and Drips , with expertise in Solidity, Cairo, JavaScript, TypeScript, and RUST. I am passionate about building secure and scalable blockchain solutions, and I would love the opportunity to contribute my skills toward solving this issue.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Arome8240 to this issue.

[drips-wave]

Congratulations, @Arome8240! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on March 30, 2026.

🧑‍💻 @Arome8240: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊