[Frontend] useSettings holds per-instance state with no shared store or storage listener - settings changes don't propagate across components/tabs

[grantfox-oss]

Telegram (ask questions / claim the issue here first): https://t.me/+DOylgFv1jyJlNzM0

Why this matters

frontend/src/hooks/useSettings.ts:31-59 - each useSettings() call owns its own useState seeded from localStorage; the setters write localStorage but only update that one instance. There is no React context and no storage event listener, so changing decimalPlaces/amountFormat on the Settings page does not update amounts already rendered by other mounted components (or other tabs) until remount.

Acceptance criteria

• Back useSettings with a shared source of truth (Context/external store) so all consumers re-render on change
• Add a window storage event listener to sync settings across tabs
• Add tests asserting two consumers reflect an updated decimalPlaces without remount

Files to touch

• frontend/src/hooks/useSettings.ts

Out of scope

• Settings page useEffect missing dependency

[bfernando]

@bfernando has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I'd like to work on this because it is a focused frontend state consistency bug with clear acceptance criteria: make useSettings share one source of truth, sync across tabs through storage events, and prove multiple consumers update without remounting.

Relevant experience: React/TypeScript hooks, shared state patterns, browser storage synchronization, and writing focused frontend tests with careful AI-assisted implementation plus manual review.

Plan:

1. Inspect frontend/src/hooks/useSettings.ts and current consumers to preserve the public hook API.
2. Back the hook with a shared store/context-style subscription so mounted consumers re-render together.
3. Add a storage event listener for cross-tab updates while keeping localStorage persistence intact.
4. Add focused tests for two consumers reflecting decimalPlaces changes without remounting, then run the closest available checks.

I will stay within this issue, avoid unrelated Settings page dependency changes, link the PR back to the issue for Wave tracking, and include exact validation notes.

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

[Ajibose]

@Ajibose has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I would love to work on this

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

[DeePrincipal-dev-lang]

@DeePrincipal-dev-lang has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Can I take up on this task?!
I'll be glad to work on it and resolve it before the deadline
So kindly please assign it to me

ℹ️ Repo Maintainers: To accept this application, review their application or assign @DeePrincipal-dev-lang to this issue.

[d3v-active]

@d3v-active has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Please assign . you will get a pr today

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

[drips-wave]

Congratulations, @d3v-active! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @d3v-active: 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 🌊