Hello! A few times I received feedback about nulla...

# decompose

[Arkadii Ivanov]

Hello! A few times I received feedback about nullability in Value. Currently it is defined as abstract class Value<out T : Any>. But sometimes it would be useful to have something like Value<String?>, instead of wrapping into something like Value<Optional<String>>.

The reason of that limitation is the interop with Swift - generics in interfaces are not supported, and a class with <T> is always nullable. But it feels that Swift is not needed for everyone, there are projects without Swift but with Android/desktop/Web/compose-ios etc.

I got an idea to make Value a normal interface, and at the same time keep the interop with Swift.

interface Value<T>

With additional classes:

abstract class ReqValue<T : Any> : Value<T>
and
abstract class OptValue<out T : Any> : Value<T?>

And two extension functions:

<T : Any> Value<T>.asRequired(): ReqValue<T>
<T : Any> Value<T?>.asOptional(): OptValue<T>

So, if Swift is not needed - it's ok to just use Value. But if Swift is needed - one should expose ReqValue or OptValue. This looks more flexible - e.g. it will be possible to expose both <T> and <T?> to Swift, and it will be type-safe. But also a bit more verbose in case of Swift.

What do you think, 👍 or 👎?

[Andrew Steinmetz]

That is an interesting idea, almost all my projects that use decompose do use swift and honestly just think making a property nullable in the model covers all my use cases. I guess if you had a complicated bottom sheet logic it might be nice to be able to store that whole model as null value, but could just as easily say that it could be achieved with a boolean in that case to be store in the model.

Is there a good example people have brought up requesting this kind of change?

[lehakorshun]

I agree with @Andrew Steinmetz I don't face up with cases where I need a nullable value.

[Arkadii Ivanov]

One of the use cases is to have something like Value<DialogComponent?>, to dynamically create and destroy a dialog/overlay component. It may be also useful for developers who prefer to have multiple Value properties instead of one single state class.

It was originally requested here - https://github.com/badoo/Decompose/issues/258 And then also here - https://github.com/arkivanov/Decompose/discussions/55
But there are no exact use cases described. Personally I bumped into this limitation when created components dynamically.

[Andrew Steinmetz]

I see, well I would personally prefer to keep the API simple and if a nullable value is needed to just do the suggestion you left in this comment making an Optional data class. But that's just my opinion since I haven't really needed just one type in a value to be null.

[Arkadii Ivanov]

Thanks! All opinions matter!

[Arkadii Ivanov]

Decided to postpone the idea until strong use cases. Thanks!