Refactor: Modernize budget viewer state with Signals

[EstherNyumu]

For this PR, I refactored the budget UI components from an Observable-driven pattern to Angular Signals. I replaced constructor DI with inject(), converted the consumed Observables using toSignal(), moved derived logic into computed(), and replaced subscription handling with a single effect(). The child component was also updated to accept a Signal input and remove all RxJS subscription logic.

This modernization simplifies state flow, removes memory-leak risks, and enables fine-grained UI updates.

The benefit of using signals is:

• No subscriptions or cleanup needed
• Cleaner UI state management
• Only the parts of the UI depending on a specific signal re-render.
• It is easier to follow compared to pipelines of RxJS operators.

The difference in the coding styles is RxJS uses a stream-based approach focused on composing asynchronous event sequences with operators like map, switchMap, combineLatest, etc while signals use a state-based approach where each piece of data is a reactive value (signal, computed, effect) that updates synchronously.

Observables emit many values over time and require a subscription to start producing values. Signals hold a single value, update synchronously, and automatically notify dependent computations. Observables remain ideal for API streams and asynchronous workflows. Signals are better suited for component/UI state.

From mobile development, I’ve worked extensively with Kotlin Flow / StateFlow in Jetpack Compose and Flutter’s reactive state tools like mutableStateOf and Provider. These follow a declarative UI model where the UI reacts automatically to state changes. Angular Signals feel very similar to mutableStateOf in Compose. Compared to Flow or BLoC, Signals provide a lighter mental model for component-level state and reduce the overhead of managing async streams for simple UI rendering.