Zach Klippenstein (he/him) [MOD]05/04/2020, 5:56 PM
, when using
to calculate list changes, it’s recommended to run the diff calculation on a background thread since it can be slow. This makes it tricky to use with declarative programming, because state updates to the list don’t synchronously get propagated down the tree (e.g.
in an item view causes a new list to be emitted with new text, but that text doesn’t get bound to the actual view until a few main loop iterations later, which causes state to get out of sync when typing fast). What implications does this have for
in Compose? Add/remove item animations can be done at the per-item level, which seems straightforward enough. But if the list is re-ordered, or items are inserted anywhere other than the end of the list, does
preserve composable state/groups by keying on the list items (i.e. using `key`/`Pivotal` machinery)? If it does, does it process those changes more efficiently than
? Does this question not even make sense in the Compose world?
Vinay Gaba05/04/2020, 6:07 PM
Zach Klippenstein (he/him) [MOD]05/04/2020, 6:12 PM
use this same machinery for list items? And are there plans to support some sort of asynchronous processing for large lists when necessary?
Leland Richardson [G]05/04/2020, 11:14 PM
Zach Klippenstein (he/him) [MOD]05/05/2020, 12:09 AM
coolchandrakumar05/06/2020, 3:52 AM
Zach Klippenstein (he/him) [MOD]05/06/2020, 3:03 PM