​

NgRx vs Service-Based State Management Analysis

​

Application Context

​

Current Architecture Overview

• Framework: Angular 19 with standalone components
• Data Sources: Mock data (transitioning to Firebase/API)
• Services: ~15+ injectable services with BehaviorSubjects
• Components: ~40+ components across pages and shared
• State Patterns: In-memory arrays, localStorage, BehaviorSubject observables

​

Option 1: NgRx State Management

​

Pros

​

Cons

​

When NgRx Makes Sense

• Real-time collaborative editing
• Complex undo/redo requirements
• Offline-first with sync queues
• Shared state across 10+ components
• Complex derived state calculations

​

Option 2: Service-Based Data Fetching (Current Approach)

​

Pros

​

Cons

​

Current Implementation Strengths

// Your services already use BehaviorSubjects effectively
private alertsSubject = new BehaviorSubject<ThresholdAlert[]>([]);
public alerts$ = this.alertsSubject.asObservable();

// Reactive patterns without NgRx overhead
private unreadCountSubject = new BehaviorSubject<number>(0);
unreadCount$ = this.unreadCountSubject.asObservable();

​

Application-Specific Analysis

​

Data Flow Patterns in This App

​

Key Observations

1. No Complex Cross-Cutting State: Features are relatively isolated
2. CRUD-Dominant Operations: Most features are simple create/read/update
3. Limited Real-Time Needs: No collaborative editing or live sync
4. Moderate Component Tree: State doesn’t need to traverse deep hierarchies
5. Firebase Integration: Firebase SDK handles real-time sync natively

​

Hybrid Approach: Recommended Improvements

​

1. Signal-Based State (Angular 17+)

// Modern Angular signals for reactive state
@Injectable({ providedIn: 'root' })
export class PatientService {
  private patientsSignal = signal<Patient[]>([]);
  readonly patients = this.patientsSignal.asReadonly();
  
  // Computed derived state
  readonly activePatients = computed(() => 
    this.patientsSignal().filter(p => p.status === 'In Progress')
  );
}

​

2. Simple Caching Layer

// Add caching to services without NgRx
private cache = new Map<string, { data: any; timestamp: number }>();
private CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async getPatient(id: string): Promise<Patient> {
  const cached = this.cache.get(id);
  if (cached && Date.now() - cached.timestamp < this.CACHE_TTL) {
    return cached.data;
  }
  const data = await this.fetchPatient(id);
  this.cache.set(id, { data, timestamp: Date.now() });
  return data;
}

​

3. Lightweight State Container (Optional)

// Per-component store without global NgRx
@Injectable()
export class QuestionnaireStore extends ComponentStore<QuestionnaireState> {
  readonly questionnaires$ = this.select(state => state.items);
  
  readonly addQuestionnaire = this.updater((state, item: Questionnaire) => ({
    ...state,
    items: [...state.items, item]
  }));
}

​

Decision Matrix

​

Conclusion

​

Recommendation: Continue with Service-Based Approach

1. Feature Complexity Doesn’t Justify It: CRUD operations on patients, questionnaires, and carepaths don’t require Redux patterns
2. Current Architecture Works Well: Your BehaviorSubject-based services already provide:
   • Reactive data streams
   • Centralized business logic
   • Observable-based component updates
3. Firebase Handles Real-Time: When you integrate Firebase, its SDK provides real-time sync without needing NgRx
4. Development Velocity: Adding NgRx would slow down feature development without proportional benefits
5. Team Productivity: Simpler patterns mean faster onboarding and fewer bugs

​

Suggested Enhancements

​

When to Reconsider NgRx

• Real-time collaborative editing is added
• Offline-first with complex sync is required
• State needs to be shared across 15+ components
• Complex undo/redo functionality is needed
• Team grows to 10+ developers on same codebase

​

Summary