❓ How to handle some advanced features

[Cotel]

Hi! I'm a big fan of TCA in SwiftUI and I'm working on a Kotlin multiplatform project in which we want to use this architecture for both platforms.

We've managed to code a lot of the app but we are starting to face some rough edges, so I'd like to get some inspiration on how to solve them.

The challenges we (mostly) related to state restoration once the app comes back from background after some time. We create our substores in runtime depending on the user navigation, so once the reference is destroyed we cannot recreate them and the app crashes.

Some examples:

State is a sealed class and we need to use a composable function for handling every when branch so we don't deal with nullables: (TCA's SwitchStore)

sealed class ProfileState {
  object Loading : ProfileState()
  data class Empty(val state: EmptyProfileState) : ProfileState()
  data class Filled(val state: FilledProfileState): ProfileState()
}

val profileReducer = Reducer.combine(
  Reducer { ... },
  EmptyProfileState.reducer.pullback(...),
  FilledProfileState.reducer.pullback(...)
)

@Composable
fun HomeTab() {
  val store = hiltViewModel<HomeStore>() // State isn't too deep here so we can create this viewmodel in build time

 // WhenStore and Case allows us to use stores with non-nullable state for the current case. But these stores
 // can only be created in runtime by passing through this piece of code.
  WhenStore(store) {
    Case<ProfileState.Loading, ProfileAction>(
      deriveState = ...,
      embedAction = ::identity
    ) { loadingProfileStore ->
      Navigator(HomeLoadingProfilePage(loadingProfileStore))
    }

    Case<EmptyProfileState, EmptyProfileAction>(
      deriveState = ...,
      embedAction = ...
    ) { emptyProfileStore ->
      Navigator(HomeEmptyProfilePage(emptyProfileStore))
    }

    Case<FilledProfileState, FilledProfileAction>(
      deriveState = ...,
      embedAction = ...
    ) { filledProfileStore ->
      Navigator(HomeFilledProfilePage(filledProfileStore))
    }    
  }
}

Once in one of those pages, if the activity is destroyed, when the framework tries to recreate the screen it cannot create the store again as it isn't parcelable. Creating a store manually is possible, but it wouldn't make sense as the global state won't be updated.

---

Recursive state and navigation.

data class TaskDetailState(
  val title: String,
  val body: String,
  val subtasks: List<TaskDetailState>,
  val childDetail: TaskDetailState? = null
)

sealed class TaskDetailAction {
  ...

  data class ChildTaskDetailAction(val action: TaskDetailAction) : TaskDetailAction()
}

val reducer = Reducer.recurse { ... } 

// Code for creating substores would be
val store: Store<TaskDetailState, TaskDetailAction> = ...

store.derived<TaskDetailState?, TaskDetailAction>(
  deriveState = { it.childDetail },
  embedAction = { TaskDetailAction.ChildTaskDetailAction(it) } 
)

Again, these kind of substores must be created in runtime as we don't know how many levels of nesting the user will navigate. Besides, they all have the same type signature, so a parameter is needed for retrieving them from DI. The most obvious one being the Task id, which we don't know until runtime.

---

TLDR How would you work with store which can only be created in runtime? How would you make them survive process death?

Thanks for your time ❤️

[semanticer]

Hi! I'm sorry for the late answer.

Hi! I'm a big fan of TCA in SwiftUI and I'm working on a Kotlin multiplatform project in which we want to use this architecture for both platforms.

This sounds exciting and it is definitely something we're also considering in the future. Let us know how it goes.

Thank you for a very detailed question, I'm not sure if I understood it completely but let me try to answer:

We use "optional" reducers for this:

Let's say there is a root TodoListReducer with it's TodoListState that might look like this:

data class TodoListState(
    val todoList: List<Todo>,
    val editedTodo: Todo?,
)

Then we have an EditTodoReducer with EditTodoState:

data class EditTodoState(
    val editedTodo: Todo,
)

This state is a subset of TodoListState but notice that editedTodo is not nullable.

The idea is that we have a list of TODO's and when the user taps one we'll save it to editedTodo and we display some kind of edit page that should be handled by EditTodoReducer. Now how do we combine these two when EditTodoReducer needs a non-nullable Todo? We'll use optionalPullback to combine them:

combine<TodoAction, TodoListState>(
    todoListReducer,
    editReducer.optionalPullback(
        mapToLocalState = { todoListState: TodoListState ->
            if (todoListState.editedTodo != null) EditTodoState(todoListState.editedTodo)
            else null
        },
        mapToGlobalState = { todoListState: TodoListState, nullableEditTodoState: EditTodoState? ->
            if (nullableEditTodoState != null) todoListState.copy(editedTodo = nullableEditTodoState.editedTodo)
            else todoListState
        }
        mapToLocalAction = TODO()
        mapToGlobalAction = TODO()
    )
)

Let me know if I answered your question or whether I confused two different things 🤷‍♂️

[Cotel]

Thanks for your response. Reading myself again I see I didn't have my problem identified so the question is not concrete enough. I've continued my research and I think I can explain myself better now.

So, as you explained, optionalPullback lets us to combine child reducers with their parents up to a root store. But the problem we have is when we do the "reverse" process.

Lets say Store<TodoListState, TodoListAction> is your root store and you have a screen in your app which receives it as a parameter. Now, when you click on a todo you want to navigate to another screen which receives Store<EditTodoState, EditTodoAction> as a parameter (notice that EditTodoState is not nullable).

We found a big issue with Navigation Compose. The library requires you to define the whole navigation graph beforehand. But we can't perform store derivations without helpers like optionalPullback for the parent to children direction:

@Composable
fun RootView() {
    val store = Store(TodoListState(), todoListReducer, Unit)
    val navController = rememberNavController()

    NavHost(navController = navController, startDestination = "todoList") {
        composable("todoList") { TodoListScreen(store, navController) }
        composable("editTodo") { 
            EditTodoScreen(store = store.derived(
                { it.editedTodo?.let { EditTodoState(it) } },
                { TodoListAction.Edit(it) }
            )) // Type mismatch. Required: EditTodoState. Found: EditTodoState?
        }
    }
}

@Composable
fun TodoListScreen(
    store: Store<TodoListState, TodoListAction>,
    navController: NavController
) {
    WithViewStore(store) {
        Column {
            state.todoList.forEach { todo ->
                Text(todo, modifier = Modifier.clickable {
                    navController.navigate("editTodo")
                })
            }
        }
    }
}

@Composable
fun EditTodoScreen(store: Store<EditTodoState, EditTodoAction>) {}

We need a tool that asserts that, once you click a todo and trigger an action which sets editedTodo to a non null value, we can derive a non nullable Store<EditTodoState, EditTodoAction>. We can find this tool in The Composable Architecture as IfStore. The thing is that is a view (a composable function in our case), so it alters our NavHost definition:

 @Composable
fun RootView() {
    val store = Store(TodoListState(), todoListReducer, Unit)
    val navController = rememberNavController()

    NavHost(navController = navController, startDestination = "todoList") {
        composable("todoList") { TodoListScreen(store, navController) }

        // Composable invocations can only happen in the context of a @Composable function
        IfStore(store = store.derived<EditTodoState?, EditTodoAction>(
            { it.editedTodo?.let { EditTodoState(it) } },
            { TodoListAction.Edit(it) }
        )) { editTodoStore: Store<EditTodoState, EditTodoAction> ->
            composable("editTodo") { EditTodoScreen(store = editTodoStore) }
        }
    }
}

Now we can't define our navigation graph beforehand because we cannot make use of IfStore. We would need to have access from TodoListScreen to EditTodoScreen directly to pass the derived store as an argument. We investigated some libraries and we decided to go with Voyager making a hacky swiftUI like NavigationLink:

@Composable
fun RootView() {
    val store = Store(TodoListState(), todoListReducer, Unit)
    Navigator(TodoListScreen(store))
}

class TodoListScreen(
    private val store: Store<TodoListState, TodoListAction>
) : Screen {
    @Composable
    override fun Content() {
        WithViewStore(store) {
            Column {
                NavigationLink(destination = {
                    EditTodoScreen(store.derived<EditTodoState?, EditTodoAction>(
                        { it.editedTodo?.let { EditTodoState(it) } },
                        { TodoListAction.Edit(it) }
                    ))
                }) {
                    state.todoList.forEach { todo ->
                        Text(todo)
                    }
                }
            }
        }
    }
}

class EditTodoScreen(
    private val store: Store<EditTodoState?, EditTodoAction>
) : Screen {
    @Composable
    override fun Content() {
        IfStore(store = store) { store: Store<EditTodoState, EditTodoAction> ->
            WithViewStore(store) {
                Text(state.editedTodo)
            }
        }
    }
}

This code works, but brings an issue we weren't able to solve. All parameters passed to a screen must be Parcelables. Store cannot be parcelable, so we have to mark it as Transient. As a consequence, if the activity is destroyed and restored (user comes from background after some time) the app will crash as the screen doesn't know how to recreate the store.

We've decided to override onSaveInstanceState and live without automatic state restoration. But we want to solve this situation and we're looking for inspiration.

Changing Navigation Compose to Voyager may seem not needed, but I've simplified this example to be on the same line of thought. We couldn't define a navigation graph beyond EditTodoState with Navigation Compose easily. It is also required when entering advanced features like the ones I exposed in the first comment, specially if we are talking of recursive navigation.

So, I guess my question is, how are you passing your derived stores from parent screens to child screens?

[jefflewis]

Does it make sense to put the App Store into a service? Then whatever activity is the one active can create the service if it's not active, or connect to the service if it is.