State immutability and clearing questions

[nsk90]

Hi! Flywheel looks very nice.

I have some questions despite its architecture:

1. How State deals with types that cannot be just copied as Strings or Integers, for example some Closable resources. It is ok to store such types in a State? It seems to be breaking State immutability rule, as all we can do is just to copy a reference on them into a new State instance.

2. Who is responsible for clearing data from a State?
   For example if we have 3 screens and it is possible to navigate like this:

• A) [init -> 1];
• B) [1 -> 2];
• C) [1 -> 3].

Here arrows are Actions.
If case A) adds some members meaningful only for screen 1 into a new State instance in a Reducer function. Those members does not make sense for screens 2 or 3. Where/when they should be cleared?

[abhimuktheeswarar]

1. Flywheel doesn't enforce any rules on how u model the State, but it is recommended to be a data class with immutable variables. In Flywheel, the reducer function is a pure function. But, when u have "closable resources" as part of a State. then the reducer might become impure, because, the "closable resource" can be in any state of its own based on some external factors. So such things can live in a worker, i.e part of a side effect instance, which you can think of as another "worker actor" that has its own internal state. But if u want to have a "closable resource" as part of a State, then it is your responsibility to handle it properly.
2. In the context of the Android platform, we recommend a StateReserve (i.e a Store for State) for each screen. But, you can have a single StateReserve for multiple screens, in that case, you can have a side effect that listens to these navigation actions & can dispatch another action to update (clear) the state or u can use stateFlow.filterIsInstance<AppState.ScreenA>() and ignore the other members, which might be relevant again when the user goes back to that screen again.