❓ How to handle some advanced features about komposable-architecture HOT 3 CLOSED

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?

from komposable-architecture.

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 🤷‍♂️

from komposable-architecture.

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.

from komposable-architecture.