What's the purpose of TemporalGameOfLifeStateMutator?

[entorchip]

In the ComposeLifeApp file in the ui-app module, there's use of a TemporalGameOfLifeStateMutator which takes TemporalGameOfLifeState and other arguments.

Later, there's a call to TemporalGameOfLifeStateMutator's update function which just calls TemporalGameOfLifeState's evolve function in the various argument's with block.

Is there any reason it's separated like this?

Could you call the evolve function from the TemporalGameOfLifeState instead, passing in the arguments, or does this go against some best practice?

I'm asking the question as when I create state holder objects, I usually just mutate from the same object and read from the same object.

[alexvanyo]

Thanks for the question. One caution is that this is all exploratory, not intending to set any sort of "best practice".

The thing I've been exploring here is intentionally keeping a few things very distinct:

• the structure and data of a state holder
• an ongoing piece of work updating the state holder's state
• exposing ongoing work via an Updatable interface with the "powering on" call of suspend fun update(): Nothing

That idea I was going for allows a couple of things:

I can create a TemporalGameOfLifeState object outside of composition and without needing direct dependencies to update it. The act of creating it doesn't immediately kick off any work, or have side-effects. It can exist on its own, and whatever state it currently has can be read. I can pass a TemporalGameOfLifeState to previews or screenshot tests without ongoing updates.

Instead of doing work automatically, it supports doing ongoing work, as exposed by suspend fun evolve(), with the specified dependencies, but there's no direct CoroutineScope reference to launch things into: all work must be done in suspend fun evolve(), in reacting to other state that is updating. If suspend fun evolve() is cancelled, TemporalGameOfLifeState goes back to having no ongoing work.

One way to call evolve is with TemporalGameOfLifeStateMutator: a specific object that provides the dependencies to do the ongoing work, in order to expose the Updatable suspend fun update(): Nothing method. TemporalGameOfLifeStateMutator pretty much just exists to turn the suspend fun evolve() with the context receivers into the suspend fun update(): Nothing calls. It's also kind of nice if one of those dependencies changed: I could just recreate the TemporalGameOfLifeStateMutator separately from recreating the TemporalGameOfLifeState.

Once I have that simple suspend fun update(): Nothing method, I can implement the policy of when to do that ongoing work completely externally to the component, using normal coroutine cancellation rules. Right now it continues to run while the app is in the background, but if I wanted to change that, nothing would have to change with TemporalGameOfLifeState or TemporalGameOfLifeStateMutator at all. It just matters what scope I run and cancel the suspend fun update(): Nothing method in.

I sort of view this suspend fun update(): Nothing method as "is the component powered on or powered off?". A powered off component can still be totally valid for rendering UI, or to keep showing the data from the most recent time it was powered on. But the decision to power on or power off the component can be done separately from the structure that the component itself provides. This also ends up being pretty nice for tests: you can inspect the structure while in a "powered down" state, and control "powering on" within the test. I do that for a lot of the data layer Updatable types.

TemporalGameOfLifeState.evolve is also called completely separately from Compose UI in the watchface here:

composelife/wear-watchface/src/androidMain/kotlin/com/alexvanyo/composelife/wear/watchface/GameOfLifeWatchFaceService.kt

Line 80 in 7588e79

temporalGameOfLifeState.evolve()

So if TemporalGameOfLifeState could only be created with @Composable in a particular piece of UI, and it kicked off work immediately, I wouldn't be able to reuse the same logic outside of the UI.

[entorchip]

Thanks for the reply, I really appreciate the explanation.

It makes much more sense now that you implemented TemporalGameOfLifeStateMutator as a sort of on/off switch for TemporalGameOfLifeState since the state changes over time. I didn't actually pick that up when I was reading the code, as I was thinking of what I've worked with, which is more like the simple "change UI-specific state on a button click" scenario.