IssueTracker

Compose needs an API that make producing a consistent asynchronous result simple.

Problem:

If an application is making asynchronous calls based on application state it is difficult to produce a result consistent to the application state at the time the function completes.

For example, consider the following code,

@Composable
fun UserView(userId: Id) {
  var userData: UserData? by remember { mutableStateOf(null) }
  LaunchedEffect(userId) { userData = fetchUserData(userId) }
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

This example will show a "Loading" state until the user data can be retrieved. This is so common in Compose that it has its own helper function, produceState,

@Composable
fun UserView(userId: Id) {
  val userDate = produceState<UserData?>(null, userId) { fetchUserData(userId) }
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

This works well if userId is not itself state. If reading the userId is a state read, as, for example, if userId is a state backed object, such as,

class ScreenModel {
  val userId by mutableState<Id>(Id.None)
  ...
}

In this case you may be tempted to simply write,

@Composable
fun Screen(screenModel: ScreenModel) {
  val userData = produceState<UserData?>(null) { 
    value = fetchUserData(screenModel.userId) 
  }
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

but this is subtly wrong; the lambda is not re-executed when userId changes so changes to userId in screenModel will not update the result of Screen. You may be tempted to fix this by rewriting the function to,

@Composable
fun Screen(screenModel: ScreenModel) {
  val userData = produceState<UserData?>(null, screenModel.userId) {
    value = fetchUserData(screenModel.userId) }
  }
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

This has a number of issues. First, the data displayed for new values of userId is off by at least a frame as the change value for userData is not reset to null when the lambda restarts and even doing this in the lambda itself, such as,

  val userData = produceState<UserData?>(null, screenModel.userId) {
    value = null
    value = fetchUserData(screenModel.userId) }
  }

is too late. Second, the coroutine for produceState is not executed until the composition is applied with the result of using the old value of userData. Once the coroutine executes, composition has already completed and will not restart for another frame. This guarantees that the data will be at least one frame out of date.

To avoid this, you may be tempted to introduce a flow into produceState such as,

  val userData = produceState<UserData?>(null, screenModel.userId) {
    snapshotFlow { userModel.userId }.collect { userId -> value = fetchUserData(userId) }
  }

Seems to solve the issue. You can also use the null trick above to ensure the loading state reappears if fetchUserData(userId) has not returned by the start of the next frame. However, snapshotFlow() observers a sequence of changes to userId, not just the last one. This means that if userId changes faster than fetchUserData(userId) can fetch the user data, the flow will be updating the value to old values of userId until it can catch up, which, in the best case, just flickers the UI. What is required is a flow that discards the result if it is not current and only have a value when it is the value for the current version of userId. This can be done with some clever use flow but it has now become quite complicated and error prone.

What is needed is an effect that allows value to be null or the user data for userId but nothing else. In other words, there needs to be an primitive that is the asynchronous version of derivedStateOf() that is always consistent with the state the lambda passed to it reads so that the snapshot will only see either the sentinel value or a result consistent with the state of the snapshot.

Potential Solution:

One potential solution would be a TaskEffect. In a TaskEffect the lambda restarted whenever any values read in the lambda are modified. If it is already running it is cancelled and started over. The original screen can then be written,

@Composable
fun Screen(screenModel: ScreenModel) {
  val userData: UserData? by remember { mutableStateOf(null) }
  TaskEffect {
    userData = null
    userData = fetchUserData(screenModel.userId)
  } 
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

The complexity of ensuring the snapshot created for the TaskEffect is only applied when the userId is the same value as was passed into fetchUserData is handled by the TaskEffect. The TaskEffect above will only ever be null or the data returned by fetchUserData for the value of userId currently in screenModel. If userId (or any other state value) read by the TaskEffect lambda changes, the coroutine is cancelled (if it hasn't already completed) and is restarted. The coroutine is also cancelled and restarted outside of composition which means, if it can complete before the next frame starts, the composition will never have to show the "Loading..." message.

The TaskEffect can also have a wrapper similer to produceState() that removes some of the boilerplate of the above,

@Composable
fun Screen(screenModel: ScreenModel) {
  val userData: UserData? by produceTaskState(null) { 
    value = fetchUserData(screenModel.userId)
  }
  if (userData != null) {
    UserDataView(userData)
  } else {
    Text("Loading user data...")
  }
}

Task effect will also handle the subtle issue that occurs when the instance of screenModel changes. As Compose will only produce a new instance of a lambda when the values captured by the lambda change, when the lambda passed to produceTaskState changes will also cause the task results to be discarded and the lambda to be restarted.