Coming from DynamicData and ReactiveUI

A side-by-side map of DynamicData and ReactiveUI concepts, operators and behaviors onto dxn_reactive, and the differences that matter.

If you have built .NET applications with DynamicData and ReactiveUI, most concepts here are familiar. This page maps the vocabulary and highlights what differs. If you have never used either, skip it.

#The same pipeline in both worlds

// C# with DynamicData
var subscription = _people.Connect()
    .Filter(this.WhenAnyValue(x => x.SearchText).Select(BuildPredicate))
    .Sort(SortExpressionComparer<Person>.Ascending(p => p.Name))
    .Page(_pageRequests)            // one-based PageRequest
    .ObserveOn(RxApp.MainThreadScheduler)
    .Bind(out _visiblePeople)
    .Subscribe();

use dxn_reactive::collections::prelude::*;
use dxn_reactive::prelude::Signal;

#[derive(Clone, Debug, PartialEq)]
struct Person {
    id: u32,
    name: String,
}

let people = SourceCache::new(|person: &Person| person.id);
let search_text = Signal::new(String::new());
let page = Signal::new(PageRequest::new(0, 20)); // zero-based

let visible_people = people
    .connect()
    .filter_with_state(search_text.values(), |text: &String, person: &Person| person.name.contains(text.as_str()))
    .sort_keyed_by_key(|person| person.name.clone())
    .page_keyed_dynamic(page.values())
    .as_observable_list()?; // the view binds this; marshal to the UI thread in the binding

people.add_or_update(Person { id: 1, name: "Ada".into() })?;
assert_eq!(visible_people.len()?, 1);

#Key differences

#DynamicData API map

#Sources

#Operators

#ReactiveUI map

#Behaviors that may surprise you

• Computed republishes equal results. WhenAnyValue plus DistinctUntilChanged habits carry over: use Computed::derive_distinct or distinct_until_changed().
• Commands run concurrently by default. Overlapping execute calls each run; choose ExecutionPolicy::IgnoreWhileRunning to refuse them. execute on a disabled command returns CommandError::Disabled instead of doing nothing.
• count() never emits for an always-empty source, and an empty source’s connect() sends no snapshot. Use start_with(0) or start_with_empty().
• Page responses follow every field. A change outside the window still emits a response (with an empty change set) so total_count stays current.
• Nested edits fail instead of recursing. Accessing a source from inside its own edit returns NestedUpdate; concurrent writers on other threads simply wait (on wasm32 they get Contended).
• There is no ObserveOn. Nothing is moved to another thread unless an operator documents a timer or worker thread; marshalling is the binding’s job.

Next: Contributing.