RxDart

## What a subject is in RxDart A **subject** in the `rxdart` package (0.28.0) is a `StreamController` that is also a `Stream`: you push events with `add`, `addError` and `close`, and anyone can `listen` to it directly or to its `stream` getter. All three built-in subjects — `BehaviorSubject`, `PublishSubject` and `ReplaySubject` — wrap a **broadcast** controller from `dart:async`, so several listeners can subscribe at the same time. What separates them is **memory**: what a listener that subscribes *after* some events were added receives first. - Each factory takes optional `onListen` and `onCancel` callbacks and a `sync` flag that defaults to `false`. - Each is both the sink you write to and the source you listen to, which is why a service normally keeps the subject private and exposes only its stream. ## The three subjects side by side | Subject | What a new listener receives first | Synchronous read | Typical use | |---|---|---|---| | `BehaviorSubject` | the latest value, or the latest error if that came last | `value`, `valueOrNull`, `hasValue` | current state | | `PublishSubject` | nothing — only events added after it subscribed | none | one-off events | | `ReplaySubject` | the buffered events, oldest first, up to `maxSize` | `values`, `errors` | a short history | ## BehaviorSubject: the latest value, optionally seeded `BehaviorSubject` keeps one slot. Every `add` overwrites it; a new listener receives the cached item first and then every later event. `BehaviorSubject.seeded(x)` fills the slot at construction, so the subject has a current value before anything is added. Because it implements **`ValueStream`**, the slot can also be read synchronously with `value`, `valueOrNull` and `hasValue`. - If the last event added was an **error**, a new listener receives that error instead of a value. - The next `add` restores normal replay of the latest value. ## PublishSubject: only what happens from now on `PublishSubject` is a broadcast controller that is also a stream, with no memory at all. Events added while nobody listens are dropped, and a listener that arrives late has missed them for good. That is the right shape for **events that should fire once**: show a snackbar, navigate to a result screen, report that location permission was denied. Replaying those to a screen that subscribes later would repeat an action the user has already seen. ## ReplaySubject and maxSize `ReplaySubject` keeps a queue of past events — data *and* errors — and replays them in order to each new listener before live events. 1. `maxSize` is **nullable and null by default, which means unbounded**: a replay subject fed by a long-lived source keeps growing for as long as it lives. 2. With `maxSize: 2`, adding 1, 2 and 3 drops 1, and each new listener receives 2 then 3. 3. Errors occupy slots in the same queue, so they count towards `maxSize` too. 4. The buffered data is readable through `values` and the buffered errors through `errors`. ## Which one for UI state For state a screen renders — the device's current position, a cart total, an active filter — interviewers expect **`BehaviorSubject`**: - A widget that subscribes late (after a route push, or after a rebuild swapped its stream) still gets the current value without waiting for the next change. - Code outside the widget tree can read the current state synchronously. - It stores one item, so its memory does not grow with the number of updates. `PublishSubject` would leave a late screen blank until the next update arrives, and `ReplaySubject` without `maxSize` would replay — and retain — every past state. `ReplaySubject(maxSize: 1)` replays like a behaviour subject but offers `values` (a list) instead of the single-value `ValueStream` getters, and cannot be seeded. ```dart import 'package:rxdart/rxdart.dart'; Future<void> main() async { final behavior = BehaviorSubject<int>(); final publish = PublishSubject<int>(); final replay = ReplaySubject<int>(maxSize: 2); for (final subject in [behavior, publish, replay]) { subject..add(1)..add(2)..add(3); } behavior.listen((v) => print('behavior $v')); // behavior 3 publish.listen((v) => print('publish $v')); // nothing replay.listen((v) => print('replay $v')); // replay 2, replay 3 await Future<void>.delayed(Duration.zero); await Future.wait([behavior.close(), publish.close(), replay.close()]); } ``` The one-line version for an interview: **Behavior remembers the last, Publish remembers nothing, Replay remembers a buffer** — and UI state wants the last.