Frontend Component and State Architecture Questions

Overview & goals
Design state so UX is snappy (instant toasts), consistent across tabs/devices, durable on server, and resilient to reconnects. Key concerns: dedupe, ordering, acknowledgement, and separation of transient vs persistent UI.

State partitioning

• Local component state (React useState / ephemeral):

  • Transient toast display, animation timers, and local "dismissed" flag for immediate hide.
  • Kept purely UI — not authoritative. Example: toastId -> visible/animating.

• Shared client state (app-level, e.g., Redux/Zustand/Context):

  • In-memory notification store: list of notification objects { id, type, payload, read, createdAt, seen }.
  • Indexes for quick lookup by id, plus a dedupe set of received IDs.
  • Controls whether notification also appears in toast (e.g., showAsToast boolean).
  • Read/unread counts, optimistic updates for marking read/dismissed.

• Server sync / backend authoritative state:

  • Persistent DB model with unique server-assigned id and idempotency keys for dedupe (source_id or event_uuid).
  • WebSocket channel for push; REST endpoints for fetch, acknowledge, paginate, and cleanup.
  • Server maintains canonical ordering and TTL policies for transient vs persistent notifications.

Real-time flow & deduplication

• On incoming WebSocket message: check client dedupe set; if new, insert into shared state and add to dedupe set; trigger toast display via local component state.
• Messages include server id, event_uuid, createdAt. Server honors idempotency key so re-sends aren’t new.
• For actions (mark read/dismiss): optimistic update client-side; send REST/WS ack with action idempotency token; on failure rollback or reconcile on next sync.

Toast vs Persistent list

• Toast: ephemeral UI controlled by local state (auto-hide timer). On toast dismissal, mark "seen" in shared state and send async ack. Toasts do not disappear from persistent list unless explicitly deleted.
• Persistent list: reflects shared client state synced from server; supports pagination, filters, bulk actions.

Resilience & edge cases

• Reconnect: on WS reconnect, client requests delta since last known timestamp or lastServerId to reconcile missed messages.
• Multiple tabs: use BroadcastChannel/localStorage to sync read/dismiss actions between tabs; server remains source of truth.
• Ordering & duplicates: server monotonic sequence numbers; client uses them to order and ignore older duplicates.
• Memory: cap in-memory store and page to server for older items.

This partition keeps UI responsive (local), consistent across the app (shared client), and durable/authoritative (server) while handling dedupe, reconnection, and clear UX separation between transient toasts and persistent notifications.

Overview / Goal
Move from one global monolithic store (client/server) to per-feature scoped stores while keeping UX stable, enabling independent deployments and clear ownership.

Step-by-step plan

1. Discovery & contract definition (2–4 wks)

   • Inventory state slices, producers/consumers, read/write paths.
   • Define canonical contracts (shapes, APIs, events) for each shared entity.

2. Design adapter layer

   • Implement a thin adapter/compatibility layer on both client and server that translates between monolith store API and per-feature stores (e.g., facade with get/set/subscribe).
   • Use publish/subscribe events (EventBus) and REST/GraphQL gateways for cross-store queries.

3. Introduce feature flags & incremental routing

   • Wrap per-feature store activation in flags (server-side + client remote config).
   • Start with read-only reads from new store behind flag; writes still go to monolith.

4. Synchronization of shared entities

   • For each shared entity, implement a sync service: change capture from source store → transform → write to target store. Use idempotent events and versioning (ETag/timestamps).
   • Resolve conflicts with deterministic strategies (last-writer-wins for ephemeral, merge for aggregates).

5. Testing strategy

   • Unit tests for adapters and sync logic.
   • Contract tests between producers/consumers (Pact-style).
   • Integration tests in staging with flags toggled.
   • End-to-end tests validating UX during mixed-state scenarios.
   • Load tests to ensure sync and event bus scale.

6. Ownership transfer & rollout

   • Assign feature team as owner when a feature store passes QA. Ownership includes tests, observability, schema migration docs.
   • Roll out gradually: alpha teams → beta users → 100%.

7. Monitoring & alerting

   • Instrument adapters and sync with metrics: latency, error rate, event lag, reconciliation counts.
   • Dashboards and SLOs; alerts for divergence thresholds and failed syncs.

8. Rollback & mitigation plans

   • Maintain dual-write disabled by default; use feature flags to revert to monolith quickly.
   • Keep replayable event logs and snapshot backups to rehydrate stores.
   • Automate rollback playbook (disable flag → stop sync → monitor).

Trade-offs & notes

• Adapters add short-term complexity but minimize disruption.
• Favor eventual consistency with clear user-facing expectations; use sync windows for critical data.
• Prioritize low-coupling slices first to reduce blast radius.

This plan balances risk, testability, and incremental ownership transfer—suitable for a full-stack role that must handle client adapters, server sync, and ops coordination.

Brief explanation
OnPush tells Angular to run change detection for a component only when its @Input references change, an event originates inside the component, or an observable tied with the async pipe emits. This reduces work and improves performance for large component trees.

TypeScript example

import { ChangeDetectionStrategy, Component, Input } from '@angular/core';
@Component({
  selector: 'user-card',
  template: `<div>{{ user.name }}</div>`,
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserCardComponent {
  @Input() user!: { id: number; name: string };
}

How to ensure view updates

• Use immutable patterns: replace objects/arrays instead of mutating (user = { ...user, name: 'New' }) so Input reference changes.
• Use Observables + async pipe: component subscribes via template (data$ | async). Emission triggers CD.
• For imperative updates, inject ChangeDetectorRef and call markForCheck() or detectChanges() carefully.

Common pitfalls

• Mutating inputs (push/pop, set property) — view won't update.
• Relying on external services without emit or markForCheck.
• Using detectChanges incorrectly causing performance or ExpressionChangedAfterItHasBeenChecked errors.

Debugging tips

• Use OnPush devtools or enable Angular profiler.
• Insert console logs and ChangeDetectorRef.markForCheck() to test.
• Verify object identity with simple === checks in dev console.

Approach to identify leaking subscriptions in production

• Reproduce by monitoring symptoms: rising memory in Chrome heap snapshots, increasing retained DOM nodes, degraded frame rate.
• Collect production signals: memory/CPU metrics (Grafana/CloudWatch), user session durations, slow renders. Correlate with releases.
• Runtime tools: enable Chrome remote heap snapshots for suspect users, use Performance profiling (Allocation instrumentation), and ng.profiler for change detection hotspots.
• Instrument app: add lightweight telemetry (Sentry / Datadog) to record number of active subscriptions or memory delta per route/component (small diagnostic flagging).

Patterns to prevent leaks (code examples + rationale)

1. takeUntil + component destroy subject

• Why: explicit teardown for many ongoing streams.
• Example:

export class MyComponent implements OnDestroy {
  private destroy$ = new Subject<void>();

  ngOnInit() {
    this.someService.stream$
      .pipe(takeUntil(this.destroy$))
      .subscribe(value => this.doWork(value));
  }

  ngOnDestroy() {
    this.destroy$.next();
    this.destroy$.complete();
  }
}

• Intuition: all subscriptions piped through takeUntil auto-unsubscribe when destroy$ emits.

2. async pipe in templates

• Why: template-driven auto-subscription + unsubscription, reduces manual teardown.
• Example:

<div *ngIf="data$ | async as data">{{ data }}</div>

3. OnPush change detection

• Why: reduces unnecessary CD cycles and accidental re-subscribes; encourages immutable inputs and pure streams.
• Example:

@Component({ changeDetection: ChangeDetectionStrategy.OnPush })

4. Use finite operators where appropriate

• take(1), first(), takeWhile(), timeout — prefer when stream is logically finite.

5. Service-level stream design

• Avoid returning hot, never-ending observables without refCount/shareReplay and clear lifecycle contract.
• Use shareReplay({refCount:true, bufferSize:1}) to avoid retaining subscribers after consumers unsubscribe.

6. Helper libraries / decorators

• Consider until-destroy or rxjs-interop utilities where team agrees; prefer explicit Subject pattern for clarity.

Enforcement & architecture changes across a large codebase

• Lint rules & static checks: custom ESLint rules that warn on .subscribe( usage in components without ngOnDestroy/takeUntil or resulting unused Subscription; enforce usage of async pipe in templates where possible.
• Code reviews & guidelines: subscription checklist in PR template; require explicit lifecycle teardown pattern or justification.
• Automated migration: codemods to replace simple subscriptions with async pipe or add takeUntil scaffolding.
• Shared base classes / utilities: provide BaseComponent with destroy$ to standardize pattern.

export abstract class BaseComponent implements OnDestroy {
  protected readonly destroy$ = new Subject<void>();
  ngOnDestroy() { this.destroy$.next(); this.destroy$.complete(); }
}

• Testing & Observability: unit tests that assert ngOnDestroy completes destroy$, integration tests to ensure no leaking observables; runtime telemetry to detect growing subscription counts.
• Education: brown-bags on RxJS memory patterns, examples of common gotchas (long-lived timers, router events, DOM events, WebSocket streams).

Trade-offs & final notes

• Prefer explicit patterns (takeUntil / BaseComponent) over magic decorators for maintainability.
• Async pipe + OnPush is the most robust for UI streams; for imperative logic use takeUntil.
• Balance performance monitoring and minimal production instrumentation to avoid overhead.

This combination—detecting via telemetry/heap snapshots, applying takeUntil/async pipe/OnPush, centralizing lifecycle utilities, linting and automation—scales across a large codebase and prevents lingering RxJS subscriptions.

When to use a server-state library vs global store

Use React Query / SWR when data is authoritative on the server, requires caching, background sync, pagination, or cross-tab freshness. Use your global store (Redux / Zustand) when you need complex client-only derived state, UI state tightly coupled across components, or to persist user-driven ephemeral state. For full-stack work: server-state libs reduce boilerplate for fetching, retries, deduping, and cache orchestration so backend-driven views stay consistent.

Cache invalidation strategies

• Time-based: staleTime to mark fresh vs stale; longer for rarely-changing resources.
• Event-based: invalidateQueries after mutations or WebSocket events.
• Key-based: structure query keys (['posts', postId]) so you can invalidate granularly.
• Conditional: refetchOnWindowFocus/refetchOnReconnect for opportunistic freshness.

Background refetching & GC

• Background: refetchInterval or refetchOnWindowFocus to keep data fresh; use exponential backoff for failures.
• GC: cacheTime controls how long unused queries stay in memory; set lower for large lists, higher for frequently revisited views.

Mutation handling (optimistic / rollback)

• Optimistic update: update cache immediately in onMutate, cancel outgoing queries, return context for rollback.
• Rollback: onError uses context to restore previous cache; onSettled revalidates with server.
  Example:

// React Query mutation pattern
const mutation = useMutation(api.updatePost, {
  onMutate: async newData => {
    await queryClient.cancelQueries(['post', newData.id]);
    const previous = queryClient.getQueryData(['post', newData.id]);
    queryClient.setQueryData(['post', newData.id], old => ({ ...old, ...newData }));
    return { previous };
  },
  onError: (err, newData, context) => {
    queryClient.setQueryData(['post', newData.id], context.previous);
  },
  onSettled: (data) => {
    queryClient.invalidateQueries(['post', data.id]);
  }
});

Combining with local UI state

• Keep UI-only state (modals, form drafts, sorting, pagination controls) in component/local store.
• Use server-state for the data source and sync UI state to queries via query keys/params (e.g., ['posts', { page, filter }]).
• For optimistic UX, store temporary form state locally, then apply optimistic mutation to server cache.

Practical rule: server-state libs for fetch/cache/refetch/mutate lifecycles; global/local stores for orchestration, derived UI state, and persistence.