Description — what to implement and the why/impact.
Group expenses often involve different currencies or custom split ratios (percentage, shares, and exact amounts). This issue implements a robust expense split calculation engine and preview component so users can verify how much each participant owes before submitting the expense to the Stellar network.
Context & Requirements — background, constraints, design references, edge cases; grounded in the actual repo (real files, stack, conventions).
Calculations must be precise, avoiding floating-point rounding issues when splitting bills among multiple participants. The component should live in src/components/expenses/ and use Zustand (src/store/) or local React state to compute shares dynamically. All data structures must align with src/lib/types.ts.
Acceptance Criteria — a checklist ("- [ ] ...") of specific, testable conditions that define "done".
Implementation Guidance — likely files/modules to touch (use real paths from the repo context) and a suggested approach, without over-prescribing.
- Review utility patterns in
src/lib/.
- Implement calculation helper functions with unit tests.
- Use Tailwind CSS classes consistent with the neobrutalist design system.
Testing & Validation — how the contributor should prove it works (tests to add/run, manual checks, screenshots for UI).
- Add unit tests covering various split combinations and edge cases (e.g., uneven division of pennies).
- Run
npm test to verify test suite execution.
Submission Guidelines — must open a PR that includes "Closes #"; assignment is required before starting; follow the repo's existing style and conventions.
Wave complexity: Medium
Description — what to implement and the why/impact.
Group expenses often involve different currencies or custom split ratios (percentage, shares, and exact amounts). This issue implements a robust expense split calculation engine and preview component so users can verify how much each participant owes before submitting the expense to the Stellar network.
Context & Requirements — background, constraints, design references, edge cases; grounded in the actual repo (real files, stack, conventions).
Calculations must be precise, avoiding floating-point rounding issues when splitting bills among multiple participants. The component should live in
src/components/expenses/and use Zustand (src/store/) or local React state to compute shares dynamically. All data structures must align withsrc/lib/types.ts.Acceptance Criteria — a checklist ("- [ ] ...") of specific, testable conditions that define "done".
ExpenseSplitPreview.tsxinsrc/components/expenses/showing itemized participant breakdowns.npm run typecheckandnpm test.Implementation Guidance — likely files/modules to touch (use real paths from the repo context) and a suggested approach, without over-prescribing.
src/lib/.Testing & Validation — how the contributor should prove it works (tests to add/run, manual checks, screenshots for UI).
npm testto verify test suite execution.Submission Guidelines — must open a PR that includes "Closes #"; assignment is required before starting; follow the repo's existing style and conventions.
Wave complexity: Medium