The mutableMapStateOf does not appear to maintain the order of the map when you iterate as <mutableM...

# compose

[Guy Bieber]

The mutableMapStateOf does not appear to maintain the order of the map when you iterate as mutableMapOf does. It randomly reorders my tabs. Any recommendations or is this a known bug?

[Guy Bieber]

It definitely would be nice to support it. Guess I will get by key in order to fix the problem short term.

[gildor]

a little surprised that mutableMapOf promises to maintain key order

There is no such promise

but considering the contract of mutableMapOf

It's not a part of contract, it's an implementation detail, but it intentional, to avoid many bugs caused by usage map and expect that it keeps order

[jim]

There is no such promise

@gildor Did you read the contract for mutableMapOf? Can you elaborate? Because I'm not sure how else to interpret the docs.

[Guy Bieber]

This is messy to workaround. I have a generic class passing in some enums. Painful.

[Guy Bieber]

Here is a quick workaround.

Before:

mDataModel.tabMap.forEach() {

After:

mDataModel.tabMap.toSortedMap().forEach()

[Guy Bieber]

Not very efficient, but it works.

[gildor]

Ahh, interesting, yeah, it's contract of mutableMapOf, I was confused with contract of MutableMap itself

[Chuck Jazdzewski [G]]

The state map does not guarantee stable iteration order like the LinkedHashMap returned by mutableMapOf() does, whose iteration order is insertion order, but uses a doubly-linked list to maintain this order.

The map returned by mutableStateMapOf() is more similar to HashMap which does not guarantee a stable order. It is implemented by using PersistentMap from kotlinx.collections.immutable which also does not guarantee a stable order.

[Guy Bieber]

Will there be support for sortableStateMapOf?

[Chuck Jazdzewski [G]]

Not before 1.0 releases. BTW, very few map implementations guarantee sorted order. Only tree based (such as red-black) maps typically do that.