Skip to content

Refactor: Budgeting State to Angular Signals#174

Open
FLAMES39 wants to merge 1 commit intoitalanta:mainfrom
FLAMES39:feat/refactor-signals-state
Open

Refactor: Budgeting State to Angular Signals#174
FLAMES39 wants to merge 1 commit intoitalanta:mainfrom
FLAMES39:feat/refactor-signals-state

Conversation

@FLAMES39
Copy link

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

  • SelectBudgetPageComponent
  • BudgetTableComponent

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._orgBudgets.get()
  • this._budgets$$.get()
    This allows the view to react automatically without subscription management.
    Introduced computed signal for merged budget data
    A computed() property now builds:

{ overview, budgets }

This keeps the data transformation pure, readable, and reactive.
Replaced @input observable with signal input
BudgetTableComponent now receives:

@input({ required: true }) budgets!: Signal<...>;

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:

  • dataSource.data = budgets;
  • dataSource.paginator = this.paginator;
  • dataSource.sort = this.sort;

HTML templates updated to use signals
For example:

<app-budget-table [budgets]="allBudgets">

instead of passing

.pipe(...) observable streams.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant