Why do configurations in the stack have to be unqiue?

[gnawf]

Maybe something obvious I missed, but why do configurations have to be unique? Configurations in my mind are basically URL paths, right? So why can't the user visit the same URL more than once?

[arkivanov]

Hello and thanks for the question. This is because how the API is designed, the main method for navigation is as follows: navigate(transformer: (List<C>) -> List<C>). So instead of direct commands like push or pop, there is one single method navigate.

One the one hand, this gives a lot of flexibility, as you can manipulate the stack how you want. For example you may want to navigate from A <- B <- C <- D to C <- E <- A (the head of the stack is at the end).

But on the other hand, the Router has a requirement to destroy removed components, to create new components, and to do nothing with the components that are still in the stack. In order to achieve it, the Router calculates diffs between old and new stacks and performs required operations.

Calculating diffs requires all components to be unique, because the Router compares configurations. For example consider the following stack - A <- A<- A. For this stack the Router created three instances of a same component class - ComponentA <- ComponentA <- ComponentA. If at this point you call router.navigate { listOf(it[0], it[2]) } to remove the middle component, the Router will have to compare the following two lists - [A, A, A] and [A, A]. It is impossible to determine which components should be actually destroyed and removed from the stack.

Additionally, configurations are used as map keys in some other places, or compared by hash code.

If you have any issues due to this requirement, I will be happy to help find a solution.

[aartikov]

@arkivanov Hi. There are cases where the same screen can occur multiple times in a stack.

For example, imagine a social networking app. You can open a UserA profile, then a friend list of this user, navigate to UserB, to his friend list and then again to UserA. By pressing a back button we will visit these screens in the opposite order.

What is the best way to implement it with Decompose? The possible solution is to add some synthetic unique fields to the configurations. But it looks a little weird, isn't it?

What do you think about such cases?

[arkivanov]

Thanks for the use case! First of all please consider the bringToFront navigation function. So if UserA is already in the stack, it will be moved to top and so there will be no duplicated screens. This might be a better UX, and the screen will appear faster because it already exists in the memory. However if this behaviour is undesirable and you really want duplicated screens in the stack, then you can refer to the Counter sample, that demonstrates reusable configurations. You definitely need to make configurations distinguishable, so Decompose can clearly understand what components belong to what configurations and when it's time to destroy a component.

[Perfomer]

For the case when you have the same Configurations classes multiple times in the stack, bringToFront function will erase all the other instances of this class from stack.

If you want to keep other instances and actually bring new Configuration to front, you may use pushToFront.

[moffpage]

pushToFront will remove the configuration and push the new one.
I guess what the OP needs is using push with duplicateConfigurationsEnabled = true (global state stored in an object)

[aartikov]

@arkivanov seems like good options. Thank you!