Refactor: Budgeting State to Angular Signals#174
Open
FLAMES39 wants to merge 1 commit intoitalanta:mainfrom
Open
Refactor: Budgeting State to Angular Signals#174FLAMES39 wants to merge 1 commit intoitalanta:mainfrom
FLAMES39 wants to merge 1 commit intoitalanta:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refactored Budgeting State to Angular Signals
This PR refactors the budgeting UI state management from RxJS-based observables to Angular Signals, focusing on clarity, performance, and simplified reactivity. The goal was to modernize the budgeting feature by aligning it with Angular’s new reactive primitives while keeping all existing behavior fully intact.
1. Summary of the Refactor
The original implementation used several Observable streams, manual subscribe calls, and SubSink for cleanup. While functional, it added unnecessary complexity for components whose state is local and purely UI-driven.
In this refactor, I replaced the local observable state with Angular Signals (signal, computed, and effect). The budgeting flow remains unchanged, but the internal state management is now more predictable, easier to understand, and requires significantly less code.
Key Improvements
Removed RxJS subscriptions from the two budgeting components
These components no longer rely on manual subscriptions, SubSink, or lifecycle-based cleanup. Converted incoming streams from the store into signals
toSignal() is used to wrap:
This allows the view to react automatically without subscription management.
Introduced computed signal for merged budget data
A computed() property now builds:
This keeps the data transformation pure, readable, and reactive.
Replaced @input observable with signal input
BudgetTableComponent now receives:
This ensures the child component updates instantly when parent state changes.
Introduced an effect to drive MatTable data updates
Instead of subscribing manually, an effect() reacts to budget changes and applies:
HTML templates updated to use signals
For example:
instead of passing
3. Why Move to Angular Signals?
Better clarity
Signals make component state explicitly readable and writable, instead of hidden behind observable pipes and async subscriptions.
Automatic cleanup
Signals handle reactivity internally no ngOnDestroy cleanup, no SubSink, no subscription leaks.
Predictable change detection
Angular refreshes exactly the parts of the view that depend on the changed signal, improving performance in a UI-heavy page like budgeting.
Future compatibility
Signals are the direction Angular is moving toward. Modernizing this flow ensures the budgeting module stays maintainable and aligned with upcoming Angular features.