observable(3/0)
Distinguish series and one time observables
Observables are extremely helpful; however, the observable.subscribe() pattern hides whether the call is expected to return once or multiple times. It’s important to distinguish when there will be a single update and when there will be a series. Series observables usually belong in the onInit() method and drive component behavior when they receive dispatches. One-time observables are merely getting data. The methods to interact with each are different. For example, one-time uses Ramda’s forkJoin to resolve all observables, but combineLatest when updates are expected.…
One subscription per resource
Here’s my subscription progression for the qrm-category-container root component. Let me know if this is headed in the right direction. Stage One - Current Code The root container creates a subscription in onInit() that fires whenever fedId or QRM periodId changes, like so: combineLatest([this.sessionQuery.federalReserveId$, this.sessionQuery.qualitativePeriodId$]) .subscribe(([fedId, qualitativePeriodId]) => { this.qualitativePeriodId = qualitativePeriodId; this.refreshViewModel(fedId, qualitativePeriodId, this.viewCustomerData, this.categoryId); }); That’s not too bad, right? Consider what happens in refreshViewModel()… refreshViewModel(federalReserveId: number, periodId: number, viewCustomerData: boolean, categoryId): void { this.…
Smart components observe state over input
In component design there are two buckets, smart and dumb components. Smart components are keepers of data models and reactive to changes. Dumb components render explicit data models to views. Dumb components benefit from the explicit interface created by a clear set of inputs. Smart components, however, can get into a lot of trouble if they depend on mutable inputs for their data models. While it seems easy to add an onChanges() function to child smart components to re-render based on changes to their inputs, this dependency can have unexpected consequences.…