Whats the motivation for creating ValueWrapper and breaking backwards compatibility with ValueStream?

ValueWrapper seems to do nothing other than wrap another value, which ValueStream also did.

So why create it? Was it really necessary to break everyone’s code due to this seemingly useless class? I’m genuinely curious as to why this was added.

So our code is going from _valueStream.value to _valueStream.valueWrapper.value.

2 thoughts on “Whats the motivation for creating ValueWrapper and breaking backwards compatibility with ValueStream?

  1. Idd, there’s a lot of focus on value, but the main purpose is to listen, starting with the latest value as first event.

    Imo, it’s perfectly fine to throw a null safe error when accessing value too early, imo the only correct type of value would be FutureOr, but bottom line it’s inherently unsafe to trust value, devs should always be careful when relying on it.

  2. That’s why I think it’s a risky change.

    • I agree, this is a big break-change. But throwing error when using ValueStream.value, which will make it possible for the user to use it properly, make sure we access to the latest value, instead of null and ?? 'Loading...' or something.

    • Like Kotlin (null-safety from first appearance), consider ConflatedBroadcastChannel from kotlinx.coroutines (it is something like BehaviorSubject). This API is similar to the current ValueStream API.

    conflated_channel