Refactor: Modernize budget viewer state with Signals

[NyamburaSandra]

** Briefly explain how you went about this assignment and the key benefits of using Signals over the previous RxJS approach in this UI scenario.**

1. I began by examining how state flowed through the existing components. The original code relied heavily on RxJS streams, async pipes, and imperative subscriptions to combine data from. My first step was removing constructor-based DI and switching to Angular’s inject() API to align the components with a more modern and future-proof pattern.
2. Next, I converted all observable streams. This allowed each value to be stored synchronously and accessed directly within the component without subscribe() or async pipes. I then introduced a computed() signal so that derived state updates automatically whenever source signals change.
3. Finally, I updated the child component to accept Signals as inputs and removed all manual subscription and lifecycle synchronization code. This eliminated complexity and shifted the UI into a clean, declarative, fine-grained reactivity model.
4. Benefits include clear, predictable data flow without nested RxJS operators and easier template usage since signals hold a value synchronously

• Explain how you understand the difference in coding styles between the two.
When using RxJS, the coding style is more imperative and stream-based.

1. It create observable streams. Pipe and transform them. Subscribe to react to changes. Manage cleanup manually. Rely on async behavior even for simple state
2. Signals encourage a declarative and state-driven style, State exists as synchronous values. Any computed state automatically updates when dependencies change. No subscriptions or teardown logic. Components react automatically via computed() and effect()

• RxJS encourages thinking in terms of streams and operators, while signals encourage thinking in terms of state and reactivity, which is often more intuitive for UI development.
  • Explain how signals and observables works and if there’s a fundamental difference between the two.
  Signals
  Always hold a current value. Are synchronous and pull-based. Update values instantly. Trigger dependent computations automatically. Work naturally in templates
  Observables
  Don’t hold values by default. Are asynchronous and push-based. Require subscriptions to access values. Use operators to transform data. Suitable for event streams, multi-value sequences, or async sources
  Signals represent state, while Observables represent asynchronous data streams. Signals excel in UI state management. Observables excel in handling things like HTTP requests, user events, and data streams.
  They complement each other, and Angular now provides tools (toSignal, fromSignal) to bridge both paradigms.
  • Mention an example of another coding paradighm or style you’ve used in the past. What is better/worse about that one?
  React Hooks, especially useState and useEffect. The Signals pattern feels similar because both track dependencies automatically and update the UI reactively. However its
  Better in Signals
  No dependency arrays (which are a common source of bugs in React). Automatic dependency tracking
  Fewer re-renders due to fine-grained updates. More predictable state updates
  Better in React Hooks
  Larger ecosystem and familiarity. Very flexible functional programming model
  Angular signals provide a more predictable and less error-prone reactive model compared to the Hook-based reactivity in React.