Aria 2.0.0
C++23 MVVM framework (C++20 minimum) — reactive, coroutine-first, ABI-layered
Loading...
Searching...
No Matches
aria::ReadOnlyReactive Concept Reference

A reactive cell that can be read and observed, but not written: exactly the surface a one-way (VM→View) binding needs. More...

#include <concepts.hpp>

Concept definition

template<typename S>
requires(S& s) {
typename S::value_type;
{ s.get() } -> std::convertible_to<typename S::value_type>;
} &&
requires(S& s, std::function<void(const typename S::value_type&)> fn) {
s.on_changed(std::move(fn));
}
A reactive cell that can be read and observed, but not written: exactly the surface a one-way (VM→Vie...
Definition concepts.hpp:88

Detailed Description

A reactive cell that can be read and observed, but not written: exactly the surface a one-way (VM→View) binding needs.

Both Property<T> and Computed<T> satisfy it — they expose the same value_type / get() / on_changed(std::function<void(const T&)>) triple. BindingEngine's one-way binders constrain on this instead of the concrete Property<T>, which is what makes a derived value (Computed) bindable without a hand-written on_changed plus a caller-owned subscription store.

Deliberately not satisfied by anything write-only, and deliberately not extended with set(): two-way binders keep taking Property<T>& so binding a computed value two-way stays a compile error rather than a silently dropped write-back.

Unlike Observable above, this concept does include the on_changed surface. That is possible because both implementations type-erase the callback to std::function, so the check is a single well-formed call expression rather than an open-ended invocable probe.