For some reason the `bind()` on the `Either` conta...
# arrow
l
For some reason the
bind()
on the
Either
contained in the `MutableStateFlow`'s
value
here cannot be resolved.
commonConnectorApi.renameControlDevice()
returns
Either<CallError, Unit>
.
s
Is
DataMissing
a
CallError
?
l
No, this is a separate sealed class hierarchy
Copy code
sealed class DataState<T> {

    sealed class DataMissing : DataState<Nothing>()

    object NotInitialized : DataMissing() {

        operator fun invoke() = Left(NotInitialized)
    }

    data class Error private constructor(val error: CallError) : DataMissing() {
        companion object {

            operator fun invoke(error: CallError) = Left(Error(error))
        }
    }

    data class DataLoaded<T> private constructor(val data: T) : DataState<T>() {
        companion object {

            operator fun <T> invoke(data: T) = Right(DataLoaded(data))
        }
    }
}
Can
bind()
be used only if the
Left
type argument is the same for all calls?
a
each
either
block can only have one error type, so all the calls to
bind
need to be over the same type, or share a parent class
s
bind does exactly that, continues with the right if it is right, if it is not it needs to know how to exit and what the result of your
either
block will be. Since the return type of your function is Either<CallError, Unit>, if you could bind in there with the left being a
DataMissing
, what would you expect the return value to be? It has to confront to the type you said you’re returning.
🙏 1
l
Yes, that makes sense -
either
block with
bind()
basically a
flatMap
, so left type always has to be the same (only right type can be changed through the flatmapping).
Thank you for the explanations! 🙏
🙌 1
s
You could
mapLeft { dataMissing -> dataMissing.toSomeCallError }.bind()
if there is such a mapping, or in general rethink what kind of error you want to return there and have it be of the same type
l
I think I actually should not
bind()
them both in the same
either
block.
I want to return the result of the call but also, as a side effect, update the
controlDevices.value
. But
controlDevices.value
being in the state of
DataMissing
is the result of the previous calls. They are not related to each other. I just wanted to oversimplify things and the
bind()
not resolving actually saved me from conflating a pure function call and a side effect.