Hey there, thanks for your work again <@UHAJKUSTU>...

# decompose

[s3rius]

Hey there, thanks for your work again @Arkadii Ivanov 🔥

Could you say a few words about duplicateConfigurationsEnabled ? I'm quite interested because I have a few scenarios where I would like to be able to have the same configurations- at the moment I solve this by adding an index or a random UUID to each config.

I'm guessing Decompose will use the order of equal configurations to match it to components? Meaning if I have configs listOf(A1, A2) (both A's being equal), it will create Child(A1, Comp1) and Child(A2, Comp2). And if I were switch them via nav.update { listOf(A2, A1) } I would probably end up with Child(A2, Comp1) and Child(A1, Comp2)?

[Arkadii Ivanov]

This mode is experimental and may go away. You can try it, but I still recommend having distinct configurations.

If you swap two equal configurations, component instances will not be swapped. Because there is no way Decompose can distinguish the equal configurations.

What is your use case?

[s3rius]

I have 1.5 use cases:

The lesser use-case is that users can navigate in such a way that a stack-navigation may contain the same destination twice. Concrete Example: we have a screen for News Article which contains related articles. So a user can jump from one article to another, and the stack reflects this. After opening an article and selecting a related article the stack would be: listOf(Home, News(original), News(related)) . So it's possible for the user to click through related articles until they end up at an article they were already at, which would be a duplicate configuration entry.
In this case, swapping of configurations would pretty much never occur.

The more relevant use-case is large lists of items. If you remember, I was asking about a list-navigation some weeks ago. Basically the equivalent of Pages but for a lazy-column/row instead.
For my use-case, the contents of this list are provided by a (paginated) API, and there isn't a reason why the same item wouldn't be in there more than once. In fact, it's expected to happen because we interlace ads in regular intervals, and these ads would sometimes repeat.
In this case, swapping of configurations should pretty much never occur but it's harder to reason about because new pages can be loaded via pagination, and unloaded via a refresh mechanic.

The individual items of this list are pretty complex and it's very useful to have every item be represented by a Component (with lifecycle, etc), so using Decompose for that has been the right choice. It just took a little extra (unique IDs based on index position) to ensure the list doesn't blow up when a duplicate is shown.

[s3rius]

Ah, maybe to conclude: I'll probably stick to the current approach. But I saw the duplicateConfigurationsEnabled in the latest alpha and was curious given that it was relevant to what I was working with over the past few weeks.

[Arkadii Ivanov]

Thank you for providing real life examples. This is always very helpful! Here are my ideas.

1. The case with articles in the stack. From my point of view, this case demonstrates exactly why we shouldn't have duplicated configurations in the stack. This looks like a terrible UX - allowing users to have long stacks with repeating screens. I would rather use pushToFront (equivalent to FLAG_ACTIVITY_REORDER_TO_FRONT).

2. The case with ads in Pages is a very interesting one! How I would handle it: I would add a number property to the ad configuration class, and probably write a custom navigation extension function to automatically increment the number for every new ad in the list based on the last ad in the list. This would make sure that if I ever need to remove a random ad from the list (e.g. the user clicks a Dismiss or Report button, or something similar), then their corresponding components wouldn't mess up.

[s3rius]

Yep, (1) is pretty much how we solved it.
(2) is a good point. It would basically turn the number into an implementation detail, whereas right now it's the responsibility of the hosting component to add a unique id based on some criteria.

[s3rius]

By the way, regarding real-life feedback: I introduced Decompose into our company a few months ago. It took a bit of convincing because it's a relatively unknown library and effectively maintained by a single person. But about a week ago we launched an Android app with ~50 components to an audience of 50k :)

No Decompose-related crashes, very few issues in general. LifecycleRegistry works great for units tests. We're using a custom Component class that I want to eventually replace using GenericComponentContext. We're using retainedComponent to avoid having to deal with a lot of state restoration; that may not be the gentleman's way but works fine.

Seriously. I'm impressed 👍

[Arkadii Ivanov]

Thank you! 🔥🚀