Presenter state stored as class properties vs inside present() — is this an intended pattern?

[AnandaDwiprayoga]

In our app, we are using a Presenter class and keeping screen-related state as class properties, while present() simply collects and exposes that state to Compose.

A simplified example looks like this:

class ExamplePresenter(
    private val repository: Repo
) : Presenter<ExampleUiState> {

    private val items = MutableStateFlow<List<Item>>(emptyList())
    private val error = MutableStateFlow<String?>(null)

    @Composable
    override fun present(): ExampleUiState {
        val itemsState by items.collectAsState()
        val errorState by error.collectAsState()

        return ExampleUiState(
            items = itemsState,
            error = errorState,
        )
    }
}

Question

While this pattern feels natural and aligns with how Presenters behave lifecycle-wise, I couldn’t find a clear example in the official docs that explicitly shows:

keeping MutableStateFlow (or other state holders) as Presenter properties and only collecting them inside present()

So I wanted to ask:

1. Is storing state as Presenter properties (outside present()) an intended and supported pattern?
2. Is this considered idiomatic Circuit usage, or is there a preferred alternative?
3. Are there any caveats or cases where this approach should be avoided?

[ZacSweers]

That's valid. As far as patterns go it's beholden to any other compose idioms when dealing with class instances (i.e. entire your presenter class abides by the stable contract with its data)