Hello! A few times I received feedback about nulla...
# decompose
Hello! A few times I received feedback about nullability in
. Currently it is defined as abstract class
Value<out T : Any>
. But sometimes it would be useful to have something like
, instead of wrapping into something like
. The reason of that limitation is the interop with Swift - generics in interfaces are not supported, and a class with
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
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>
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
. But if Swift is needed - one should expose
. This looks more flexible - e.g. it will be possible to expose both
to Swift, and it will be type-safe. But also a bit more verbose in case of Swift. What do you think, 👍 or 👎?
👎 1
👍 1
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?
I agree with @Andrew Steinmetz I don't face up with cases where I need a nullable value.
One of the use cases is to have something like
, 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.
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.
Thanks! All opinions matter!
Decided to postpone the idea until strong use cases. Thanks!