Hey! :wave: Following the principles shown in Artur Artikov’s posts, I am trying to decompose my scr...

# decompose

[Nacho Ruiz Martin]

Hey! 👋
Following the principles shown in Artur Artikov’s posts, I am trying to decompose my screens into smaller components. To avoid duplicating logic, I am attempting to create components dynamically for each item of a list that is fetched from the network. The models inside are updated in response to several intents, such as user intents or push notifications so the component is observing the models that are stored in the local repository.
Is this still the recommended approach for dynamic lists of components?

[Arkadii Ivanov]

Absolutely not. Also you are looking at the old repo. Decompose now supports Child Pages navigation model, please give it a try. Alternatively, you can use Generic Navigation for custom navigation cases, by either using it directly or creating your own navigation API (e.g. extension on ComponentContext).

[Nacho Ruiz Martin]

Sounds reasonable, the fact that it was in the old repo is what warned me about it being deprecated, actually.
I thought the Child Pages navigation had the active page as mandatory. It's a normal list in my case, no active item.

[Arkadii Ivanov]

You can just ignore the index property, and you can also use pageStatus lambda argument to control lifecycle states of the pages (e.g. make pages never destroyed).

[Arkadii Ivanov]

Or you can implement your own navigation model (i.e. name it Child Items) and derive the implementation from Child Pages, but without index.

[Arkadii Ivanov]

Here is an example of a custom navigation model where all items are always RESUMED.

Untitled.cpp

[Nacho Ruiz Martin]

Looks good, will try it tomorrow. Many thanks!!

[Nacho Ruiz Martin]

Hey, Arkadii! This works like a charm to display the initial list, but when the items are updated and I call to setItems again, the update is not behaving as expected. I guess this should be handled more carefully going through the list?

[Nacho Ruiz Martin]

Or do you think it’s a better approach for each component to observe each item individually instead of the parent observing the whole list?

[Arkadii Ivanov]

Could you elaborate what is exactly not expected?

[Nacho Ruiz Martin]

Basically, items go back to the initial state. They do change and go back to their initial state. I’m unsure what happens behind scenes, but that’s what I’m experiencing.

[Nacho Ruiz Martin]

Are they supposed to update smoothly just by calling navigate?

[Arkadii Ivanov]

Yes, when you call navigate the items should be updated. But I didn't try the code myself.

[Nacho Ruiz Martin]

Let me try to dig deeper and I’ll let you know.

[Arkadii Ivanov]

The navigate function's lambda receives the current list of configurations and returns a new list that should be displayed.

[Nacho Ruiz Martin]

Yep, saw that. Will it perform any magic in terms of comparing old and new list and check if configs are the same or something?

[Arkadii Ivanov]

Yes, this is what it actually does.

[Nacho Ruiz Martin]

Let me check what it’s happening, in that case.

[Nacho Ruiz Martin]

Nah, items are not going back to their initial state. What is happening is that when navigate is called to set a new list (with the same items, just in a different state), the internal mvikotlin’s store is getting recreated so the running coroutine gets cancelled (and on error, I’m resetting the items state to the previous one).
Do you know if this is expected?

[Arkadii Ivanov]

Each component instance in the list is represented by a unique configuration. If you change a configuration in the list, the related component is destroyed and another one with the new configuration is created.

[Arkadii Ivanov]

You can treat a configuration as a unique identifier.

[Arkadii Ivanov]

So it's not clear what you mean by "with the same items, just in a different state".

[Nacho Ruiz Martin]

Each configuration is holding a view model (data class) that will be rendered in each component. Some properties of these models may and will change. I guess that since the new item is not equal with the old one, it’ll recreate the component/store.
Should I override equals in some way or maybe just provide the id to this and make each subcomponent to observe changes independently?

[Arkadii Ivanov]

Yeah, this is the reason. Arguments from a configuration are passed to the corresponding component via constructor. So when you have new arguments, it recreates component instances and supplies new arguments in them.

You can remove all the changing data from configurations and only keep unique info (e.g. id). Then you can locate components in the list and call a method on them. Or your components may subscribe to updates in their constructors.

[Nacho Ruiz Martin]

Yeah, sounds good, thank you! allo love