You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Something to consider for FlowRedux 2.0 as working with onEnterStartStateMachine or onActionStartStateMachine is not so convenient, i.e. you dont need to deal with the initial state problem of the child state machines.
Maybe we could do something like we do with untilIdentityChanged( { ... } ).
I am not sure how feasible it is to implement and how much sense it makes, I am just sketching out an idea here:
sealedinterfaceStateobject Loading : State
data classShowContent(items:List<Item>, valotherState:OtherState) : State
selead interfaceOtherStateobject A : OtherState
object B : OtherState
then we could have our regular FlowReduxStateMachine but instead of having another FlowReduxStateMachine that manages OtherState we could let that be handled by the "parent" FlowReduxStateMachine (i will add a thought about reusability at the end) :
classMyStateMachine : FlowReduxStateMachine<State, Action>( Loading ){
init {
spec {
inState<Loading> {
onEnter { state ->
delay(1000)
state.override { ShowContent( emptyList(), A) }
}
}
inState<ShowContent> {
// new DSL block
asChildState( { state :ShowContent-> state.otherState }) { // specify which property of ShowContent state should be treated as a sub state// inside asSubState you can use all the regular DSL blocks as if it was the top level spec block of a regular FlowReduxStateMachine
inState<A> {
on<Action1> { ... }
onEnter { ... }
collectWhileInState { ... }
condition { ... }
untilIdentityChanged { ... }
asSubState(...) // In theory we could support nesting too
}
inState<B> {
...
}
}
}
}
}
The new DSL block is asChildState (better name needed). Basically you can "teach" a FlowReduxStateMachine how to act on a certain property of a State by treating it as a substate. That should come close to something like onEnterStartStateMachine or onActionStartStateMachine do today but I am not 100% sure if it is a 1-to-1 replacement or not 😄 need to think about it a bit more in detail ...
One of the nice things of onEnterStartStateMachine or onActionStartStateMachine is that you can make "reusable" smaller state machines. This is done by having small FlowReduxStateMachines on its own that can be "composed" into bigger state machines and reused when needed. We should aim to have the same advantage with the propose asChildState block.
How we could achieve that is by using extension functions (or maybe context receivers). I am not 100% sure if that really would compile but let's assume we have a SuperBuilderBlock (I am lacking a better name for now 😄 ) then we could maybe extract the logic descirbed above into an extension function. Something like this:
// Pseudo-codefun SuperBuilderBlock.otherStateDefinition() {
inState<A> {
on<Action1> { ... }
onEnter { ... }
collectWhileInState { ... }
condition { ... }
untilIdentityChanged { ... }
asSubState(...) // In theory we could support nesting too
}
inState<B> {
...
}
}
}
once this logic is extracted in it's own extension function, we could simply invoke this extension function wherever we want to reuse this "state machine definition" for OtherState. For example the example above could look as follows:
classMyStateMachine : FlowReduxStateMachine<State, Action>( Loading ){
init {
spec {
inState<Loading> {
onEnter { state ->
delay(1000)
state.override { ShowContent( emptyList(), A) }
}
}
inState<ShowContent> {
// new DSL block
asChildState( { state :ShowContent-> state.otherState }) { // specify which property of ShowContent state should be treated
otherStateDefinition()
}
}
}
}
and if we want to have a dedicated FlowReduxStateMachine for OtherState we could resue
Again, not sure if this all will work or if we can achieve that with kotlin nor if it is a good ideas to add something like that to the DSL. I am just doing a braindump 😄
The text was updated successfully, but these errors were encountered:
Something to consider for FlowRedux 2.0 as working with
onEnterStartStateMachine
oronActionStartStateMachine
is not so convenient, i.e. you dont need to deal with the initial state problem of the child state machines.Maybe we could do something like we do with
untilIdentityChanged( { ... } )
.I am not sure how feasible it is to implement and how much sense it makes, I am just sketching out an idea here:
then we could have our regular FlowReduxStateMachine but instead of having another FlowReduxStateMachine that manages
OtherState
we could let that be handled by the "parent" FlowReduxStateMachine (i will add a thought about reusability at the end) :The new DSL block is
asChildState
(better name needed). Basically you can "teach" a FlowReduxStateMachine how to act on a certain property of a State by treating it as a substate. That should come close to something likeonEnterStartStateMachine
oronActionStartStateMachine
do today but I am not 100% sure if it is a 1-to-1 replacement or not 😄 need to think about it a bit more in detail ...One of the nice things of
onEnterStartStateMachine
oronActionStartStateMachine
is that you can make "reusable" smaller state machines. This is done by having small FlowReduxStateMachines on its own that can be "composed" into bigger state machines and reused when needed. We should aim to have the same advantage with the proposeasChildState
block.How we could achieve that is by using extension functions (or maybe context receivers). I am not 100% sure if that really would compile but let's assume we have a
SuperBuilderBlock
(I am lacking a better name for now 😄 ) then we could maybe extract the logic descirbed above into an extension function. Something like this:once this logic is extracted in it's own extension function, we could simply invoke this extension function wherever we want to reuse this "state machine definition" for
OtherState
. For example the example above could look as follows:and if we want to have a dedicated FlowReduxStateMachine for
OtherState
we could resueAgain, not sure if this all will work or if we can achieve that with kotlin nor if it is a good ideas to add something like that to the DSL. I am just doing a braindump 😄
The text was updated successfully, but these errors were encountered: