Why does `action {}` return `ActionFlow` instead o...
# uniflow
e
Why does
action {}
return
ActionFlow
instead of
Unit
, is there a use case to have that object somewhere outside of the Uniflow internals?
a
it is a form of contract, an action function should return an
ActionFlow
to be valid. There is a validator for testing your ViewModel in the uniflow-test module
if you have better suggestion đź‘Ť
e
Where is it a contract? In practical use of a
DataFlow
if a write a function as
fun getWeather() = action { /*..*/ }
then my data flow exposes the returned
ActionFlow
object to the caller. Why is that necessary? The public API of the
ActionFlow
class has all kinds of properties and functions that should likely never be called or callable from outside of a
DataFlow
. Do you have an example of where having all this access is useful?
An example if a user pressing a button to submit a form. I expect my
DataFlow
to just expose a function
fun submit(): Unit
. Of course I could write
Copy code
fun submit() {
    action { /*..*/ }
}
But then I actively must ignore the returned value from
action { /*..*/ }
. What is its intended use? Furthermore, wouldn't it be nicer to be able to write
Copy code
fun submit() = action { /*..*/ }
while
Unit
is returned, indicating that the submit function is fire and forget: it returns quickly but ensures that an action is submitted to its internals that might (or might not) lead to events and state changes.
Let me take a look at uniflow-test now
I've seen the validator now and I understand what it validates, but I still don't understand why all public
DataFlow
functions must return an
ActionFlow
.
a
I’ve seen the validator now and I understand what it validates, but I still don’t understand why all public 
DataFlow
 functions must return an 
ActionFlow
.
Yes, I see your point
not sure it’s a consistent way to effectively avoid any side effect directly on a ActionFlow, we don’t need to see it 👍
I can help validate VM with a Kotlin compiler instead, it will have more sense