Issue and questions about subStateMachine

[xiaozhikang0916]

I have an issue and some questions about the subStateMachine.

1. In the onXXXStartStateMachine apis, they are requiring a StateMachine instance, or a lambda returing such instance in the param. And it is impossible in the new FlowRedux2 api now, because we can only access to a StateMachineFactory instance.

The following are some questions about the design of subStateMachine.

1. Is it possible to have a stop sign, either from the host state or the sub state, for the sub state machine, to stop and release the running sub state machine and release resources when met. Currently, it is hard to figure out if a sub state machine started by a one-shot action is correctly stopped.
2. I wonder if the state mapper of sub state machine can be suspend, or even map the sub state to an action for the host state machine. Or is this thought a violation of some principle?

[gabrielittner]

In the onXXXStartStateMachine apis, they are requiring a StateMachine instance, or a lambda returing such instance in the param. And it is impossible in the new FlowRedux2 api now, because we can only access to a StateMachineFactory instance.

This will change in one of the next alphas. I have most of the changes prepared for it but there are still some things missing. Until then you could use LegacyFlowReduxStateMachine for sub state machines. It does implement StateMachine and has the new DSL. It doesn't have all of the advantages of the new factory, but for sub state machines it doesn't make much of a difference. The migration to factory is also fairly simple with it once we properly support them for sub state machines.

Is it possible to have a stop sign, either from the host state or the sub state, for the sub state machine, to stop and release the running sub state machine and release resources when met. Currently, it is hard to figure out if a sub state machine started by a one-shot action is correctly stopped.

You are talking about onActionStartStateMachine in this case, right? They are running until either another action of the same kind is received (will cancel the old state machine and start another) or if the parent state machine leaves the block that the sub state machine was started in (like moving to another state). So if a sub state machine transitions the parent to a different state it, this would cancel the sub state machine. I generally agree though that we could have more here. Could you share some use cases for how you use sub state machines and would like to cancel them?

I wonder if the state mapper of sub state machine can be suspend, or even map the sub state to an action for the host state machine. Or is this thought a violation of some principle?

Suspending should be do-able. We primarily have simple mappers because when we designed it the idea was mostly that you'd build the part of the state in the sub-state machine and then the state mapper is just "integrating" the sub state into the parent state. I'd be curious about your use cases for this.

Dispatching actions goes more against the philosophy of flow redux. One of the main design points is to avoid internal actions and instead act based on state changes (or parts of a state changing with the condition or untilIdentityChanges blocks).

[xiaozhikang0916]

They are running until either another action of the same kind is received

It should be another action of the same value rather than same kind, right?

Take your GithubRepository Sample as an example. If we add some log to the MarkAsFavoriteStateMachine we can find that these state machines are kept alive until the same repo is triggered favourited or unfavourited.

class MarkAsFavoriteStateMachine(
    private val githubApi: GithubApi,
    private val repository: GithubRepository,
): LegacyFlowReduxStateMachine<GithubRepository, Action> {
    override val state: Flow<GithubRepository>
        get() = super.state.onStart { println("$repository Start") }.onCompletion { println("$repository Complete") }
}

GithubRepository(id=3, name=Repository 3, stargazersCount=30, favoriteStatus=NOT_FAVORITE) Start
GithubRepository(id=4, name=Repository 4, stargazersCount=40, favoriteStatus=NOT_FAVORITE) Start
GithubRepository(id=5, name=Repository 5, stargazersCount=50, favoriteStatus=NOT_FAVORITE) Start
GithubRepository(id=4, name=Repository 4, stargazersCount=41, favoriteStatus=FAVORITE) Start
GithubRepository(id=4, name=Repository 4, stargazersCount=40, favoriteStatus=NOT_FAVORITE) Complete

And in our real project, I have a content page and would like to separate the initial load to a sub state machine. It simultaneously loads from database and network asynchronously, emits any of them once value returned, and all works are done after loaded from network.
It is achieveable to close the sub state machine gracefully by designing the host state class carefully, but it would be more convenient with a stop sign in the sub state.

Suspending should be do-able. We primarily have simple mappers because when we designed it the idea was mostly that you'd build the part of the state in the sub-state machine and then the state mapper is just "integrating" the sub state into the parent state. I'd be curious about your use cases for this.

We need to show toast after some network requests, some may be from the error message of the http return, and some from the string resources bundled in the app, which is a suspend call in compose resource lib. In this case, I would like to keep sub state machine focus on network requests and just return the request result, and leaves the conversion from result to toast string in the host state machine, either in a suspandable state mapper, or introduce a new field for the result and convert it to string with the condition or untilIdentityChanges blocks. Just like the previous case, it is achieveable, but can be better if we have more apis here.

Dispatching actions goes more against the philosophy of flow redux. One of the main design points is to avoid internal actions and instead act based on state changes (or parts of a state changing with the condition or untilIdentityChanges blocks).

Can you share some pages about philosophy, theory and best practice of flow redux?

[gabrielittner]

It should be another action of the same value rather than same kind, right?

Yes you're right.

And in our real project, I have a content page and would like to separate the initial load to a sub state machine. It simultaneously loads from database and network asynchronously, emits any of them once value returned, and all works are done after loaded from network.
It is achieveable to close the sub state machine gracefully by designing the host state class carefully, but it would be more convenient with a stop sign in the sub state.

For onEnterStartStateMachine you'd ideally achieve this by wrapping it in either inState (e.g. you have a Loading state in which you use it and then transition to Content based on the state from the sub state machine, which cancels it) or condition (if you have one state class and have some way to check whether the initial load happened).

For onActionStartSubStateMachine we should really have something though, since there is nothing right now.

We need to show toast after some network requests, some may be from the error message of the http return, and some from the string resources bundled in the app, which is a suspend call in compose resource lib. In this case, I would like to keep sub state machine focus on network requests and just return the request result, and leaves the conversion from result to toast string in the host state machine, either in a suspandable state mapper, or introduce a new field for the result and convert it to string with the condition or untilIdentityChanges blocks. Just like the previous case, it is achieveable, but can be better if we have more apis here.

Makes sense 👍

Can you share some pages about philosophy, theory and best practice of flow redux?

Unfortunately not, I will write something. The core idea is around being declarative and resumable/reproducible. There were 2 other approaches that we tried out: 1) relying on internal actions, 2) allowing multiple state changes from a single event handler.

Approach 1 is something we used a lot in our code base before FlowRedux when writing ViewModels. So loading the content of a screen or making a request based on a user action would first send a Load/InProgress action which transitions to the loading state and then in the end would emit a success/error action to then update the state again to the result. This was much harder to read since it was harder to follow through where something happens and any action could have a lot of other effects in different places of the state machine. It also led to some confusion around which actions are internal to the state machine and which come from the UI.
The other issue with this was in terms of being "resumable/reproducible". FlowRedux was initially designed to be used in an Android code base where we have to deal with configuration changes or the app being killed and then restored. If you handle an action by doing a http request and dispatching an internal action to update to a loading state and then to the final state, if the state machine is killed while this happens and then the state is restored, you are in the loading state but since the action triggers the http request it will not be executed again. With the current approach of the DSL, the action would only do the state change to the loading state and then you'd have an onEnter (either within a different inState or in a condition block depending on how your state is modelled) to do the request and transition to the final state. In this case being killed and restored would re-execute the onEnter so that you are not stuck in the loading state without anything actually happening.

Approach 2 got rid of internal actions but still had some issues around the area of being "resumable/reproducible".

[xiaozhikang0916]

Thanks for sharing, it is greatly helpful for us improving our code.

---

By the way, will it be problematic that execution policy of some apis (onActions) are based on the type equality and some (onActionStartSubStataMachines) on the value equality 🤔? Is it necessary to let user take control of the execution policy on both equality case?

---

I would like to ask for more best practice if you don't mind. Or should I open a thread in discussions?

As you mentioned above,

For onEnterStartStateMachine you'd ideally achieve this by wrapping it in either inState (e.g. you have a Loading state in which you use it and then transition to Content based on the state from the sub state machine, which cancels it) or condition (if you have one state class and have some way to check whether the initial load happened).

Which way do you prefer?

In our previous practice, we tried abstracting the state to different classed like

sealed interface PageState {
  data class Loading(/* fields */)
  data class ShowContent()
  data class Submitting()
}

But soon we found some problems here.

First of all, it was annoying to bring some data to another state during transtion, e.g. bringing all user input from ShowContent to Submitting on Submit button clicked, and bringing it back after submit succeed or failed. It required lots of helper functions or some other data holder class.

And it was diffcult to handle actions for the abstract type of state, e.g. I have a checkbox which can be toggled in all these states. If I handle this action during inState<PageState> block, I cannot simply use copy on this interface type, so an abstruct funtion fun toggleSwitch(on: Boolean): PageState may be needed here.

So, most of our statemachine implementations are using one single state class for all page situations. It simplify our work for handling data transfering among states. In this way, we rely on the condition api heavily, but unfortunatly, condition block cannot be nested 😢. Therefore, we need to duplicate some condition code in several condition blocks.

Can I have some advice about it?

[gabrielittner]

Sorry for the way too late reply. Since our previous conversation happened, alpha5 completely switched sub state machines to FlowReduxStateMachineFactory so that now everything is in the new system. The next alpha is coming with some more improvements, for example #923 adds cancellation for sub state machines (happy to get feedback).

By the way, will it be problematic that execution policy of some apis (onActions) are based on the type equality and some (onActionStartSubStataMachines) on the value equality 🤔? Is it necessary to let user take control of the execution policy on both equality case?

It's not ideal, but that onActionStartSubStateMachine does not have an ExecutionPolicy was mostly due to time constraints when it was initially implemented. I'm planning to add it, there's just some complexities. But, yes then there's still the case of type vs value and I'm not 100% sure how to resolve it. It might make sense to also change the others to be value based, but I need to see. The basic idea was that in onActionStartStateMachine you could handle actions related to an item in a list and handle the mutation there and then merge it back in. For that it makes sense that actions targeting different items don't cancel each other, but you could say the same about the regular on<Action>.

Which way do you prefer?

We generally prefer having separate subclasses, at least for the content of the screen, so loading/content/error. For submitting a form we have a mix but it also depends on the screen. If you just show an overlay or indicator while submitting and the rest stays the same, we could have something in the state and use condition blocks, for those actions.

But in general some of your issues are also issues for us, like handling actions in a base state where we usually add our on copy helpers to the base class.