Month Manager

Why I built it

I built Month Manager to practice frontend fundamentals with a problem that required forms, derived values, state management, and persistence—not just a static interface.

What works today

Income and expense entry, validation, optional notes, date-sorted activity, monthly summaries, period switching, deletion, and local browser persistence work today.

What I wanted to learn

• Model data clearly with TypeScript.
• Keep React state and browser storage synchronized.
• Build responsive, accessible forms and controls.

How it works

1. Model each period with a stable month-and-year key.
2. Validate transaction amounts and dates before updating state.
3. Split forms, summaries, controls, and transaction views into focused React components.

Technical structure

React owns the interface and selected-period state. Typed transaction records are grouped under month keys and serialized to localStorage. Period changes load only the matching records into the dashboard.

Testing

• Automated component and persistence tests remain planned in the repository. The key regression scenarios are switching months without overwriting records, reloading persisted data, rejecting invalid amounts or out-of-month dates, and recalculating totals after deletion.

Technical decisions

• Use a month-keyed data model to make period isolation explicit.
• Keep persistence local for a private, dependency-free personal dashboard.
• Use small components and keyboard-friendly native controls instead of a large UI library.

Challenges

Keep the selected period, React state, and persisted browser data synchronized as users move between months.

What I learned

The project helped me reason about state transitions, validation boundaries, derived totals, browser persistence, and how small data-model choices affect the interface.

What I'd improve next

Add focused tests for persistence and period transitions, then explore optional data export.